Skip to content

Annotation quality guide

Bounding Box Coordinate Conventions: Reconcile Pixels, Origins, and Formats

Review object boxes by writing the image geometry and coordinate convention beside every observation, before comparing annotations or converting formats.

A bounding box is not portable just because it has four numbers. Review the image width and height, origin, axis direction, units, field order, edge convention, and whether the box is clipped or outside the image. Keep the source record and any conversion as separate evidence. This guide is a static worksheet, not a detector, coordinate converter, geocoder, or claim about model quality.

Updated

On this page

Write the coordinate contract before comparing boxes

The source dates shown in this guide identify documentation checks on 22 October 2026, not original publication dates. Follow each citation for the format vocabulary being discussed. First record a controlled image id, width, height, frame or page index, and any resize or crop operation. Then record whether coordinates are pixels, normalized fractions, or another declared unit; whether the origin is the top-left or another point; and whether the fourth fields mean width and height or maximum x and y.

Write the coordinate contract before comparing boxes (table)
Contract fieldSynthetic exampleQuestion to resolve
Image geometrywidth 640, height 480Which dimensions belong to this annotation?
Origintop-leftDoes y increase down the image?
Unitspixel coordinatesAre values absolute or normalized?
Field orderx, y, width, heightCould the last pair be x_max, y_max?
Edge conventionhalf-open or inclusiveHow is a one-pixel edge represented?
Transformcrop then resizeWhich transform produced these numbers?
Clip policyinside image or flaggedAre outside values errors or evidence?

The cited format documentation shows a format with image dimensions and object annotation fields such as bbox, while segmentation is carried separately CVAT Documentation, (opens in a new tab). Do not infer every field convention from a familiar name. Preserve the declared format and the local export documentation as evidence.

Reconcile boxes with image bounds and transforms

For a synthetic image with width W and height H, a pixel box in x, y, width, height form has a start point and an extent. A review can derive an end point for comparison, but it should not silently rewrite the source. Keep both the raw values and the derived comparison values, with the convention used for the derivation.

Synthetic box worksheet fixture

Reconcile boxes with image bounds and transforms code example, JSON
{
  "image": {"id": "synthetic-frame-01", "width": 640, "height": 480},
  "source_box": {"format": "xywh", "units": "pixel", "origin": "top-left", "x": 120, "y": 80, "width": 160, "height": 120},
  "derived": {"x_end": 280, "y_end": 200, "inside_image": true},
  "review": {"transform": "none declared", "edge_rule": "unknown", "disposition": "conditional"}
}

The fixture is invented and contains no customer image or private label. If a source uses normalized values, record the image dimensions used at conversion time. A box that fits after a resize can still be wrong if it was measured against the pre-crop geometry. Record crop, pad, rotate, and mirror operations in order, rather than keeping only a final guessed box.

Reconcile boxes with image bounds and transforms (table)
FindingWhat it establishesWhat it does not establish
Negative x or yThe box is outside or uses another conventionThat clipping is safe or intended
End point beyond boundsExtent and image geometry disagreeThat the object is absent
Width or height zeroThe supplied extent is not a visible areaWhy the annotation was emitted
Fractional pixelThe source uses subpixel or normalized precisionThat rounding is harmless
Box fits after transformOne stated transform reconciles valuesThat the source transform is complete

Compare formats without losing source meaning

A conversion is a new evidence record. Capture source format, destination format, source image geometry, transform, rounding rule, clipping rule, and the reason for conversion. A xywh to xmax,ymax derivation can be reversible only if the edge convention and numeric precision are known. A crop or rotation may require an explicit geometry transform, not a field rename.

Compare formats without losing source meaning (table)
Conversion questionRecordHold when
Field semanticsSource and target names with definitionsNames are guessed from position
Image dimensionsDimensions before and after transformOne side is absent
PrecisionDecimal scale and rounding operationRounding rule is unknown
ClippingOriginal and clipped coordinatesOut-of-bounds values are discarded
IdentitySource annotation id and destination idThe output cannot be traced
ValidationSynthetic round-trip or visual review noteOnly a parser success is available
  1. Read the format declaration and write its field order in the worksheet.
  2. Recompute a small synthetic fixture in both conventions.
  3. Compare derived bounds while retaining the unmodified source values.
  4. Mark clipping, rounding, and unknown edge rules as findings.
  5. Attach each conversion result to the source artifact and transform record.

Use a box review matrix for disagreements

When two annotators or exports disagree, compare the contract before comparing the object. Keep one row per annotation id and image version. The matrix below is a starting point for a synthetic review; it deliberately avoids deciding whether an object should have been labeled.

Use a box review matrix for disagreements (table)
CheckEvidenceDisposition
Same image id and dimensionsSource id, width, heightCompare geometry or hold identity
Same field conventionxywh, xyxy, normalized, or unknownConvert only with a stated rule
Same transform chainCrop, resize, rotate, pad sequenceReconcile or record a transform gap
Same edge ruleInclusive, half-open, or unknownFlag boundary uncertainty
Same class identityOntology version and label idRoute label issue separately
Same region extentDerived bounds and delta summaryHuman review if difference matters
Source retainedRaw coordinates plus derived recordDo not overwrite source evidence

Keep coordinate evidence scoped and qualified

The arXiv / Cornell University, (opens in a new tab) provides context for object localization and segmentation datasets, but a format reference does not prove that any particular box is accurate or suitable for a use. A coordinate review can establish what was declared, how a derived value was computed, and which ambiguity remains. It cannot establish ownership, permission, privacy, annotation quality, or model performance.

Pair this guide with annotation label ontology versioning for class identity and the data provenance log for image and transform history. After supported non-health scope, authority to describe the collection, and a controlled annotation packet are established, the qualified appraisal request path may be a next preparation step. It does not convert boxes, inspect images, create a quote, match a buyer, issue a legal opinion, or grant a license.

Takeaways

  • Record geometry, origin, units, field order, edge rule, and transforms before comparing coordinates.
  • Keep raw source boxes separate from derived or converted values.
  • Use synthetic round trips to expose field-order and rounding mistakes.
  • Treat clipping, zero extents, and unknown conventions as explicit findings.
  • Separate geometry evidence from label meaning, accuracy, privacy, rights, and intended use.

Sources

  1. arXiv / Cornell University: Microsoft COCO: Common Objects in Context (opens in a new tab)
  2. CVAT Documentation: COCO format (opens in a new tab)

Use the appraisal path after the annotation packet is organized.

It does not convert boxes, inspect images, create a quote, match a buyer, or grant a license.