Comments on this document can be sent to the PNG specification maintainers at
png-mng-misc@lists.sourceforge.net.
Distribution of this memo is unlimited.
Initial proposals were in the png-mng-misc mailing list, January 2017.
At present, the latest version of this document is available on the World Wide Web from
http://www.simplesystems.org/png-group/proposals/eXIf.
A copy of this version is archived at
ftp://ftp.simplesystems.org/pub/png-group/documents/history/png-proposed-eXIf-chunk-2017-03-09.html
Permission is granted to copy and distribute this document for any purpose and without charge, provided that the copyright notice and this notice are preserved, and that any substantive changes or deletions from the original are clearly marked.
It is proposed to add the following section to the document "Extensions to the PNG 1.2 Specification, Version 1.4.0"
101 88 73 102 (ASCII "eXIf")
The data segment of the eXIf chunk contains an Exif profile in the format specified in "4.7.2 Interoperability Structure of APP1 in Compressed Data" of [CIPA DC-008-2016] except that the JPEG APP1 marker, length, and the "Exif ID code" described in 4.7.2(C), i.e., "Exif", NULL, and padding byte, are not included. [Therefore, it begins with a standard TIFF header (starting with either "II" or "MM", depending upon the byte order used), and contains a 0th IFD (Image File Directory) and optionally a 1st IFD. The 0th IFD may contain pointers to an Exif IFD and/or a GPS IFD, and the 1st IFD (if any) contains a thumbnail image. Any gap preceding an IFD is filled with bytes of unspecified content.]
There are no ordering constraints upon the position of the eXIf chunk beyond those imposed by the PNG specification, i.e., if present, the eXIf chunk may appear anywhere between the IHDR and IEND chunks except between IDAT chunks. Only one eXIf chunk is allowed in a PNG datastream.
The eXIf chunk contains metadata concerning the original image data. If the image has been edited subsequent to creation of the Exif profile, this data might no longer apply to the PNG image data. It is beyond the scope of this specification to resolve potential conflicts between data in the eXIf chunk and in other PNG chunks. It is recommended that unless a decoder has independent knowledge of the validity of the Exif data, the data should be considered to be of historical value only.
While encoders may choose to update them, there is no expectation that any thumbnails present in the Exif profile have (or have not) been updated if the main image was changed.
While the PNG specification allows the chunk size to be as large as 2^31-1 bytes, encoders should be aware that, if the Exif profile is converted to JPEG, the total length of the Exif data (the sum of the lengths of the Exif attributes IFD, the GPS IFD, the thumbnail IFD, and the TIFF header) must not exceed 64 kbytes, because it must fit into a JPEG APP1 marker.
Image editing applications should consider Paragraph E.3 of the Exif Specification (CIPA DC-008, Exchangeable image file format for digital still cameras), which discusses requirements for updating Exif data when the image is changed. Encoders should follow those requirements, but decoders should not assume that it has been accomplished.
See ISO 12234 (the XMP standard):
https://www.iso.org/obp/ui/#iso:std:iso:12234:-3:ed-1:v1:en
CIPA DC-010-2012, Exif 2.3 Metadata for XMP. Available at:
http://www.cipa.jp/std/documents/e/DC-010-2012_E.pdf
CIPA DC-008-translation-2016, Exchangeable image file format for
digital still cameras: Exif Version 2.31,
http://www.cipa.jp/std/documents/e/DC-008-Translation-2016-E.pdf
Description of the Exif file format, (based on Exif Version 2.1),
TsuruZoh Tachibanaya, May 28, 1999,
https://www.media.mit.edu/pia/Research/deepview/exif.html
The first two bytes of data are either "II" for little-endian (Intel) or "MM" for big-endian (Motorola) byte order. Decoders should check the first four bytes to ensure that they have the following decimal values:
73 73 42 0 (ASCII "II", 16-bit little-endian integer 42)
or
77 77 0 42 (ASCII "MM", 16-bit big-endian integer 42)
All other values are reserved for possible future definition.
The Exif specification does not contain a requirement that tag "value offset" pointers actually point to a valid address within the file (see Paragraph 4.6.2). Although this seems to be an implicit requirement, decoders should be prepared to encounter invalid pointers and deal with them appropriately.
1. Safe-to-copy ("eXIf") versus unsafe-to-copy ("eXIF"): The Exif profile (and thus the eXIf chunk) contains both material that is safe-to-copy, such as the model of the camera and the location where the photograph was taken, but also contains unsafe-to-copy material about the image data, such as image orientation, width, height, gamma, and JPEG-specific compression information. We resolved that by including a statement that such unsafe-to-copy material should be regarded as historical in nature only, and made the chunk safe-to-copy to reduce the risk of losing valuable information.
2. The eXIf chunk contains TIFF-like and JPEG-like features that seem inappropriate for use in a PNG file. In particular, the IFD structure seems to be of little use. However, we retain IFD and other TIFF-like features for compatibility with workflows involving converstion to and from JPEG/Exif or TIFF/Exif formats and with existing tools for manipulating an Exif profile.
3. The material enclosed in square brackets seems to be redundant with information already available and obvious to users familiar with the Exif specification. It is just a couple of sentences gleaned from the 186-page Exif specification, and may be helpful to people who would rather not search through the Exif specification for it.