Image Resolution, Compression and File Requirements for Vision Training Data

This page covers pixel-level requirements: resolution, compression, bit depth, color and file encoding. Container and shard formats such as WebDataset tar shards or Parquet tables belong to delivery planning, and video codecs are covered in frame rate, resolution and codec requirements for video training data. For the wider sourcing picture, start at the image data hub.

Start from pixels on target, not megapixels

Minimum resolution is a function of the smallest object or defect, the field of view and the network input size, so a megapixel figure on its own means little. A 12 MP photo of a whole vehicle and a 2 MP close-up of one weld can put very different pixel counts on the feature you care about.

The working calculation has three steps. First, measure the physical size of the smallest target (a 0.5 mm scratch, a 30 cm pallet label, a 2 m vehicle in overhead imagery). Second, convert it to pixels at capture using the sampling rate (pixels per mm, or ground sample distance for overhead data; xView, for example, uses WorldView-3 imagery at 0.3 m GSD [3]). Third, apply the downscale your pipeline will do: a 4000x3000 frame letterboxed to a 640-pixel detector input shrinks every object by roughly 6x.

The COCO convention treats objects under 32x32 pixels of area as "small," and small objects remain the weakest size category for general detectors on COCO-style benchmarks. If your smallest target lands below that after resizing, you have three options: request higher sampling at capture, tile the full-resolution image at train and inference time, or crop to regions of interest. Each changes what you must ask a supplier for, which is why the calculation belongs in the spec. See aerial vs satellite vs drone imagery for the GSD version of this trade-off.

Why public benchmark resolution is a poor default

Public datasets span a wide range of resolutions, and many were sized for convenience rather than for your task. A widely used car damage tutorial set ships 480x640 RGB images [2], while defect detection benchmarks range from small grayscale synthetic images such as DAGM to higher-resolution real captures [1].

Two failure modes follow. Teams copy a benchmark's resolution into a supplier request and receive data too coarse for hairline cracks or small text, or they demand maximum resolution everywhere and pay storage, transfer and annotation costs for pixels the model never sees. Saturation is a third warning: leading anomaly detection methods already exceed 99% AUROC on MVTec AD, which motivated the multi-view, real-world Real-IAD dataset [4]. Benchmark numbers at benchmark resolution say little about production cameras. The industrial defect image datasets guide covers defect-specific capture in more depth.

How JPEG compression affects CNNs and vision transformers

Light JPEG compression rarely changes what a model learns about large objects, but heavy or repeated compression removes fine detail and introduces block artifacts that models can learn as shortcuts. The damage depends on the task, so measure it: re-encode a held-out set at several quality levels and plot accuracy per class before writing a quality floor into the spec.

The mechanics explain where JPEG bites. Baseline JPEG quantizes 8x8 DCT blocks and typically subsamples chroma at 4:2:0, so it discards high-frequency texture and halves color resolution in each direction. That hurts tasks that depend on fine edges (cracks, print defects, small text), thin color features (rust spots, wire color codes) or texture statistics (fabric, surface finish). It hurts least on large, shape-defined objects.

Three compression problems matter more than the nominal quality setting:

• Platform recompression. Images exported from messaging apps, social platforms, ticketing systems or CMS thumbnails are often resized and recompressed on upload. Ask for originals from the capture device or the system of record, not the copy that was attached to a ticket.
• Double compression. Each decode and re-encode cycle compounds blocking artifacts. Ask suppliers not to re-encode during de-identification, cropping or format conversion unless the spec allows it.
• Label-correlated quality. If defect images came from one inspection station at quality 95 and good parts from another at quality 70, a model can learn compression level instead of the defect. Record encoder settings per image and check their distribution by class.

The "quality" number is not standardized across encoders, so request the quantization tables or let your intake tooling estimate quality from them rather than trusting a filename or a vendor's label.

Raw vs JPEG training data

