PNG Proposed zXIF chunk, draft 20170128

File: png-proposed-zXIF-chunk-20170128.html

Status of this Memo

This document is an informal draft of the PNG development group.

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


ftp://ftp.simplesystems.org/pub/libpng/png-group/documents/.

Notices

Copyright © 2017 Glenn Randers-Pehrson

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.

Abstract

This document describes a special-purpose chunk type that has been proposed for use in various PNG (Portable Network Graphics) and related multi-image applications. It has not yet been approved for registration by the PNG developers, and therefore is experimental and its format is subject to change. The proposed chunk is "zXIF" (an unregistered name that can be used in test implementations is "zxIF"). Caution: the third letter in the chunk name is an uppercase "i", not a lowercase "L".

PNG zXIF (compressed Exif) proposal

It is proposed to add the following section to the document "Extensions to the PNG 1.2 Specification, Version 1.4.0"

3.7. zXIF Compressed Exif (Exchangeable Image File) profile

The four-byte chunk type field contains the decimal values
    122 88  70 102 (ASCII "zXIF")
    122 120 70 102 (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). When uncompressed, the
                  first two bytes are "II" or "MM", depending upon
                  the byte order used within the profile.

              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
                  or mode == 77): 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.

At most one zXIF or eXIf chunk should occur in a PNG datastream. 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.

The zXIF chunk contains metadata concerning the original image data. This data may not apply or may no longer apply to the PNG image data. To avoid potential conflicts between data in the eXIf chunk and in other PNG chunks, it is declared that only those Exif tags that contain historical information such as data about the camera, picture-taking conditions, and geographical location, and that do not affect subsequent image processing have any meaning. Such tags are listed in the Exif Specification (CIPA DC-008, Exchangeable image file format for digital still cameras) Annex E, Paragraph 3, with the notation "should be copied unchanged".

Encoders may write all known Exif tags in the zXIF chunk; however, any other tags which might be present in the zXIF chunk shall be ignored by decoders, and tags containing information relevant only to the original JPEG or TIFF encoding shall be ignored by decoders.

If a thumbnail image (or multiple thumbnail images) is present, there is no expectation that such thumbnails have been updated if the main image was changed, or that they have not been updated.

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-2012, Exchangeable image file format for digital still cameras: Exif Version 2.3. Available at: http://www.cipa.jp/std/documents/e/DC-008-2012_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

eXIf Security considerations

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 "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.

Contributors

Contributors to discussion on the png-mng-misc list

Editor

End of PNG zXIF Chunk Proposal. Expires 28 August 2017.