Why does cv2.Sobel with ddepth=cv2.CV_8U lose half of the edges?

## What Sobel computes `cv2.Sobel(src, ddepth, dx, dy, ksize=3)` convolves the image with a small kernel that approximates a partial derivative, optionally smoothing in the perpendicular direction. `dx=1, dy=0` gives the horizontal derivative (response to vertical edges), `dx=0, dy=1` gives the vertical one. `cv2.Scharr` is the more rotationally accurate 3x3 variant, and `cv2.Laplacian` is the second derivative, which is unsigned in a different sense — it is signed too, and has exactly the same dtype problem. The key fact is that these are *derivatives*, and a derivative of a real signal takes both signs. Along +x, a step from 0 to 255 yields a large positive response; a step from 255 to 0 yields a large negative one of the same size. ## The saturation trap `ddepth` is the depth of the **output** array. `cv2.CV_8U` is unsigned 8-bit. OpenCV does not wrap on overflow the way NumPy does; it *saturates*, clamping to [0, 255]. So every negative derivative becomes exactly 0. The image looks plausible — you get edges, just not all of them — which is why this survives code review. A bright rectangle on a dark background filtered with `dx=1` shows only its left border; the right border, where intensity falls, is gone. The symmetric mistake is casting afterwards in NumPy: `sobel.astype(np.uint8)` on a float array **wraps** rather than saturates, so -20 becomes 236 and the edge map fills with garbage bright pixels. Both routes lose the information; the NumPy one loses it more colourfully. ## The correct pattern 1. Compute into a type that can hold the sign and the range. `cv2.CV_16S` is the traditional choice for 8-bit input (a 3x3 Sobel can exceed 8 bits even in magnitude); `cv2.CV_32F` or `cv2.CV_64F` are fine and are what you want if further float math follows. 2. Convert for display or thresholding with `cv2.convertScaleAbs(src, alpha=1, beta=0)`, which computes `saturate_cast<uchar>(|src * alpha + beta|)` — absolute value first, then saturation, so both polarities survive as bright pixels. 3. Combine directions. The cheap approximation is `cv2.addWeighted(abs_gx, 0.5, abs_gy, 0.5, 0)`. The correct magnitude is the Euclidean norm of the signed gradients, computed with `cv2.magnitude(gx, gy)` on `CV_32F` inputs (`cv2.cartToPolar` gives magnitude and orientation together if you need edge direction). Note the ordering: take the absolute value *before* combining. Averaging the signed images first lets a positive and a negative response cancel. ## Related consequences - **Scale.** With `ksize=3` the Sobel kernel is not normalised, so responses on a hard edge run into the high hundreds even for 8-bit input. That alone would overflow `CV_8U` on the positive side too. `cv2.Sobel` exposes a `scale` argument, and `cv2.convertScaleAbs`'s `alpha` gives you a second place to rescale for viewing. - **Blur first.** Differentiation amplifies high-frequency content, which is exactly where noise lives. A light `cv2.GaussianBlur` before `cv2.Sobel` is standard, and the `ksize` of the Sobel itself provides some smoothing (larger `ksize` = more smoothing, thicker response). - **Laplacian has the same trap.** `cv2.Laplacian(src, cv2.CV_8U)` throws away the whole negative lobe of every edge response, which for a second derivative means you keep only one side of each zero crossing. - **`ddepth=-1`** means "same depth as the source". On the usual 8-bit input, that is `CV_8U` — so `-1` is the trap under another name, and it is the default in several OpenCV filtering functions. ## How to spot it in a review Any `cv2.Sobel`, `cv2.Scharr` or `cv2.Laplacian` call whose `ddepth` is `cv2.CV_8U` or `-1` is suspect. Any `.astype(np.uint8)` applied to a gradient array is suspect. And any edge image where the outlines look one-sided — objects with a bright left rim and no right rim — is this bug rendered visually. The interviewer's real question behind this one is whether you understand that OpenCV's output dtype is a decision you make per call, and that saturation is silent.