--- title: "Image annotation: label files you specify and accept | YPAI" url: https://ypai.ai/annotation/image-annotation/ description: "Bring the model task and source-image conditions. YPAI scopes the label type, task rules, review method, acceptance requirement and output format." source: "src/copy/routes (route /annotation/image-annotation/)" --- # 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. Street photograph with a polygon annotation identifying a traffic sign From model task to accepted label file 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. - **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? ## 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 - One class for the whole frame. Nothing about where the part is survives. - Extent and position survive. The machined shape does not. - The cut boundary survives, and the bore is carried as its own region. - 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. ## 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. - A hose is not its bounding box. - Traced as a path that carries its own width. A box around the same hose, shown dashed, would be mostly conveyor belt. - Dark machined metal against a dark cell. - The boundary follows the tool silhouette, flange top included, not the specular highlight down the barrel. - Label what is visible. Record what is hidden. - The run stops at the block edge. The hidden part is carried as a flag. - The bore belongs to the scene, not to the bracket. - Carried as its own region, so the mask of the part keeps its opening. ## 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 ### The review record for this decision This is the record kept for each decision. The reviewer sees the asset, the instructions and the evidence, and a pseudonymous reviewer reference. - 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. Which of these applies is a scoping decision for your workload. - The item meets the requirement agreed in the project scope. - The item goes back with the failing rule named, not a score. - The rule itself did not decide the case. It is still open, and it moves to adjudication. - Path with width, never a box. - Two annotators disagree on the edge. - Visible extent only, hidden run flagged. - The hidden share passes the agreed limit. - The bore is its own region. - No void class exists in the ontology yet. - 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. ## 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 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 The ypai block in the file carries the review record: which vertices the model drew, which a person moved, and who decided. Your schema can rename it. 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. If your review requires them, the same scope can add the relevant specification, reviewer record, acceptance record, manifest, version history or change record. ## The labels your vision model needs Choose the output by what your model must decide. YPAI scopes the geometry, the case rules, the review method and the file format together. ### Object detection - Locates each object and keeps its extent for the task the model learns. ### Polygons and segmentation - Defines the boundaries and regions the task needs, difficult edges and separate instances included. - polygons · semantic and instance masks ### Keypoints and pose - Marks named landmarks and the structure that connects them. ### Image classification - Settles the image-level decision with the classes and taxonomy agreed for the workload. ### OCR and document layout - Ground truth for reading text and for the structure of a document. - OCR ground truth · layout annotation ### Quality review - Checks labels against the requirement and decides the cases that need a person. - review · agreement analysis · adjudication ## Agree the rules. Calibrate the sample. Deliver the labels. ### Scope the workload - Model task, source-image conditions, ontology, access and output format. ### Calibrate the sample - The difficult-case rules and the acceptance plan, set against representative images. - A reference sample and the guideline ### Annotate and review - A model's first pass where it helps, SAM 3 from a text prompt or an edge model from a point, then human review, calibration, agreement analysis and adjudication by a named reviewer. ### Validate and deliver - The label files checked against the agreed schema and acceptance criteria. - Label files and the agreed records Human QA is applied according to the agreed acceptance and sampling plan. Approved sample transfer follows the initial brief through an agreed channel. ## The platform behind your annotation project YPAI operates its own bespoke, GDPR-native data collection and assurance platform. Customer specifications and agreements become executable controls across sourcing, collection, technical validation, consent, human review, rights, dataset assembly and delivery. Every accepted asset is linked to the evidence of why it passed. The native review console connects the image, the guideline, the reviewer's decision and the supporting evidence. - **Specification**: Your requirement, ontology and acceptance criteria, as written. - **Controls**: Turned into executable checks on every item. - **Annotation and review**: A model's first pass, then a named reviewer, in the console. - **Evidence**: Each decision bound to reviewer, rubric version, reason code and time. - **Delivery**: Label files and records your team can verify. ### Specialist review, with responsibility attached A senior-led managed operation from Lysaker, Norway. An internal annotation and QA team holds the reference set and the review; contributors are qualified for the project. Clinician reviewers are contracted for medical modalities. A 210,000+ contributor network across 50+ countries supports project-specific recruitment. Review runs in YPAI's own console. Around it, the leading annotation platforms are set up for each project as adapters, self-hosted CVAT and Label Studio among them, on YPAI's European annotation servers or inside your perimeter for regulated imagery. - Norwegian company, EEA residency by default - Data residency, subprocessors and transfer controls defined per project, SCCs available - Standard DPA terms under Article 28, per-contributor consent - EU AI Act Article 10 documentation supporting your conformity assessment ## Files your model team can use and accept The scope names the annotation schema, the output format and the acceptance criteria. The label file and its record describe the same item. COCO JSON · Pascal VOC XML · YOLO TXT · custom format agreed in scoping - **Output**: The agreed annotation type, in the frame's absolute coordinates - **Schema**: Your classes, geometry and file format - **Review**: The item's decision and the record behind it - **Records**: Specification, reviewer and acceptance records, manifest, version history and change record, as agreed in the project scope Region 318, 364 of the source frame under the agreed annotation: the safety housing with its box, polygon and three keypoints ## For a more specialised workload - tracking, actions, pose and video object segmentation - [Video annotation](https://ypai.ai/annotation/video-annotation-services/) - [Semantic segmentation](https://ypai.ai/annotation/semantic-segmentation-annotation-services/) - [Medical imaging](https://ypai.ai/annotation/medical-imaging-annotation-services/) - [Robotics and industrial vision](https://ypai.ai/annotation/robotics-industrial-vision-annotation-services/) - [LiDAR and 3D point cloud](https://ypai.ai/annotation/lidar-3d-point-cloud-annotation-services/) - a broader annotation programme under one quality regime - [All six modalities](https://ypai.ai/ai-data-annotation/) ## 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. - One frame from your own data, with the model task and the difficult cases named. Annotation starts once the rules are drafted against it. - 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. - **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. Image files, storage links, credentials and datasets follow through a secure channel agreed in our reply. 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. YPAI reviews the workload and identifies the remaining inputs needed for scoping. 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 ## 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 delivery. ## 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. 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 ships with every batch. ## 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 agreed 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 set out in the scoping document and the controls are written into the DPA.