What is Computer Vision Data?
Annotated image and video data, with annotation types including classification, bounding boxes, segmentation masks, and keypoints.
Computer vision data is images and video with annotations: classification labels, bounding boxes, segmentation masks, or keypoints. The annotation type determines what the data can train, and it is the primary specification item.
The hard part is consistency. Two annotators drawing a box around the same object can differ by a substantial margin, and the difference is larger for masks and keypoints. Cross-checking is not optional here in the way it is for transcription.
The uses range from classification, which needs only a label per image, to instance segmentation, which needs a mask per object. Annotation cost differs by orders of magnitude between them, which is why the type has to be fixed before quoting.
What buyers get wrong
Annotation consistency is harder to guarantee for visual data than for speech. Two annotators drawing a box around the same object can differ by 30%, so cross-checking is mandatory.
The specification detail that decides everything
Annotation type (box, mask, keypoint) and whether occluded samples are included directly determine what the data can be used for.
This is the line item that most often separates a dataset that works from one that gets re-ordered. It belongs in the specification before production starts, not in the delivery review.
How we source it
We do not hold inventory in this category. A requirement comes in, we match it to a producer who can meet the specification, and we agree the quality bar with both sides before recording begins. A pilot batch goes first so misalignments surface early.
Scenarios this covers
Buyers rarely ask for a category by name. They describe a situation, and the situation is what tells us whether this category is the right one. If yours is in the list, name it in the brief and it goes straight into the specification. If it is not, describe it anyway, because it usually means the requirement sits in a neighbouring category.
What good Computer Vision Data looks like
Visual annotation is judged on consistency, and consistency is measured rather than asserted.
-
Annotation type stated precisely
Box, mask, keypoint or label, with the conventions: are occluded objects annotated, are truncated objects annotated, and what is the minimum object size.
-
Inter-annotator agreement measured on the visual task
Box overlap or mask intersection figures, reported per class, because agreement varies enormously by class.
-
Occlusion and truncation policy documented
These are the two decisions that cause the largest disagreement, and leaving them to the annotator produces an inconsistent corpus.
-
Class definitions with boundary cases
What counts as an instance, where one object ends and another begins, and how ambiguous cases are resolved.
-
Negative and background images included
A corpus of only positive examples trains a model that finds the object everywhere.
Public datasets in this category
These are openly documented resources, not products we sell. Each one covers part of the category, and knowing where each stops is usually what decides whether a project needs a collection of its own.
-
ImageNet
The classification benchmark that defined modern computer vision, with over a million images across a thousand classes. Its labels are single-class and its images are curated, which is the opposite of deployment conditions.
-
COCO
Images with object detection, segmentation and caption annotations. It is the standard detection and captioning benchmark and it is small by pretraining standards.
-
Open Images
A large collection with bounding boxes, relationships and localized narratives. The scale and the multiple annotation types make it a common pretraining resource.
-
LAION-5B
A very large image-text pair collection built from web alt-text. The scale enabled a generation of vision-language models and the alt-text quality is highly uneven, which propagates into the models.
Questions to ask a supplier
Questions that establish whether the annotation conventions were decided or left to the annotators.
- What are the exact conventions for occlusion, truncation and minimum size?
- What is the measured inter-annotator agreement, per class?
- How were class boundary cases resolved, and is the resolution documented?
- What proportion of images are negatives or background?
- What is the cross-checking rate, and what happens to a batch that fails it?
The vague answer in this category is about the taxonomy. A supplier who says the corpus is labelled for detection without delivering the class definitions has described a label set rather than an annotation scheme. Boundary cases are resolved differently by each annotator unless the rules are written down.
A verifiable answer includes the taxonomy with its boundary rules, the annotator count and the agreement between them, and the class distribution. Ask for the distribution rather than the class list, because a list says nothing about how often each class occurs, and the rare classes are the ones deployment meets.
Technical attributes
The items below are the ones a specification can hold a producer to, and the ones that decide whether a delivery is usable for training rather than only present.
| Annotation type | Classification, box, mask, or keypoint |
|---|---|
| Occlusion policy | Documented, applied consistently |
| Truncation policy | Documented, applied consistently |
| Inter-annotator agreement | Measured, reported per class |
| Negatives included | Proportion stated |
| Delivery format | Images with annotations in a named format, plus the guideline document |
The annotation taxonomy column decides the label noise floor, and it is the one most often delivered as a class list. A taxonomy without boundary rules produces systematic noise that is consistent within each annotator and inconsistent across them. No amount of training removes that, because the labels disagree with each other.
The values come from the deployment scene. Indoor retail, outdoor traffic and industrial inspection have different class sets, different object scales and different occlusion patterns. The specification should describe the scene, because the supplier cannot derive it from the phrase computer vision.
A mistake here is discovered as a long-tail failure. A corpus with a flat-looking distribution usually had its rare classes under-sampled, and those are exactly the cases the deployed system encounters. Recovering them means targeted collection, since the images were never captured.
How Computer Vision Data is collected
The guideline is written before annotation, and the hard cases are decided in it rather than during it.
- Class definition and boundary cases. The class list is written with the ambiguous cases resolved in the document, because those are where annotators diverge.
- Annotation convention setting. Occlusion, truncation and minimum size are fixed as rules, and the rules are tested on a pilot batch before the main run.
- Pilot annotation and agreement measurement. A pilot batch is annotated by several annotators, agreement is measured, and the guideline is revised where it is low.
- Main annotation with cross-checking. A defined proportion of the output is re-annotated or reviewed, and batches that fail the threshold are reworked rather than accepted.
- Agreement reporting and delivery. Per-class agreement figures and the guideline document are delivered with the annotations.
After annotation, the labels go through a consistency review, the agreement figure is computed, and the files are packaged with the taxonomy, the class distribution and the per-image provenance. The agreement figure is what tells a buyer how much of the label noise is systematic.
The pilot for vision data is a small annotated set covering the boundary cases in the taxonomy, run before the full annotation, because the property being tested is whether the boundary rules resolve the cases the annotators will actually meet. A pilot over the edges shows the agreement between annotators, and that figure is what the full batch is then specified against. A pilot over easy examples shows nothing.
Acceptance is checked on the agreement figure and on the class distribution, both against figures stated before annotation starts. The specification should include the taxonomy with its boundary rules before the run. Where the pilot shows low agreement, the taxonomy is rewritten and the pilot re-annotated rather than the tolerance lowered, since label noise that is consistent within each annotator cannot be trained away.
How a delivery goes wrong
The defects below are the ones that recur across this category. Each is decided at collection or annotation time, which is why none of them can be repaired in delivery review.
-
Annotation taxonomy was not delivered
A class list without boundary-case definitions produces annotators who each resolve ambiguity differently. The resulting corpus has systematic label noise that no amount of training fixes.
-
Long-tail classes were sampled away
Rare classes are expensive to annotate and easy to under-sample. A corpus with a flat-looking class distribution usually means the rare cases were dropped, and they are the ones deployment meets.
-
Image rights were not traced
Images collected from the web carry rights that are not transferred by downloading. A corpus without per-image provenance cannot be filtered if a source turns out to be restricted.
Why this matters to buyers
Annotation consistency sets the ceiling on what a model can learn. A corpus with inconsistent boxes teaches the model the inconsistency, and no amount of additional data fixes a label set that disagrees with itself.
The second driver is cost predictability. The annotation type determines the cost by orders of magnitude, and a project that changes from boxes to masks after quoting has changed the project rather than the specification.
A detection model trained on a corpus with an undocumented taxonomy fails on the boundary cases that decide whether the product is usable. The failures look like model errors and are actually label disagreements, so the team spends its time on architecture. The corpus cannot be corrected without re-annotating it.
The second cost is rights. Images collected from the web carry rights that are not transferred by downloading, and a corpus without per-image provenance cannot be filtered if a source turns out to be restricted. Withdrawing a deployed model costs far more than tracing provenance at collection time.
A vision corpus with a documented taxonomy and a measured agreement figure gives a label noise floor the team can plan against. The rare classes are present at known rates, so deployment failures on those classes are predicted rather than discovered, and the boundary cases behave consistently.
The second gain is per-image provenance. Image rights are not transferred by downloading, and a delivery that records the source per image can be filtered if a source turns out to be restricted. That record is what keeps a deployed model from having to be withdrawn.
Specification at a glance
| Category | Computer Vision Data |
|---|---|
| Group | Non-speech data |
| Critical spec | Annotation type (box, mask, keypoint) and whether occluded samples are included directly determine what the data can be used for. |
| Included by default | Pilot batch, metadata schema, source and consent documentation |
| Pricing | Quoted from specification. No published rates |
Related categories
-
LLM Training Data
Text corpora for LLM pretraining and fine-tuning: instruction data, preference data, and multi-turn dialogue data.
-
NLP Data
Annotated text for NLP tasks: named entities, dependency syntax, sentiment polarity, and relation extraction.
-
Multilingual Language Data
Parallel or non-parallel text corpora spanning multiple languages, used for multilingual models and low-resource language research.
-
Translation Data
Parallel corpora pairing source and target language, used for machine translation training and evaluation.
-
Dictionary Data
Structured dictionary entries with definitions, parts of speech, pronunciation, and example sentences, used for dictionary products and lexical understanding tasks.
-
Text Data
General-purpose text corpora from web pages, forums, reviews and similar sources, used for language model pretraining and text classification.
Questions about Computer Vision Data
Why is agreement measured per class?
Because it varies enormously by class. Agreement on a large, well-defined object is high; agreement on a small, partially hidden one is low. A single pooled figure averages the easy classes with the hard ones and hides where the corpus is weak.
How should occluded objects be handled?
By a written rule applied without exception. The two common choices are annotating the visible extent or the estimated full extent, and both are workable. What is not workable is leaving it to the annotator, because half will do each.
Do we need negative images?
Yes, unless the deployment genuinely never contains an empty scene. A corpus of only positives trains a detector that finds the object in every image, and the negatives are what teach it restraint.
What does cross-checking involve?
Re-annotating or reviewing a defined proportion of the output and comparing against the first pass. The rate is stated in the specification, and a batch that fails the threshold is reworked rather than accepted with a note.
Do you have Computer Vision Data available now?
No. We do not hold inventory. Everything is produced against a specification. That means the timeline starts when the spec is agreed rather than immediately, and it also means the data matches your requirement instead of approximately matching something already built.
Can this be combined with other categories in one delivery?
Yes, and it is common. A single specification can cover several categories across several languages, with one pilot batch and one quality bar. It usually reduces total cost because contributor recruitment and project setup are shared.
What does the consent documentation cover?
Signed contributor consent stating the intended use, the collection methodology, and the annotation guideline the data was produced under. For projects involving EU data subjects the chain is built to satisfy GDPR, including the transfer mechanism. The terms for moving the data across a border.
Request Computer Vision Data
Tell us the language, the hours, and what the data needs to look like. You will get a real number and a real timeline, not a range. If we cannot source it well, we will tell you that instead.
- Pilot batch before the full run, so problems surface early.
- Consent documentation delivered with the data.
- No medical or clinical data. No recorded telephone calls.
- You send the spec Language, hours, recording conditions, and the deadline.
- We reply within two business days A real number and a real timeline, not a range.
- You approve a pilot batch A small run first, so problems surface before the full order.
- Full run, then delivery with documents Audio, transcripts, and the consent record for every speaker.