Urban intersection with road signs, traffic lights, vehicles and a pedestrian

From model task to accepted label file

Image labels
your model team
can specify and accept

Bring the model task and source-image conditions. YPAI scopes the label type, task rules, review method, acceptance requirement and output format as one delivery decision.

You buy image-label files in the agreed output format, reviewed against the acceptance criteria in the project scope.

Send your annotation brief
Model task What must the model decide?
Visible boundary Which geometry preserves it?
Review rule What happens when the case is unclear?
Label file Which agreed output is accepted?
Output grammar

What must the label file preserve?

Choose the output by the decision your model has to make. One frame, four choices, and four different things that survive into the file.

Source frame · 1586 × 992 Illustrative annotation specimen · 3× display derivative
Machine-vision cell: a robot arm above a conveyor carrying machined aluminium brackets, a red safety housing and a cable hose
1 Classification · scene 2 Box · safety housing 3 Polygon · bracket + bore 4 Keypoints · tool axis
  • 1 Classification

    One class for the whole frame. Nothing about where the part is survives.

  • 2 Box

    Extent and position survive. The machined shape does not.

  • 3 Polygon

    The cut boundary survives, and the bore is carried as its own region.

  • 4 Keypoints

    Named landmarks only. Here, the three points of the tool axis. The dotted outline is context for reading them, not part of the label.

The annotation coordinate frame is 1586 × 992, and every coordinate in the chapters below is absolute in it. The photograph is rendered from a deterministic 3× display derivative of that same illustrative frame, so a region still carries pixels on a high-density screen. The derivative is a resample for display. It adds no source detail and it does not move the coordinate space.

Edge cases

Difficult images need explicit rules

Use your sample to name the cases that could change a label. The guideline then states what counts, when a reviewer steps in and which cases move to adjudication. All four regions below are read from the one frame above, each at its own origin, and none is shown above the pixels its rendering carries.

Key map of the whole 1586 by 992 source frame with region 1, thin geometry, outlined at origin 781, 287
1
Frame 1586 × 992 origin 781, 287 560 × 350
Region 781, 287 of the source frame: a cable hose traced as a path, inside the dashed box a box annotation would produce
1 Thin geometry

A hose is not its bounding box.

Traced as a path that carries its own width. The dashed box the same object would get is mostly belt. polyline · width 18

Key map of the whole 1586 by 992 source frame with region 2, low contrast, outlined at origin 737, 170
2
Frame 1586 × 992 origin 737, 170 560 × 350
Region 737, 170 of the source frame: a dark machined tool outlined against a dark cell
2 Low contrast

Dark machined metal against a dark cell.

The boundary follows the tool silhouette, flange top included, not the specular highlight down the barrel. mask

Key map of the whole 1586 by 992 source frame with region 3, occlusion, outlined at origin 700, 426
3
Frame 1586 × 992 origin 700, 426 560 × 350
Region 700, 426 of the source frame: the traced hose stopping where a machined block hides it
3 Occlusion

Label what is visible. Record what is hidden.

The run stops at the block edge. Nothing behind the block is drawn, so the hidden part stays a flag and never a guess. occluded: true

Key map of the whole 1586 by 992 source frame with region 4, interior void, outlined at origin 378, 622
4
Frame 1586 × 992 origin 378, 622 560 × 350
Region 378, 622 of the source frame: a machined bracket outlined with its bore carried as a separate region
4 Interior void

The bore belongs to the scene, not to the bracket.

Carried as its own region so the mask of the part is not quietly filled in. category: bore

Acceptance method

How will the batch be accepted?

Agree the acceptance requirement before production. The pilot is where an observed result can be measured against it.

Every item leaves review in one of three states, decided against a requirement that was agreed before production, never after.

The agreed requirement names
  • The annotation type, and the geometry it has to produce.
  • The rule for each difficult case your data actually contains.
  • The review method that decides an item, and who adjudicates.
  • The sample the requirement was fixed against before production.
  • The output format the label files are delivered in.
Review can use
  • Human verification
  • Dual annotation
  • Specialist review
  • Agreement analysis
  • Sampling
  • Task-specific quality gates

Which of these applies is a scoping decision for your workload.

  • Accepted

    The item meets the requirement agreed in the project scope.

  • Returned for rework

    The item goes back with the failing rule named, not a score.

  • Escalated

    The rule itself did not decide the case. It is still open, and it moves to adjudication.

CaseRuleReviewer steps in when
Thin geometry Rule Path with width, never a box. Reviewer steps in when Endpoints are ambiguous.
Low contrast Rule Silhouette, not the highlight. Reviewer steps in when Two annotators disagree on the edge.
Occlusion Rule Visible extent only, hidden run flagged. Reviewer steps in when The hidden share passes the agreed limit.
Interior void Rule The bore is its own region. Reviewer steps in when No void class exists in the ontology yet.
Small instance Rule Below the agreed minimum size. Reviewer steps in when Always. It is never dropped silently.

The first four rows are the cases in the frame above. Small instance is listed with them because a size floor is agreed in scoping even when the sample frame you send does not happen to contain one.

File correspondence

The label files come first

The scope names the output format and the acceptance criteria for the label files. Everything else in the record is qualified by that scope.

Region 318, 364 · 560 × 350 Never above rendered scale
The red safety housing from the source frame, outlined, with three recorded vertex coordinates called out
501, 482 694, 479 615, 609
364 470 Bbox
extent
609 714
  • source image 1586 × 992 whole frame
  • shown region 318, 364 560 × 350
  • category 1 safety_housing one instance
  • bbox 501, 470, 195, 139 safety housing
  • segmentation 17 points visible extent
  • keypoint 1 501, 482 top left
  • keypoint 2 694, 479 top right
  • keypoint 3 615, 609 front bottom

