An eXIf chunk is proposed for addition to the PNG specification, in support
for high-end imaging and digital photography applications. The formal draft
specification is currently available here:
http://www.simplesystems.org/png-group/proposals/eXIf/
The eXIf chunk is simple and compatible with the storage models used in
other image formats:
- While the EXIF data being stored is highly complex, its container has no embellishments.
- The EXIF data inside the
eXIfchunk is stored as in TIFF (which is the format where EXIF originated). Moreover, it is stored as in JPEG (excluding the JPEG-specific APP1 "Exif" marker); it is stored as in WebP (excluding the WebP-specific "EXIF" chunk); etc. - There are no PNG-specific requirements imposed on any EXIF data field, in order to make transfer across formats easy to implement. In particular, EXIF data fields that are only applicable to JPEG, such as YCbCr chroma sampling, are allowed.
The eXIf chunk has no ordering rules:
- It may appear anywhere in the PNG data stream, either before or after
IDAT.
The eXIf chunk has no size constraints:
- Applications may choose to limit the maximum
eXIfchunk size to 2^16-2 bytes, for easy interchange with the JPEG format, but any size within the limits accepted by the PNG format (i.e. no larger than 2^31-1) is valid.
The eXIf chunk has no multiplicity:
- Only a single EXIF structure is allowed in the other image formats. For compatibility and simplicity considerations, only a single EXIF structure is allowed in PNG also.
The eXIf chunk is safe-to-copy:
- The EXIF structure is a mixture of safe-to-copy and unsafe-to-copy data fields that are manipulated, as a whole, in a safe-to-copy manner by the existing applications.
- The EXIF structure contains data fields of primary importance that are safe to copy. Examples include: camera info, lens info, flash info, GPS coordinates.
- The EXIF structure also contains data fields of secondary importance that would normally be unsafe-to-copy, and, for that reason, are retained after editing with historical value only. Examples include: thumbnails (which may or may not be reconstructed upon update, as per the behaviour of existing EXIF applications), colorimetry (which is overridden by an accompanying sRGB or ICC profile additional to EXIF), focus point information (which is either hard or impossible to recalculate while performing geometry transformations like resizing, cropping, or anything more complex).
The PNG format is suitable for high-end imaging, due to its abilities to represent RGB and RGBA samples in 8-bit and 16-bit depths. However, in spite of its abilities, and also in spite of the fact that it is a well-established format for the Web, it is barely used in digital photography workflows. Few software implementations support it, and, to the best of our knowledge, there is no support in digital cameras or other hardware implementations.
The industry standards in this domain are JPEG, TIFF and Raw. Each of these have their own applicability. All digital cameras, as well as all of the photography software, have support for one, two, or (especially for software) all of these three formats.
Comparatively, the PNG format, in spite of its capabilities, is largely under-utilized in these areas. We believe that lack of standardized EXIF support in PNG is an important reason. The implementors of mainstream applications did not create a private PNG chunk; they simply resorted to using TIFF instead of PNG.
- Aim to make PNG suitable for processing, interchange and archival of high-end imaging data and applications.
- Aim to replace TIFF-EXIF (with 8-bit and 16-bit, RGB and RGBA samples), which is currently the de-facto standard used for this purpose.
- Aim to maintain compatibility with the existing EXIF workflows. The users who are currently relying on TIFF or JPEG, for storing intermediate photo edits as well as final releases, should be able to incorporate the PNG format in their workflows, with as little disruption as possible, and without unexpected surprises.
- Do not aim to replace JPEG-EXIF. JPEG is suitable for lossy imaging applications.
- Do not aim to replace Raw image capture formats. The family of Raw pixel data formats (Bayer, Foveon, X-Trans, etc.) is incompatible with the PNG format, and their complex features are considerably beyond the scope of PNG.
- Do not aim to replace TIFF completely. TIFF is suitable, for example, for storing non-RGB colorspaces (CMYK, YCC, CIE, etc.).
This section is a summary of the past discussions that took place on the PNG mailing list.
A zlib-compressed format (named zxIf as a private chunk during format
development) was considered, but eventually dropped.
The EXIF data is easily compressible at high rates (typically around 50%), but this was deemed insignificant when accompanied by the image data, which, in the digital photography use case, is typically massive.
The other image formats that use EXIF are designed to handle the structure as a
singleton. The eXIf design follows the same considerations.
Implementations may go the extra length and try to make sense of data that
happens to be present in other EXIF-like chunks, such as private chunks
(exIf, zxIf) produced by implementations supporting past draft
specifications, or tEXt chunks containing EXIF-specific data produced by
applications like ImageMagick. However, this is a highly complicated task
that is better left at the implementations' discretion. PNG-compliant
implementations should not be forced to deal with the complexities caused by
accidental EXIF multiplicity.
The immediate answer to the question can be obtained by asking:
How to stay compatible with the existing EXIF workflows? How do the existing (non-PNG) applications handle the EXIF data?
Safety-to-copy, as a concept, exists in the world of PNG and PNG-derived formats only. However, it is safe to say that existing non-PNG applications handle EXIF data in a safe-to-copy-like manner.
THE SAFE-TO-COPY EXIF FIELDS, AND WHY ARE THEY IMPORTANT
The vast majority of EXIF data fields are safe-to-copy. For example: camera manufacturer, camera model, lens manufacturer, lens model, exposure time, exposure program, ISO value, shutter speed value, F-stop, aperture value, maximum aperture value, focal length, exposure compensation, metering mode, light source, flash mode, GPS coordinates, etc.
The above fields are the core of the EXIF concept, and are values that are most essentially about photography. Applications or websites that happen to display only a reduced subset of the EXIF fields, will display a subset that largely consists of the fields enumerated above. They are, arguably, the most important for photographers.
All of the real-world image editing applications that recognize EXIF metadata are capable to preserve this metadata. The exception to this rule applies when the user requires to delete the metadata, inside an application that offers the user the choice to delete the metadata.
THE UNSAFE-TO-COPY EXIF FIELDS, AND WHY ARE THEY LESS IMPORTANT
There is a minority of EXIF data fields that are unsafe-to-copy. Existing applications either update some of these fields to keep them in sync with the main image, or leave them intact and therefore out-of-sync with the main image, or leave it up to their users to decide.
Examples include:
- Thumbnails: many, but not all applications update the thumbnails. Some applications update the thumbnails unconditionally, others never do it. Other applications offer the choice to update the thumbnail or not. Some users conscientiously choose to not lose the original thumbnail, for various historical interests; other users don't mind losing the original, since a new up-to-date one can be recreated at any time. Issues like privacy (which may occur when the main image is updated, but the thumbnail isn't) are left at the discretion of these applications and their users.
- Orientation: there are 8 possible orientation values, and the most common one (but not the only one in actual use) is "upright". Instead of rotating an entire image by 90 or 180 degrees, or flip it, a one-byte orientation field is being written, based on the information given by the camera's orientation sensor. This is, again, not a fully reliable piece of data, because not all digital cameras have an orientation sensor (in which case, the user is left with the task of rotating the images manually), and not all applications recognize or update this field when the user rotates the image in software (in which case, again, it is up to the user to recognize whether the images are rotated correctly).
- Scene capture, sharpness, gamma, focus points, etc.: these fields, almost without exception, are being left at their original values after editing. For example, sharpness has only a handful of discrete values set in camera, but the editing software may have a slider (e.g. ranging from -100 to 100). Most, if not all of the image editing software leave these fields untouched, in spite of subsequent edits that no longer reflect the initial values. If the final image happens to not be in the sRGB color space, an ICC profile is present, and the gamma value (if it ever was present) is being either ignored or deleted.
THE NON-APPLICABLE EXIF FIELDS, AND WHY ARE THEY UNIMPORTANT
There is one more category of fields: the JPEG-specific ones that do not apply to the PNG format. Neither the JPEG encoding process (e.g. JPEG baseline DCT), nor the YCbCr sampling (e.g. 4:4:4, 4:2:2, 4:2:0), nor any other JPEG-specific field irrelevant to the PNG format can interfere with the PNG process in any way. Applications may delete these fields, but nothing bad should happen if they don't.
Even in the light of how the current EXIF-processing applications are handling their data (by preserving it, regardless whether it's being updated correctly or not), the following question has still arised:
Should the PNG applications choose a different implementation path, and update
the EXIF data in a faithful manner (and therefore repurpose the eXIf design
into an unsafe-to-copy eXIF)?
FAST AND EASY ANSWER: EXIF UNSAFETY-TO-COPY IS NOT FEASIBLE
Even on the surface, mandating the PNG applications to update the EXIF fields
upon image edits would mean requiring the implementation of a TIFF codec. There
wouldn't be "simple" PNG implementations any more: these implementations would
have to be augmented with TIFF datastream decoding and re-encoding (because
the EXIF format is based on TIFF), and we would end up with PNG applications
that require more code to parse a single chunk (i.e. the hypothetical
unsafe-to-copy eXIF) rather than the whole rest of the PNG format! Anybody
who has ever implemented a TIFF parser can attest to the fact that the TIFF
structure is more complex than the PNG structure, so this would not be a
trivial thing to do.
COMPLETE ANSWER: EXIF UNSAFETY-TO-COPY IS NOT GENERALLY POSSIBLE
The complete answer goes even further. Imagine a "simple" PNG processor that performs "simple" image cuts, rotations, scalings and flips. For the sake of correctness, it would not be sufficient to just update the thumbnail or the orientation field: it would be necessary to recalculate the focus points. This is a non-trivial task for orthogonal transformations, and an absolutely impossible task for non-orthogonal transformations such as shearings or lens distortion corrections.
To add yet more degrees of complication, the focus points are not stored in a conventional EXIF field in a standard way. They are manufacturer-specific, stored in a special sub-structure called MakerNotes, and the implementations that recognize it must have manufacturer-specific code paths.
Some implementations do have manufacturer-specific code paths, on an as-needed basis. However, making a design that would impose such a requirement would be the unreasonable thing to do (and the unreasonable thing to expect that implementors at large will be able or willing to comply to it).
The eXIf chunk should be safe-to-copy, because that's how it is the majority
of its fields. The unsafe-to-copy fields should be left with historical
significance only, because this is how existing applications work, and this is
the only way to make it work correctly.
The following applications have added experimental support for PNG EXIF
metadata, currently in the form of a private chunk (exIf).
Production-quality applications:
- ExifTool
(supporting
exIfsince version 10.43) - ImageMagick
(supporting
exIfin private builds since version 7.0.4-10) - OptiPNG
(
exIfsupport is currently under development)
Proof-of-concept implementations:
- pngexif
(supporting
exIfblob extraction) - pngexifinfo
(supporting
exIfinspection and blob extraction)