---
title: "Image Data Collection and Evaluation | YPAI"
url: https://ypai.ai/image-data/
description: "Managed image collection for models that must hold across light, device, viewpoint and population. Every image leaves with its coverage and its rights record."
source: "src/copy/routes (route /image-data/)"
---

# One photograph is a point. Your model lives in a space.

> Managed image collection for models that must hold across light, device, viewpoint and population. Every image leaves with its coverage and its rights record.

We collect images against the task your model has to solve: specified coverage, every frame measured, every visible person's rights recorded.

YPAI designs and runs managed image collection programmes: subject, cohort, device, light and viewpoint specified before the first capture, every frame measured and reviewed against that specification, and delivered with the coverage, quality and rights record for every image.

## One requirement becomes one accountable image operation

Model task, subject, cohort, device, light and acceptance criteria are written before capture. The same specification is what every image is reviewed against, and what the delivery record documents.

### Specification

- The model task sets the subject, the cohort, the devices, the conditions matrix and the acceptance criteria, before anyone photographs.
- **Coverage**: Light, device, viewpoint and population, agreed per cell before capture
- **Acceptance**: Criteria written before work starts

### Capture

- Images captured under the specified conditions
- Identity-verified contributors photograph under the specified conditions; the device tier, native resolution and metadata are fixed in the specification.
- **Device**: Tier and native sensor named per cell
- **Metadata**: EXIF kept

### Quality gates

- Each image accepted, or returned with a reason
- Every frame is checked for blur, exposure, dynamic range, duplicates and manipulation. Human review against the specification follows the agreed acceptance and sampling plan; a rejected image returns with its reason.
- **Review**: Native reviewer on sampled work
- **Verdict**: Accepted, or returned with a reason

### Delivery

- The set delivered with its record
- Accepted images leave with their metadata, readings, rights and provenance record, acceptance report, checksums and a manifest with Croissant metadata.
- **Record**: Coverage cell, readings and rights per image
- **Package**: Checksums

Capture specifications, device tiers and reshoot terms are defined in the statement of work.

under 3: a near-duplicate of the first image

## Start from the condition your model has not seen

Nine programmes YPAI runs, and four adjacent kinds of work with their own pages. Each programme names the coverage it delivers; open it for the problem, the delivery and the annotation it hands off to.

### Collection at scale