Use camera raw or lossless formats when the deployed system sees raw or lossless pixels, or when you need headroom for exposure, white balance and denoise experiments; otherwise, match the encoding your production camera emits. Train-serve mismatch is the real risk: a model trained on pristine 16-bit TIFFs and deployed on an edge camera's compressed JPEG stream sees a different input distribution.

Raw files (DNG, or vendor formats such as CR3, NEF and ARW) hold 12- to 14-bit sensor data before demosaicing, so they preserve shadow and highlight detail and let you rerun the image signal processing pipeline. They are large, need a fixed development recipe for reproducibility, and vendor formats can be awkward to parse at scale. A common pattern is to request raw plus a reference JPEG rendered by the camera, then decide which one to train on after a pilot.

Lossless 8-bit PNG suits screenshots, documents and synthetic overlays. Lossless 16-bit PNG or TIFF suits machine vision, microscopy and radiometric work. HEIC (from many phones), WebP and AVIF are acceptable only if your decoders support them across the training stack and you know whether the supplier transcoded them.

Bit depth, color space and sensor modalities

Declare bit depth and color space explicitly, because silent conversions are among the most common causes of unusable deliveries. Ask for the native bit depth from the sensor, the color space (sRGB, Display P3, Adobe RGB, or linear), and whether an ICC profile is embedded.

Modality-specific notes:

• Industrial monochrome cameras often output 10- or 12-bit data packed into 16-bit containers. Conversion to 8-bit with an auto-contrast stretch per image changes intensity statistics between images; ask for a fixed mapping or the original values.
• Thermal cameras may deliver a colorized JPEG preview alongside radiometric data. The palette image is not temperature data; request the radiometric values plus the calibration parameters needed to convert them.
• Medical and scientific imaging usually arrives as DICOM or TIFF with modality-specific metadata. Pixel spacing tags matter as much as pixel count.
• Phone and consumer cameras apply HDR fusion, sharpening and noise reduction by default. Ask whether computational processing was on, because it changes edges and noise patterns relative to a fixed industrial camera.

Orientation is a related trap: the EXIF Orientation tag can make an image display rotated relative to its stored pixel array, so labels drawn in one viewer land on the wrong pixels in another. The EXIF metadata guide covers what to keep and strip.

Downsampled images and dataset quality checks

Downsampled or upscaled images are hard to spot by eye and should be checked at intake. A supplier may resize to save bandwidth, or upscale thumbnails to meet a minimum-resolution clause; upscaled images meet the pixel count but carry no extra detail.

Practical intake checks:

1. Compare declared dimensions with EXIF camera model and the sensor's native resolution; odd sizes suggest cropping or resizing.
2. Estimate JPEG quality from quantization tables and flag images below your floor or with signs of double compression.
3. Measure a sharpness metric (variance of the Laplacian is a cheap one) per image and per class; look for classes that differ systematically.
4. Look for interpolation signatures in the frequency spectrum to catch upscaled files.
5. Hash files and near-duplicate-check across splits, since resized copies of the same image defeat exact-match deduplication.

These checks sit naturally inside a documented data quality process of the kind ISO/IEC 5259-3 describes [5], and they connect to the wider training data quality assessment workflow. Capture diversity (cameras, lenses, lighting) is a separate axis covered in camera, lens and lighting diversity.

Example image file requirements block

A file requirements block turns the decisions above into clauses a supplier can check before sending anything. Put it in the data request alongside task description, label schema and rights questions, whether you send it to suppliers directly or describe the data to SourceX; the guide on how to write a data request for suppliers covers the rest of the request, and what file formats AI buyers accept covers broader format expectations.

Illustrative example: invented to show structure; it does not describe an available dataset.

Request image data at the resolution your task needs

SourceX sources operational datasets, including new recordings of hands-on work, from US companies on request; categories are not inventory, and a request does not guarantee a match. Buyers describe the data, including pixel and file requirements like those above, every release is approved by the supplying company, and delivery runs through private, access-controlled workflows after an executed agreement. To describe the image data you need, start at SourceX for buyers.