YOLO segmentation mask resizing: does label accuracy shift?

Every YOLO segmentation run resizes the camera image to the network's input size, and the annotated polygon stays behind at full resolution. Does that resize move or degrade the ground-truth mask? No, not in any way that matters: labels are stored as coordinates normalized to image width and height, so the letterbox transform moves every vertex by exactly the same scale and offset as the pixels. What does cost accuracy is quantization. The mask head predicts on a coarse grid, and each grid cell grows as the input shrinks. This guide gives the letterbox math, a worked example with the arithmetic shown, the cell-size rule that sets your resolution budget, and the deployment choices between camera-side and controller-side inference.

What a YOLO segmentation label stores

A segmentation label is a class index followed by an ordered list of polygon vertices. Each vertex stores two fractions: x as a share of image width, y as a share of image height, both between 0 and 1. The file never records a pixel count.

A vertex at pixel (1000, 200) in a 1280 × 720 frame is stored as 0.78125 and 0.27778. Shrink the image to 640 × 360 and the same two fractions describe the same corner of the same part. Because the label is dimensionless, resizing the image cannot invalidate it: the ground truth rides along at every resolution, including the letterboxed training copy. A dataset annotated at native camera resolution trains unchanged at a 640 px input.

The letterbox transform, applied to pixels and labels alike

Letterbox preserves the aspect ratio. Both axes scale by one factor s, chosen so the longer side fits the input, and padding fills the leftover rows or columns to complete the square.

The training pipeline applies this exact map to the polygon vertices when it builds the target masks, so a vertex lands on the resized object to within one rounding step. Padding adds empty border pixels; the normalized fractions stay inside the real image area, and the pad offset enters only at the moment fractions become network pixels.

Rect mode changes the target shape instead of the map: frames are scaled to a common rectangle, in multiples of the 32 px stride, rather than padded to a square. The scale-and-offset logic is identical, and the non-square image size in YOLO training: rect vs square guide covers when rect mode pays off. For the square case, YOLO letterbox padding: what happens to a 16:9 image works a wide frame step by step, and object detector input dimensions: height, width, and padding shows how the input shape is assembled in general.

Worked example: 1280 × 720 into a 640 × 640 input

Take a 1280 × 720 frame with a polygon vertex at pixel (1000, 200).

Scale: s = min(640/1280, 640/720) = min(0.5, 0.889) = 0.5. The resized image is 640 × 360. Padding: (640 - 360) / 2 = 140 px top and bottom, 0 px left and right.

Network pixel: x' = 0.5 × 1000 + 0 = 500, and y' = 0.5 × 200 + 140 = 240.

Cross-check from the normalized label: 1000/1280 = 0.78125, and 0.78125 × 640 = 500. On the vertical axis, 200/720 = 0.27778, and 0.27778 × 360 + 140 = 100 + 140 = 240. Both routes land on the same pixel, which is the point: the label needs no edit, and none is ever needed when only the size changes. Mask area scales by s² = 0.25, and IoU stays meaningful because ground truth and prediction share the same grid.

The two quantizers that set mask accuracy

The resize itself is exact up to rounding. Two grids set the resolution you actually get.

Vertex rounding: when the polygon is rasterized into a target mask, coordinates snap to the pixel grid. The error is at most half a scaled pixel, which is 0.5 / s px of the original frame — 1 px at s = 0.5, 2 px at s = 0.25. Annotation noise is far larger, so this term is rarely the problem.

Mask grid: the segmentation head predicts mask prototypes at one quarter of the network input, so a 640 × 640 input returns masks on a 160 × 160 grid. One cell is 4 network px, which is 4 / s px of the original image.

At s = 0.5 a mask edge localizes to about ±4 original px; at s = 0.25, to about ±8 px. The loss is computed on this same grid, so the model is consistent with its targets — it is your expectation of edge precision that must follow the cell size.

Choosing the input size from the defect size

Decide from the finest mask geometry the decision needs; call it d, in original pixels. Require one mask cell to be no larger than d:

Assume a 4:3, 5 MP frame of 2592 × 1944 px (a typical 5 MP sensor; substitute your camera's exact resolution) and run three common cases:

• Presence, shape, area: d = 20 px gives s ≥ 0.2. A 640 px input has s = 0.247 and a cell near 16 px, so it clears the bar with margin.
• Detect a crack 12 px wide: the cell must stay under 12 px, so s ≥ 0.333 and W_in ≥ 4 × 2592 / 12 = 864. Run 960 or 1024. At 640 the crack spans less than one cell and the mask tears it into fragments.
• Outline edges to ±4 px: the cell must be 8 px or less, so s ≥ 0.5 and W_in ≥ 1296. Run 1280 (cell ≈ 8 px), or crop regions of interest from the native frame — a crop keeps s = 1 and cell = 4 px.

When the mask feeds a measurement — width, length, area — the cell size is also the measurement floor; crack width, length and area measurement after segmentation picks up at that stage.

What actually shifts a polygon

Cropping, not resizing. A crop moves the origin, so labels must be re-mapped: subtract the crop offset from every vertex, then divide by the crop width and height. Resizing changes scale, never origin. If masks land shifted by a constant fraction of the frame, look for a crop whose offset was never subtracted; the crop-then-inspect pattern in live inference is covered in rotated bounding boxes in live inference: detect first, crop after.

Asymmetric padding is the subtle one. When the leftover pixel count is odd, the pipeline puts the extra row or column on one side instead of splitting it evenly. Code that assumes exact halves places every coordinate one scaled pixel off — that is 1 / s original px, so 4 px at s = 0.25. Take the pad values from the transform output rather than recomputing them as half of the difference.

Swapped denominators: an annotation step that divides x by height instead of width distorts masks by the aspect ratio — 1.33× on the 4:3 frame above, 1.78× on 16:9. The training overlay hides it only while image and label carry the same mistake.

Upsampling: the predicted mask returns at network resolution and is stretched to full size for output. Nearest-neighbor stretching adds at most half a cell of staircase, and a smoothing filter changes the look, not the accuracy.

On the line: capture size, input budget, hardware

The camera fixes W. The deployment target fixes the input size you can afford per frame, and YOLO inference image size mismatch: fix visual accuracy covers the failure pattern when the training size and the deployed size drift apart.

A 5 MP vision sensor handles shape-based pass or fail at a 640 px input, because one mask cell spans about 16 px of a 2592 × 1944 frame.

When the model must run on the camera itself, an x86 camera platform is the fit: the onboard processor executes the network, and the 8.8 MP capture leaves room to crop regions of interest at native scale.

Multi-camera cells, 1280 px inputs and shared lighting channels belong on a controller; LAN port count and memory are what a larger input spends per frame.

Checks before you blame the resize

• Overlay the transformed polygons on the letterboxed image before the first training run. If they track the parts, the loader map is right and the labels are innocent.
• Recompute the padding the way the pipeline does, not as half of the leftover by assumption; odd leftovers split unevenly.
• Print s and cell = 4 / s for your frame and input. Draw a line that many px long on a test image: that is the finest edge the mask can express.
• Compare masks at native scale. Stretch the predicted mask back to full size and overlay it on the original camera frame, not on the training copy.
• A constant offset on every mask points to a crop origin or a swapped normalization axis, not to resize; trained YOLO model has no detections: fix labels first walks the label audit.
• Mask edges that move frame to frame point to staging or trigger timing; why pixel shifts change detection results and how to stabilize them covers that path.

When the usual answer is wrong

• Blockiness blamed on interpolation is the grid. A larger input or an ROI crop is the fix; a smoothing filter only softens the staircase.
• Accuracy that drops after switching the deployed input size is a scale change, not a label change: the network saw objects at a different size during training. Keep the training size and the deployed size matched, or fine-tune at the deployed size.
• Thin elongated features fail at input sizes where blob-like parts still pass. Run the cell test before collecting more data.
• When the mask feeds a downstream area or depth measurement, pixel selection matters as much as the mask; segmentation mask average depth: select valid object pixels shows that next step.

The decision, in order

Fix d from what the inspection must resolve. Compute W_in ≥ 4·W / d and check the hardware can run that input at the line rate. Keep the training size equal to the deployed size. When the required input exceeds the compute budget, crop regions of interest at native scale instead of asking a smaller input to do more — a 640 px ROI crop keeps cell = 4 px at any camera resolution.

Filter smart cameras by resolution in the camera finder, or plan a multi-camera cell around vision controllers with the build-a-system configurator. The systems topic page collects the training-side guides that go deeper.