Skip to content
Language:DeutschEnglish Last updated: 2026-10-23

Images: formats and significant properties

This page sets out, for raster images, which formats Anton prefers and accepts, which properties of an image must be preserved, and what Anton measures or checks of them today. It is the first page of a series per format category (anton#687); PDF, text, audio and video, and spreadsheets and presentations follow. Vector graphics are not covered here.

Anton needs this for three things: to document what makes up an image (NDSA Cn-1.1), to verify that it still does (Cn-2.1), and to prove after a migration that nothing significant was lost (media:migrate).

Formats

Level Format Condition
preferred TIFF with Deflate (ZIP) and predictor 2 greyscale and colour, 8 or 16 bits per channel
accepted TIFF in another form uncompressed, LZW, CCITT G4 (bitonal), JPEG-compressed, BigTIFF, multi-page
accepted JPEG
accepted PNG
accepted JPEG 2000 (JP2)
accepted HEIC/HEIF stays the master, access copy JPEG
accepted GIF, BMP, WebP
accepted DNG
accepted camera raw (CR2, CR3, NEF, ARW and others) as long as LibRaw reads it
accepted PDF/A if it contains only images, such as scans without a text layer or with an OCR layer
accepted PDF if it contains photographs only

Preferred means: this is what Anton recommends to depositors, and it is the form into which the rule tiff_zip losslessly repacks uncompressed TIFF and LZW without a predictor. Deflate with predictor 2 saves 38–66 % over uncompressed without changing a single pixel, and libtiff, ImageMagick, GIMP and Photoshop read it. It is not part of baseline TIFF, however; KOST recommends baseline with LZW or CCITT. Bitonal images are better left in CCITT G4, which compresses them more; tiff_zip therefore skips them.

Accepted is what widespread open-source tools can read and will in all likelihood go on reading. Anton takes in the file and keeps it in its format. Following the format decisions, Anton migrates only when a file can no longer be rendered. Images already compressed with loss (JPEG, JPEG-compressed TIFF, lossy JP2) are not converted to a lossless format: the lost information does not come back, the file would only grow (KOST says the same).

As a rule, we recommend keeping as few different formats as possible in one archive, so that preservation planning stays simple in the long run: every format has to be watched, checked and perhaps one day migrated (KOST says the same). The list of accepted formats says what Anton can preserve, not what an archive should collect. Where a holding brings many formats, it is therefore normalised before ingest where possible: by the depositor or with the file rules that Anton applies before the file becomes the master. Lossy images are the exception (see above).

PDF is listed here because some image holdings arrive as PDF. As soon as a PDF carries text, forms or links, the page on PDF applies.

HEIC/HEIF, as mobile phones deliver it, stays the master as it is; Anton converts only the access copy to JPEG. This is what NARA recommends as long as the file renders well. HEIF is an open ISO standard (ISO/IEC 23008-12), free tools (libheif, libde265) read it; the catch is HEVC compression with its patent pools, which is why Windows, Photoshop and some browsers do not open HEIC out of the box. HEIC is smaller than a JPEG made from it, and every conversion loses what the file holds besides the main image (depth map, HDR gain map). At ingest HEIC can be converted to JPEG, for archives where storage is expensive and the file should open everywhere, with a second lossy encoding; the QR upload offers this today (heic2jpg, off by default). The HEIC is kept as a version of the medium, and the conversion is logged as an event with tool, command and checksums. Conversion to TIFF is possible at any time later, without further loss but about ten times larger, with media:migrate. The rule for this, and likewise a conversion to TIFF or JPEG at ingest chosen per archive, is built only when an archive needs it (decided in anton#710).

GIF, BMP and WebP are read by all common tools and browsers. NARA advises converting BMP; under the principle above it stays until that changes. DNG is an open Adobe specification based on TIFF; NARA rates it low risk, KOST considers it unsuitable for long-term preservation. Camera raw is specific to each maker and model and undisclosed; the open-source LibRaw reads it and has been maintained for this for many years. NARA advises conversion, and depositors who can should rather deliver DNG or TIFF. Anton recognises camera raw by its extension, since the tools take NEF, ARW and DNG for TIFF, and makes the access copy through LibRaw from the whole image, not from the embedded preview. Upload takes DNG and camera raw with their extension; the QR upload limits files to 10 MB, so larger ones such as ProRAW DNG from an iPhone (25–75 MB) go through the regular upload.

A TIFF made from raw loses something: raw holds the sensor data, and only development fixes white balance, exposure and tone curve. A TIFF holds one of these developments, and the rest of the sensor data is gone afterwards. What of it must be preserved depends on what the archive wants to preserve:

  • The finished image: then the developed TIFF suffices as the master.
  • The material, with every option for later editing: then raw or DNG must stay, for instance in a photographer's estate.

Significant properties

Grouped as NARA does into appearance, structure, behaviour and context. The column «Source» names who considers the property significant; the sources are listed below.

Group Property Source
Appearance width and height in pixels, and so the aspect ratio InSPECT, NARA
bit depth and number of channels, including alpha InSPECT, NARA
colour space and ICC profile NARA, LoC
orientation (EXIF Orientation) NARA
pixel content, where the format is lossless Anton
Structure resolution in dpi (for scans, the scale to the original) InSPECT, NARA
number of pages in a multi-page TIFF LoC, KOST
compression: recorded, not preserved NARA, KOST
Behaviour The image can be rendered. NARA
for GIF and WebP, the animation LoC
Context embedded metadata (EXIF, IPTC, XMP), such as date taken, creator, rights NARA

Colour space counts here, unlike in InSPECT. InSPECT did not consider it significant because it changes in almost every migration. For scans of photographs, posters and maps, however, colour is content, and Anton migrates only when needed anyway. A migration that changes the colour space must carry the ICC profile along.

Compression is not a property that must be preserved. It is recorded because it tells whether the other properties are held losslessly.

Layers, editing steps and preview images in a TIFF are not significant behaviour: they belong to the software the image was made with, not to the image.

What Anton measures and checks

As of version 0.111.1.

Property Measured Checked
Width and height TIFF at ingest with exiftool, when tiff_zip is switched on via the pixel signature after tiff_zip and media:migrate
Bit depth and channels likewise likewise
Colour space and ICC profile likewise (name of the profile) no
Orientation no no
Pixel content pixel signature per page with ImageMagick, only for tiff_zip and media:migrate yes, must stay the same, otherwise the delivered file remains
Resolution no no
Number of pages TIFF with exiftool, as above, previews counted separately via the pixel signature per page
Compression TIFF with exiftool, as above –
Renderable – at ingest and nightly with media:validate-formats: TIFF with tiffinfo (thorough: -D); JPEG, PNG, JP2, GIF, BMP, WebP, HEIC/HEIF, DNG and camera raw with ImageMagick, which decodes every pixel rather than reading only the header; also when the access copy is made
Embedded metadata no tiff_zip carries it over with exiftool but does not compare it

Measured values appear on the medium under Technical characteristics and in the dry run before a spreadsheet import.

Limits

  • For JPEG, PNG, JP2, HEIC, GIF, BMP, WebP, DNG and camera raw Anton records no characteristics, only PUID, MIME type and size. Likewise for TIFF from SIPs and for TIFF in archives that have not switched on tiff_zip.
  • Anton measures orientation and resolution for no format.
  • Embedded metadata is carried over by tiff_zip but not compared. Nothing proves that all fields are still present after a migration.
  • Anton does not check whether a PDF contains photographs only.
  • HEIC stays the master. At ingest Anton does not convert it to TIFF or JPEG, except with heic2jpg in the QR upload (decided in anton#710).
  • The QR upload takes files up to 10 MB; larger raw and DNG files go through the regular upload.
  • The check «renderable» means the tool reads the file without error. It does not check whether the colours are right.

What a migration must check

When media:migrate converts an image, afterwards:

  • Width, height, number of pages, bit depth and channels are the same.
  • With a lossless target, the pixel signature of every page is the same.
  • The ICC profile is carried along, or the conversion is recorded in the event.
  • The embedded metadata is carried over.
  • The delivered file stays as an original when the target is lossy.

Today media:migrate checks only the pixel signature. With a lossless target it covers the first and second points, not the others.

Sources