- The images your model needs do not exist, or miss the conditions it will meet.
- Subject-based, quota-managed capture across countries, devices, light and viewpoint, remote or moderated, with reshoot workflows and delivery manifests. Image-text pairs for vision-language models are collected here and captioned as annotation work.
- Coverage is specified per cell before volume is counted.
- The same subject under every condition it will be seen in.
- [Classification](https://ypai.ai/annotation/image-annotation/)

### Rare events, edge cases and evaluation sets

- The case your model has not seen is the one it will meet, and public benchmarks rarely document where their images came from.
- Held-out evaluation and robustness sets collected to a written matrix of conditions, populations and rare cases, with the record an assessor can open: origin, coverage, readings and rights per image, delivered in Croissant, the open metadata format for ML datasets.
- An evaluation set with its coverage and its rights documented per image.
- A model is tested on the space, not on the point it was trained at.
- [Failure analysis and robustness evaluation](https://ypai.ai/data-solutions/evaluation/)

### Face, demographic and geographic coverage

- Faces, liveness and cohorts across skin tone, age and place, with a consent record that survives a review.
- Quota-managed cohorts, identity-verified, photographed across devices, light and viewpoint, with consent and permitted use bound to every image and every visible person. Every image is captured opt-in; untargeted scraping of facial images is prohibited.
- Consent per visible person on the image itself, from an identity-verified network.
- A face is a person before it is a sample; the record says who agreed to what.
- [Attribute labels and representativeness review](https://ypai.ai/data-solutions/evaluation/)

### Document and form capture

- Mobile OCR fails on the pages people actually photograph, with glare, skew, shadow and a fold.
- Receipts, forms, identity documents and pages photographed on the device tiers the product will meet, under the light it will meet, with EXIF kept and blur, exposure and compression read per image. Each page is photographed the way the product's users capture it.
- Real device artefacts on real pages, read per frame.
- A page is an image first; the glare and the skew are the data.
- [OCR and document understanding](https://ypai.ai/document-ai-workflow-automation/)

### Industrial and inspection imagery

- The defect is rare on the line and the synthetic copy of it lacks the sensor's noise.
- Parts, surfaces and assemblies photographed on line cameras and phones, lit from the directions the inspection will use, with and without the defect, at the distances the model will see. Proprietary imagery stays on EEA infrastructure with a self-hosted review console.
- Rare defects captured on purpose, on the sensor that will inspect them.
- The defect is rare on the line and common in the set.
- [Defect labels and agreement](https://ypai.ai/annotation/image-annotation/)

### Multi-view and product imagery

- Product recognition, try-on and shelf models need one object from every angle and every packaging.
- Products, garments and shelves photographed multi-view under the same light, on the devices the deployment will use, as one matched set. Shelf capture in the wild is deduplicated by perceptual hash before it is counted.
- One matched set per object; duplicates are removed before delivery.
- One object, every angle, the same light.
- [Keypoints and view-consistent labels](https://ypai.ai/annotation/image-annotation/)

### Environment-specific capture

- Light, weather and place decide whether the model holds, and a web crawl has none of them on purpose.
- Streets, cabins, homes, workplaces and stores photographed under the light, weather and season the deployment will meet, Nordic winter included. Coverage per condition is specified and delivered in the record.
- Weather and light are cells in the sheet, specified before capture.
- Light, weather and place are specified per cell.
- [Scene and condition labels](https://ypai.ai/annotation/image-annotation/)

### Device-specific corpora

- The model ships on a sensor it was never trained on.
- The same subject captured on the device tiers the product will meet, smartphone tier, webcam tier, line and industrial camera, with native resolution, EXIF and compression history recorded per image so cross-device evaluation reads from the record.
- The sensor is a condition in the sheet, with its metadata kept.
- Smartphone tier, webcam tier, line camera; the sensor is a condition.
- [Cross-device evaluation](https://ypai.ai/data-solutions/evaluation/)

### Licensed image datasets

- The deadline does not allow custom collection, or a rights review failed on the set you have.
- Existing inventory identified, sourced through partners, sampled and technically reviewed, rights checked, licensed, packaged and delivered. License what exists and collect only what is missing.
- Chain of title and permitted use are checked before a sample is shared.
- A licensed set carries its provenance, or it is not delivered.
- [Annotation documented per set](https://ypai.ai/annotation/image-annotation/)
- Adjacent work with its own page

### [Geospatial and aerial imagery](https://ypai.ai/geospatial-data-solutions/)

- Aerial and satellite frames need the pose, the coordinate system and the rights that place them.
- Geospatial programmes have their own page: imagery preparation, metadata, annotation and the QA package for aerial and satellite capture.

### [Image annotation and evaluation](https://ypai.ai/annotation/image-annotation/)

- Boxes, masks, keypoints and attributes on images you already hold.
- Classification, detection, semantic and instance segmentation, keypoints and visual attributes, with quality review, agreement analysis and adjudication.

### [Video data](https://ypai.ai/video-data/)

- The decision lives between frames, not in one.
- Video programmes have their own hub: the take, the sequence and the frame rate the task needs, with the record per recording.

### 3D, depth and sensor data

- Point clouds, depth and multi-sensor rigs, calibrated and time-synchronised.
- LiDAR, depth, IMU and multi-camera capture with calibration and synchronisation as part of the delivery. Its hub is being built; until then, scope it here.
- Multi-modal capture, image with text, audio or sensor streams
- Skin and wound imagery on smartphones, with consent and permitted use agreed per engagement
- Gap-fill against images you already own

Working with a subject not listed here?

Describe the deployment and the conditions it runs under, and YPAI designs the capture protocol.

## Four axes decide whether an image survives deployment

You name the range your deployment has to hold. The programme is built to span it, and every image lands with its coverage cell in its record.

- Exposure is a condition, not a defect. The range is written into the specification and read on every frame.
- The sensor, the lens and the compression are part of the sample, so the device tier is a cell in the sheet.
- Native resolution, EXIF and compression history kept
- The same subject from where the model will see it, at the distances it will see it.
- Quota-managed cohorts and specified places, with the rights for every visible person recorded.
- Age range, gender identity, skin tone

Coverage is agreed before capture begins and delivered as part of the record. Where a required range cannot be covered, YPAI says so at scoping.

The reading on each frame is taken from the frame itself: sharpness as the variance of the Laplacian, exposure as the share of pixels under 64 and over 235 on the 0 to 255 luma scale. Device, lens and metadata are conditions the specification names and the record holds; the platform takes these readings on every image it accepts.

## Every image carries its own evidence

Provenance-aware sets for teams training on real images and defending against generated ones. The record travels with the file.

### Source evidence per image

- Capture metadata, EXIF where present and a checksum for every delivered asset, with lineage from source to derivative.

### Compression history and manipulation

- Compression history and manipulation checks are read on every frame; generated or edited images are excluded from a real-image delivery or delivered as a labelled set on request.

### Duplicates and near-duplicates

- Perceptual-hash distance to every other image in the set is read before an image is counted.

## We built the system behind the data.

YPAI runs its own data collection and assurance platform, built for GDPR obligations, across speech, video, image, text, human feedback, agents, robotics and other multimodal programmes.

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 for why it passed.

The chain, for one image asset

- **Specification**: Your specification and the signed agreements become the project the platform runs against
- **Source**: Contributor and device qualified before the first capture
- **Collection**: Conditions controlled at capture, in the browser, on device or on site
- **Quality**: Real-time edge control, then central automated validation, then qualified human review
- **Agreements**: Consent and agreement state bound to the asset, statement by statement
- **Rights**: Permitted use enforced by the platform, per asset
- **Dataset**: Constraint-based assembly against the contract
- **Delivery**: Signed delivery or controlled model access
- **Verification**: Data Assurance Record per asset, independently verifiable

What the platform measures on every image

- Sensor and lens, native resolution and EXIF
- Geographic metadata, facial and biometric rights
- **Identity**: Asset, modality and schema version
- **Contract**: The requirements it was collected against, and its cell in the coverage
- **Origin**: Source, device, sensor and lens, EXIF, environment and time of capture
- **Quality**: Blur, exposure, dynamic range, duplicate distance and the human verdict
- **Integrity**: Compression history, manipulation check and checksum
- **Agreements**: Applicable statements, their hashes and signatures
- **Privacy**: Processing purpose, legal state and data categories; consent per visible person

Built by YPAI. Built for GDPR. Documented image by image.

Attributes are declared by the person, never read from the face.

## The record your legal and security review will ask for

The operation produces the governance artefacts as it runs. Depth and format follow your risk profile and are agreed during scoping.

The review asks · the record answers

Where a person is in the frame, the consent record travels with the image.

- **Legal basis**: What is the legal basis for each image?. Consent, legitimate interest or contractual necessity, documented per image
- **Consent**: Can you show consent, per person in the frame, and what happens on withdrawal?. A traceable rights and consent record linked to each contributor, image and delivered asset where participant consent is the applicable basis, with withdrawal status; withdrawal runs through a workflow with an audit trail
- **Biometric**: How are faces and biometric data handled?. Facial images used for identification are special-category data under GDPR Article 9 and are collected only by opt-in capture with explicit consent; no scraping, in line with the AI Act's prohibition on untargeted facial scraping
- **Rights**: What may the images be used for, and by whom?. Permitted use, release and licence scope defined per engagement; reuse by explicit written grant
- **Provenance**: Where did each image come from?. Provenance per image, capture metadata, EXIF and checksum, lineage from source to derivative
- **Residency**: Where do the images reside, and under whose jurisdiction?. EEA infrastructure by default, Norwegian jurisdiction; EEA-only sourcing on request
- **Retention**: What happens to the images when the engagement ends?. Erasure within 30 days of contract end; retention and closeout defined in the engagement
- **Agreements**: What governs the engagement on paper?. DPA signed, SCCs available for cross-border transfer

Questions buyers ask before scoping an image programme

## What is the difference between image data collection and buying an existing image dataset?

A collection programme starts from the conditions your model has to hold: the light, the device tier, the viewpoint and the population are written into a specification before anyone photographs, and every delivered image carries the coverage cell it was captured against. An existing set is fixed at whatever its original purpose was. YPAI does both; licensed inventory and gap-fill sourcing live on <a href="/dataset-licensing/">dataset licensing</a>.

## How is coverage specified, and what happens if a condition cannot be covered?

Coverage is agreed per cell across four axes, light, optics, viewpoint, and people and place, before capture begins, and it is delivered as part of the record. Where a required range cannot be covered, YPAI says so at scoping rather than delivering a thin cell.

## What is checked on every image, and who reviews it?

Every frame is checked for blur, exposure, dynamic range, duplicates and manipulation. Human review against the specification follows the agreed acceptance and sampling plan. A rejected image returns with its reason. The platform records the reading and the verdict for each image, and the reviewer for each image a person reviewed.

## How are the rights for people in the frame handled?

Contributors are identity-verified, and consent is recorded per visible person, with the processing purpose, the legal state and the data categories in the image's record. Attributes such as age range, gender identity and skin tone are declared by the person, never inferred from the face.

## Where is the data processed, and what happens to it after the contract ends?

EEA processing is available by default, Article 28 data processing terms are available, and standard contractual clauses cover any cross-border transfer. Erasure follows within 30 days of contract end.

## What ships with a delivery?

Accepted images leave with their metadata, readings, rights and provenance record, the acceptance report, checksums and a versioned manifest in Croissant, so a dataset can be audited after the fact rather than described.

## Does this route cover video, point clouds or annotation?

This route owns still images. Sequences are on <a href="/video-data/">video data</a>, point clouds, depth and multi-sensor rigs on <a href="/image-3d-sensor-data/">image, 3D and sensor data</a>, and marking up images you already hold on <a href="/annotation/image-annotation/">image annotation</a>.

## Bring the coverage problem. Leave with a capture plan and an acceptance proposal.

Technical assessment inside one EU business day.

### Describe the system

- Model task, subject, cohort or geography, devices, scale and timeline.

### Feasibility read

- Capture plan, conditions matrix, rights scope and acceptance proposal.

### Pilot

- A scoped delivery against the agreed specification, reviewed before production.

### Production

- Full programme with ongoing review, versioned delivery and support.
- Subject and the conditions it must hold

We will define the image programme required for your deployment context and constraints.

If YPAI is not the right fit, we will say so directly.

specified · reviewed · delivered with its record

- [Read how pilots work](https://ypai.ai/pilots/)