Every coordinate here is absolute in the 1586 × 992 frame, never in the view above. That view begins at 318, 364, so keypoint 1 at 501, 482 sits 183 px right and 118 px down from its top-left corner. The values read off the frame are the values in the file, and that correspondence is the thing being bought. The cable gland crossing the left face sits outside the polygon, so the record carries the visible extent and not an assumed rectangle.

COCO JSON Primary artifact
{
  "images": [
    { "id": 1, "width": 1586, "height": 992 }
  ],
  "annotations": [
    {
      "id": 1,
      "image_id": 1,
      "category_id": 1,
      "bbox": [501, 470, 195, 139],
      "segmentation": [[
        501, 482, 511, 477, 571, 472,
        629, 470, 689, 473, 694, 479,
        696, 556, 686, 564, 685, 593,
        615, 609, 612, 578, 559, 577,
        513, 571, 542, 564, 547, 545,
        536, 533, 501, 536
      ]],
      "keypoints": [
        501, 482, 2,
        694, 479, 2,
        615, 609, 2
      ],
      "num_keypoints": 3,
      "iscrowd": 0
    }
  ],
  "categories": [
    {
      "id": 1,
      "name": "safety_housing",
      "keypoints": [
        "top_left", "top_right", "front_bottom"
      ]
    }
  ]
}
Also available Pascal VOC XML Custom output agreed in scoping

If your review requires them, the same scope can add the relevant specification, reviewer record, acceptance record, manifest, version history or change record.

Scope to delivery

From your brief to accepted files

Tell us the source data status, model task, required annotation type, approximate volume, difficult cases, file format, application domain, target timing and acceptance requirement. If part of the specification is unclear, say so.

1 You send a sample
Region 318, 364 of the source frame with no annotation: the red safety housing as it arrives
One frame from your own data, with the model task and the difficult cases named. Nothing is annotated until the rules are drafted against it.
2 One agreed sample
The same region under the agreed annotation: bounding box, traced polygon and three named keypoints
The same region under the annotation type and the case rules you agreed. This is the sample the acceptance requirement is fixed against, before any production work starts.
3 Label files return
Label file
COCO JSON
Coordinates
Absolute in 1586 × 992
Carried
Bbox · 17-point polygon · 3 keypoints
Per item
The state it left review in
What comes back, in the format agreed in scoping. Every item carries the state review left it in, so a returned batch can be read without asking what was decided.
Do not send

Image files, private storage links, credentials or confidential datasets in the initial form.

Send the brief for one workload. We reply with the questions your specification leaves open, and what a first agreed sample would have to settle before production.

Include the use case, target objects or classes, difficult cases and any known acceptance method.

YPAI uses the submitted information to review and respond to the image-annotation brief. Do not include image files, credentials or private storage links. Read the privacy notice.

Use general commercial contact

Opening photograph: Turning vehicles yield to pedestrians by Erica Fischer, licensed under CC BY 2.0.

FAQ

Frequently asked questions

What image annotation tasks does YPAI deliver?

YPAI delivers 2D bounding boxes, oriented (rotated) boxes, polygon and instance segmentation, semantic segmentation, keypoint and skeleton annotation, image classification with hierarchical taxonomies, OCR ground truth, and document layout markup. Specialised verticals (medical imaging on DICOM, satellite and aerial, robotics bin-picking) ship with reviewer pools recruited for the modality.

Which image formats and storage targets does YPAI support?

Deliveries are shipped in COCO, YOLO, PASCAL VOC, custom JSON, GeoJSON for geospatial, and DICOM-segmented overlays for medical imaging. Storage targets include AWS S3, Azure Blob, GCP, customer-hosted S3-compatible (MinIO, Ceph) and direct-to-VPC drops. Custom format translation is part of the delivery pipeline, not a post-hoc consulting line.

Can YPAI annotate medical imaging (DICOM, NIfTI)?

Yes. Medical imaging is handled by clinician reviewers contracted for the specific modality (radiology, pathology, dermatology). Data is processed inside EU residency under GDPR Article 9 special-category controls. The controls in place for a given engagement are documented in the statement of work.

How does YPAI handle large-scale annotation backlogs?

Capacity scales with reviewer recruitment, not with crowd-marketplace dispatch. For multi-million-image backlogs the engagement runs in staggered waves with continuous IAA monitoring, so quality drift is caught at the batch boundary rather than at delivery. Active-learning loops are common at this scale to keep human attention on the lowest-confidence examples.

What inter-annotator agreement does YPAI report?

Each batch ships with task-appropriate IAA: Cohen kappa on classification, IoU and mAP on bounding boxes, Dice on segmentation, OKS on keypoints. Targets are set in the SOW per task and per class; underperforming classes trigger re-calibration before bulk progress continues. The IAA report is part of the deliverable, not an audit-only artefact.

Does YPAI provide active-learning or model-in-the-loop image annotation?

Yes. Where the customer has a working baseline model that can be queried EU-locally, YPAI runs human review over model pre-predictions and prioritises low-confidence or high-impact slices. The loop feeds into retraining batches. Hosting patterns (synchronous API, asynchronous batch queue, customer-on-prem) are confirmed during scoping.

Can YPAI annotate inside our perimeter for sensitive imagery?

Yes. For regulated healthcare, public-sector, and critical-infrastructure engagements where third-party processors are not acceptable, the annotation tooling and reviewer access can run inside the customer perimeter (EU regional cloud, on-prem rack, customer VPN). Specific feasibility is confirmed in the scoping document and the controls are written into the DPA.