Bounding Box Export QA: Pixel and Normalized Coordinates

Specify bounding box units, coordinate representation and source image dimensions before accepting an annotation export. A normalized box and a pixel box can describe the same object, but applying pixel coordinates to a resized image can put the box in the wrong place.

This guide is for buyers reviewing image annotation deliveries. It is not a work opportunity, hiring announcement or application guide. The original export worksheet and synthetic calculation below help make a delivery reproducible without ranking providers or promising model performance.

Which coordinate convention does the export use?

Record the origin and axis directions, the units and whether a box is represented as left, top, width and height or as minimum and maximum corner coordinates. Also record the image identity, dimensions and orientation to which the coordinates apply. Similar field names across formats do not establish identical meaning.

Amazon Rekognition's BoundingBox documentation defines left and width as ratios of image width, and top and height as ratios of image height. It also notes that partially visible detections can have coordinates outside image bounds. That is one documented format, not a universal annotation convention. Data Annotation Companies is independent and is not affiliated with AWS.

What should be written into the export handoff?

Agree the format before delivery and keep it tied to the exact asset version. Ask the provider to supply the convention and transformation history rather than inferring them from four numbers.

Field	Definition to retain	Acceptance question
Asset identity	Stable image ID and version reference	Which exact image does this annotation describe?
Dimensions	Width and height of the coordinate image	Were coordinates generated before or after resizing?
Origin and axes	Declared origin and direction of increasing values	Does the consumer interpret the same frame?
Units	Pixels, normalized ratios or another documented basis	Is the conversion explicit?
Representation	Left/top/width/height or declared corner fields	Are dimensions being mistaken for far-edge positions?
Transformations	Resize, crop, rotation or other applied change	Is the coordinate transformation documented?
Boundary rule	Allowed out-of-bounds values and clipping policy	Are exceptions reviewed under the agreed format?
Rounding	Consumer-approved pixel conversion rule	Can the rendered result be reproduced?

How do normalized coordinates become pixel coordinates?

AWS's bounding box display guidance describes multiplying normalized coordinates by the corresponding image dimension. Use the documented format and the correct image dimensions. Do not assume that every export uses that representation.

Illustrative example. A synthetic image is 1000 pixels wide and 500 pixels high. Its declared normalized box has left 0.10, top 0.20, width 0.30 and height 0.40. In this example the origin is the top-left corner, with x increasing rightward and y increasing downward.

Value	Calculation	Pixel result
Left	0.10 x 1000	100
Top	0.20 x 500	100
Width	0.30 x 1000	300
Height	0.40 x 500	200
Right edge	100 + 300	400
Bottom edge	100 + 200	300

The width value 300 is a dimension, not the right-edge position. The corner representation is therefore left 100, top 100, right 400 and bottom 300. The example uses continuous boundary coordinates and does not define an inclusive pixel-index convention. If the consumer uses a different convention, record that conversion explicitly.

What changes when the image is resized?

In the same illustrative example, a proportional resize of the whole image to 500 by 250 pixels, with no crop or rotation, preserves the normalized ratios. The pixel box becomes left 50, top 50, width 150 and height 100. Reusing the old pixel coordinates on the resized image gives a different placement.

A crop or rotation needs its own coordinate transformation; it cannot be described as a width-and-height scaling alone. Retain the transformation reference and original annotation. Do not silently replace the source image while keeping an unchanged pixel export.

Which delivery checks should the buyer perform?

Check declared field meanings and dimensions, then render a review sample against the exact coordinate image. Include changed-size assets and any agreed boundary cases. Record whether a mismatch comes from format interpretation, image version, transformation or annotation judgment rather than treating all errors as poor labeling.

Do not automatically reject every negative or greater-than-one value under a rule that the selected format does not require. AWS's documented example permits some out-of-bounds coordinates. Apply the agreed validation and clipping policy and retain the disposition for exceptional items.

Preserve the original export, conversion method and reviewed version. Use the annotation services buyer page when exploring providers, then request responses to the same asset and coordinate specification. Confirm actual capabilities directly with each provider.

Frequently asked questions

Are normalized coordinates measured in pixels?

No. In the documented ratio format, convert using the corresponding image dimension.

Is width the same as the right-edge coordinate?

No. In a left/top/width/height representation, the right edge is left plus width.

Can every out-of-bounds value be rejected automatically?

No. Validate against the agreed format and its boundary policy; some documented formats allow such values.

Does proportional resizing preserve the old pixel coordinates?

No. With no crop or rotation, normalized ratios can remain the same while pixel coordinates scale with the image.