IMAGE DATA. BUILT IN THE EEA
One photograph is a point. Your model lives in a space.
We collect images against the task your model has to solve: specified coverage, every frame read, every visible person's rights recorded.
measured by
The same corner, twelve conditions distinct over 4 · / 11
WHAT YPAI COLLECTS OWNED 09 · ROUTED 04
Start from the condition your model has not seen
Nine programmes YPAI runs, and four adjacent kinds of work with their own pages. Each door carries one sentence on the coverage it delivers; open it for the problem, the delivery and the annotation it hands off to.
- 01
Collection at scale
The same subject under every condition it will be seen in, not one good picture.
The problem and the delivery
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.
- 02
Rare events, edge cases and evaluation sets
A model is tested on the space, not on the point it was trained at.
The problem and the delivery
The case your model has not seen is the one it will meet, and the benchmark you hold was scraped.
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.
An evaluation set with its coverage and its rights proven per image, not a folder.
- 03
Face, demographic and geographic coverage
A face is a person before it is a sample; the record says who agreed to what.
The problem and the delivery
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. Untargeted scraping is prohibited; opt-in capture is the alternative.
Consent per visible person on the image itself, from an identity-verified network.
- 04
Document and form capture
A page is an image first; the glare and the skew are the data.
The problem and the delivery
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. The page is a photographed object, not a scan.
Real device artefacts on real pages, read per frame.
- 05
Industrial and inspection imagery
The defect is rare on the line and common in the set.
The problem and the delivery
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.
- 06
Multi-view and product imagery
One object, every angle, the same light.
The problem and the delivery
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, with the set as the specimen. Shelf capture in the wild is deduplicated by perceptual hash before it is counted.
The set is the specimen; duplicates are read out before delivery.
- 07
Environment-specific capture
Light, weather and place are specified, not hoped for.
The problem and the delivery
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, not luck.
- 08
Device-specific corpora
Smartphone tier, webcam tier, line camera; the sensor is a condition.
The problem and the delivery
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.
- 09
Licensed image datasets
A licensed set carries its provenance, or it is not delivered.
The problem and the delivery
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 verified, licensed, packaged and delivered. Licence what exists and collect only what is missing.
Chain of title and permitted use verified before a sample is shared.
-
Geospatial and aerial imagery
Aerial and satellite frames need the pose, the coordinate system and the rights that place them.
-
Image annotation and evaluation
Boxes, masks, keypoints and attributes on images you already hold.
-
3D, depth and sensor data
Point clouds, depth and multi-sensor rigs, calibrated and time-synchronised.
Also collected 05
- Multi-modal capture, image with text, audio or sensor streams
- Multi-country, quota-managed cohorts
- Cross-device and cross-environment variability
- Skin and wound imagery on smartphones, rights setup 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.
THE CONDITION SPACE Light · Optics · Viewpoint · People and place
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.
Light
Exposure is a condition, not a defect. The range is written into the specification and read on every frame.
Range specified
- Blue hour
- Night under practical light
- Grey daylight and direct sun
- Mixed indoor light
- Glare, shadow and backlight
Optics
The sensor, the lens and the compression are part of the sample, so the device tier is a cell in the sheet.
Range specified
- Smartphone tier
- Webcam tier
- Line and industrial camera
- Mirrorless and DSLR
- Native resolution, EXIF and compression history kept
Viewpoint
The same subject from where the model will see it, at the distances it will see it.
Range specified
- Fixed mount and handheld
- Multi-view rig
- Overhead and aerial
- Near, mid and far
- Occlusion and partial view
People and place
Quota-managed cohorts and specified places, with the rights for every visible person recorded.
Range specified
- Multi-country, quota-managed cohorts
- Age range, gender identity, skin tone
- Identity-verified contributors
- Facial and biometric rights recorded
- Geographic metadata where agreed
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 25 IRE and above 235. Device, lens and metadata are conditions the specification names and the record holds; the platform takes these readings on every image it accepts.
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.
HOW A PROGRAMME RUNS Specification · Capture · Quality gates · Delivery
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 proves.
-
The sheet, written first
The model task sets the subject, the cohort, the devices, the conditions matrix and the acceptance criteria, before anyone photographs.
-
The frame, under the specified condition
Identity-verified contributors photograph under the specified conditions; the device tier, native resolution and metadata are fixed in the specification.
-
The reading, accepted or returned with a reason
Every frame is read for blur, exposure, dynamic range, duplicates and manipulation, then reviewed by a person against the specification; a rejected image returns with its reason.
Returned 08 · Phone, high ISO · 0.8 by titan-embed-image-v1, under 3: a near-duplicate of the specimen -
The set, with its record
Accepted images leave with their metadata, readings, rights and provenance record, acceptance report, checksums and a manifest in Croissant.
YPAI PROPRIETARY DATA COLLECTION TECHNOLOGY PLATFORM · RECORD · RIGHTS
We built the system behind the data.
YPAI operates its own bespoke, GDPR-native data collection and assurance platform, built to produce high-specification AI data across speech, video, image, text, human feedback, agents, robotics and other multimodal programmes.
- Identity
- Asset, modality and schema version
- Origin
- Source, device, sensor and lens, EXIF, environment and time of capture
- Contract
- The requirements it was collected against, and its cell in the coverage
- Privacy
- Processing purpose, legal state and data categories; consent per visible person · 7 persons by two readers · 2 faces in profile
- 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
- Verdict per image
- PASS
Two readers on this plate yolov10n 7 persons · Rekognition 7 persons · 2 faces in profile · brightness 13.7 · sharpness 46.6 · contrast 77.1 · 2026-09-18 · eu-west-1 Attributes are declared by the person, never read from the face.
What the platform measures on every image
- Sensor and lens, native resolution and EXIF
- Blur, exposure and dynamic range
- Compression history and manipulation
- Duplicate and near-duplicate
- Subject coverage and annotation quality
- Geographic metadata, facial and biometric rights
Specification Customer specification and agreements compiled into an executable project contract
The record your legal and security review will ask for
Governance artefacts are produced by the operation, not assembled afterwards. Depth and format follow your risk profile and are agreed during scoping.
What is the legal basis for each image?
Consent, legitimate interest or contractual necessity, documented per image
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
What may the images be used for, and by whom?
Permitted use, release and licence scope defined per engagement; reuse by explicit written grant
Where did each image come from?
Provenance per image, capture metadata, EXIF and checksum, lineage from source to derivative
Where do the images reside, and under whose jurisdiction?
EEA infrastructure by default, Norwegian jurisdiction; EEA-only sourcing on request
What happens to the images when the engagement ends?
Erasure within 30 days of contract end; retention and closeout defined in the engagement
What governs the engagement on paper?
DPA signed, SCCs available for cross-border transfer
START WITH THE SPECIFICATION Describe the system · Feasibility read · Pilot · Production
Bring the coverage problem. Leave with a programme shape.
- 01 Describe the system Model task, subject, cohort or geography, devices, scale and timeline.
- 02 Feasibility read Capture plan, conditions matrix, rights scope and acceptance proposal.
- 03 Pilot A scoped delivery against the agreed specification, reviewed before production.
- 04 Production Full programme with ongoing review, versioned delivery and support.
FAQ
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 dataset licensing.
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 read on every image, and who reads it?
Every frame is read for blur, exposure, dynamic range, duplicates and manipulation, then reviewed by a person against the specification. A rejected image returns with its reason. The platform records the reading, the verdict and the reviewer for each image.
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?
No. This route owns still images. Sequences are on video data, point clouds, depth and multi-sensor rigs on image, 3D and sensor data, and marking up images you already hold on image annotation.
specified · read · delivered with its record
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.