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/zXIf.
A copy of this version is archived at
ftp://ftp.simplesystems.org/pub/png-group/documents/history/png-proposed-zXIf-chunk-2017-03-05.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"
122 88 73 102 (ASCII "zXIf", copy-safe)
122 120 73 102 (ASCII "zxIf", use prior to registration of zXIf)
122 88 73 70 (ASCII "zXIF", copy-unsafe)
122 120 73 70 (ASCII "zxIF", use prior to registration of zXIF)
The data segment of the zXIf chunk contains an optional "mode" byte and an optional "uncompressed_length" field followed by an Exif profile in a raw format or in a zlib-encoded compressed format. It begins with either a compression_method byte, "I" or "M", depending upon the byte order used and whether the data is zlib-compressed or uncompressed.
The Exif profile is 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, padding byte, are not included.
Mode: 1 byte
0: the remainder of the data segment
(chunk_length - 1 bytes) make up a 4-byte
uncompressed_length integer followed by a
zlib-encoded Exif profile written in accordance
with Chapter 5, "Deflate/Inflate Compression"
of the PNG specification version 1.2 (which is
Clause 10.1, "Compression method 0" of the
ISO PNG specification). Therefore, when
uncompressed, the
first two bytes are "II" or "MM", depending upon
the byte order used within the profile,
and it contains a TIFF header plus a 0th IFD
(Image File Directory) and a 1st IFD; the 0th
IFD contains pointers to an Exif IFD and/or a
GPS IFD; and the 1st IFD contains a thumbnail
image. Any IFD may be omitted. Any gap
preceding an IFD is filled with padding bytes
of unspecified content.
73: the Mode byte (ASCII "I") plus the remainder
of the data segment, beginning with another "I",
make up a raw uncompressed Exif profile in
little-endian ("Intel", LSB first) byte order.
77: the Mode byte (ASCII "M") plus the remainder
of the data segment, beginning with another "M",
make up a raw uncompressed Exif profile in
big-endian ("Motorola", MSB first) byte order.
Other values of Mode are reserved for other
compression methods which might be defined
in a future version of this specification.
Uncompressed length (4 bytes, omitted if mode == 73,
mode == 77, or mode == 69): the length of
the Exif profile when uncompressed, expressed
as a 32-bit unsigned integer in network byte
order.
Data (the remaining chunk_length): the Exif profile,
either uncompressed or compressed, according
to the Mode byte.
There are no ordering constraints upon the position of the zXIf chunk
beyond those imposed by the PNG specification, i.e., if present, the zXIf
chunk may appear anywhere between the IHDR and IEND chunks except between
IDAT chunks. Only one zXIf chunk is allowed in a PNG datastream.
The zXIf 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 zXIf 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.
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
Decoders should check the first two bytes of data, or the first two bytes of the datastream after decompressing it, to ensure that they are "II" or "MM". All other values are reserved for possible future definition. It is possible that the first two bytes are "Ex", indicating that the first 6 bytes are probably "Exif\0\0", harmlessly included by some legacy application (for example, ImageMagick/GraphicsMagick have been including these bytes in a predecessor zTXt-based version of this chunk). Decoders may choose to check for this case and skip these 6 bytes if present and look again for "II" or "MM" in the next two bytes of the data segment or decompressed datastream.
It is proposed to add the following clause to Section 7 (Security Considerations) of the "Extensions to the PNG 1.2 Specification, Version 1.4.0" document:
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.
The "uncompressed length" field of the zXIf chunk allows decoders to defend against potential "decompression bomb" attacks which would have been possible if the amount of expansion were allowed to be unlimited. Decoders should reject the zXIf chunk if, while inflating the data, the data would exceed the specified uncompressed length.