Key takeaway
Rotating pixels without transforming their labels can leave a convincing image paired with the wrong region.
Distinguish stored pixels from displayed orientation
A photograph may display upright because a viewer interprets orientation metadata, while the stored pixel array has another orientation. A separate bounding-box file may use either coordinate frame. Before transferring annotated images, ask which frame each artifact uses. Looking at a thumbnail cannot establish that the box coordinates describe the displayed object.
Pillow documents exif_transpose as applying an EXIF orientation transformation to pixels and removing the orientation data. That operation does not say that separately stored annotation coordinates are transformed. Torchvision demonstrates joint image-and-box transforms with an explicit box format and canvas size. These are useful implementation references; the actual receiving pipeline still needs its own fixture checks.
Rotate an explicit rectangle, not an unexplained tuple
This hypothetical fixture has width 6 and height 4, with a rectangle whose continuous edge coordinates are (xmin, ymin, xmax, ymax) = (1, 0, 3, 2). The origin is the top-left edge, x increases rightward and y downward. Boundaries run from 0 to width and 0 to height. This is an edge convention, not a statement about integer pixel-center indices.
After a ninety-degree clockwise rotation, the new canvas is width 4 and height 6. For these edge coordinates, the mapping is x′ = 4 − y and y′ = x. Transform all corners and take their extrema: the new rectangle is (2, 1, 4, 3). Keeping the old tuple would instead identify a different region. The fixture’s area remains 4 square coordinate units, but equal area alone would not establish correct placement.
| Representation | Canvas width × height | Box edges | Decision |
|---|---|---|---|
| Original fixture | 6 × 4 | (1, 0, 3, 2) | Original top-left edge convention |
| Correct clockwise transform | 4 × 6 | (2, 1, 4, 3) | Corners transformed with pixels |
| Pixels rotated, old annotation | 4 × 6 | (1, 0, 3, 2) | Reject misaligned coordinate frame |
| A pixel-center convention | Must be separately defined | Different index formulas may apply | Do not reuse edge formula blindly |
Carry the complete geometry history
A receiving contract should name image width/height, coordinate origin, axis direction, box format, edge inclusion rule, orientation policy and normalization denominator if coordinates use fractions. Record the order of rotations, flips, crops and resizing. A crop can remove part of an object; a resize changes its coordinate scale. Store how clipped or empty annotations are represented rather than silently dropping them.
Include source image identifier, original orientation observation, transformed image identity and annotation version in the mapping. If the pipeline has already applied orientation, applying it again may rotate the image twice. If one export strips metadata while another retains it, viewers can disagree. Ask the producer to explain the transformations already completed, then test the exact recipient behavior.
Verify position with asymmetric fixtures
Use a synthetic picture with a clearly asymmetric marked region near one corner, plus boxes that touch boundaries. Compare the rendered overlay and numerical coordinates after each transformation. A centered square can conceal a rotation mistake, and an area check can pass for a box in the wrong location. Test the pipeline’s rejected out-of-bounds and zero-area cases as well as its ordinary example.
The accepted conclusion is limited to the coordinate conventions and transformations actually checked. Correct geometry does not establish that labels are substantively correct, that people in photographs consented or that the archive can be licensed. Use the inventory builder for geometry metadata and the readiness planner for unresolved transform tests. Keep real images out of an introduction brief unless the named recipient and exact sample scope have separately been approved.