PNG and MNG tools Exif and PNG

Converting TIFF/EP or Exif files to and from the PNG format (Draft 0.20, December 20, 2000)

Notices:

Copyright 2000, Glenn Randers-Pehrson, randeg@alum.rpi.edu, all rights reserved. The original document is available at http://pmt.sourceforge.net/exif/drafts/history/d020.html The latest draft of the document is available at http://pmt.sourceforge.net/exif/drafts.

You may link to this file or (preferably) to the directory in which it resides, but please do not publish this file on your web site without my permission. You may quote portions of this document and portions of the preceding drafts, on web sites and in messages, provided that you include the copyright notice and a link to the original document. If and when this document emerges from draft status, it will be released on more generous terms, identical to those of the PNG extensions document [PNGEXT].

Status of this document

This is a draft of a proposal to the PNG Development Group for registration of a new text keyword (Exif). It has not been approved by any approving body.

This document and the latest version of this document can be found at <http://pmt.sourceforge.net/exif>. If at some date the files move to another site, I intend to leave a link to the new location here, if possible.

A mailing list, "pmt-exif@lists.sourceforge.net" has been established for discussing this project. Visit lists.sourceforge.net/mailman/listinfo/pmt-exif to subscribe or to view the archives.

Scope:

This document proposes a new PNG [PNG] registered keyword, "Exif". It shows how to use these to preserve the Exif information [EXIFFORMAT] that is present in a TIFF/EP [TIFF/EP] file, when converting the file to PNG or JNG [JNG] format (JNG is a sub-format of the MNG (Multiple-image Network Graphics) [MNG] format).

Introduction

When converting an image to PNG or JNG format, it is desireable to preserve the Exif information present in some camera images because

• The information is useful in its own right [STOKES]. For this reason it ought to be stored in an easily-extracted human-readable format.
• The information is required in case the image is to be converted back to camera format, so it can be loaded back into the camera. For this reason, it ought to be stored in a tamper-resistant machine-readable manner.

Some of the information, which describes the particulars of the encoding of the original image, is of no use once the image has been converted to another format and need not be preserved.

Applications that convert an image back to the original format need to be able to determine whether the image data has been changed, and whether the saved Exif information is still valid and remains in a machine-readable format.

The PNG format does not presently formally accommodate Exif information. It could be stored in PNG text chunks, but a formal specification for storing Exif information is required, to ensure that the data will remain valid and be machine-readable. This document proposes a new registered "Exif" text keyword and rules for using it in a robust manner, within one of the existing PNG text chunks. By this method, the Exif data can be stored in a manner that is both machine and human readable, and can be examined with existing PNG applications.

The chunk data includes validity information by which applications can determine whether the image data might have been edited in a manner that invalidates the stored Exif information. Applications that modify the image data and do not recognize the proposed Exif keyword, and persons who manually edit the Exif data will fail to update the validity check values; therefore, an invalid check value will serve as an indicator that the image data or the Exif data has been modified and is no longer necessarily valid.

Terminology

Adler-32 CRC

Adler-32 Cyclic Redundancy Check (see the zlib specification [ZLIB] for a sample implementation).

CRLF

A carriage-return, line-feed sequence representing a newline in a string.

Exif

Exchangeable Image File Format [EXIFSPEC]. An image format specified by the Japan Electronic Industry Development Association (JEIDA). "Exif information" refers to the extra information that is contained in TIFF tag format within an Exif file or within a TIFF/EP file, or that has been extracted from one.

line

A sequence of bytes ending with a newline character. A line might be empty.

newline

The ASCII NEWLINE character, also represented as "\n" in this document. Actual NEWLINE characters, not the two-symbol representation ("\", "n") are used in the textExif chunk.

textExif chunk

A PNG iTXt, tEXt, or zTXt chunk that contains Exif information, and whose keyword is "Exif"

textExif entry

A "subkeyword=DATA\n" sequence in a textExif chunk. Abbreviated "tE" in the encoding table.

textExif subkeyword

The subkeyword in a textExif entry. The currently defined set of keywords consists only of upper and lower case ASCII letters, and it is likely that this practice will continue in future TIFF/Exif/DCF specifications, but applications must not depend on this. In fact, any Latin-1 character allowed in PNG text chunks, except for the "=" sign, is conceivable. Any new subkeywords proposed in this document will begin with "PNG_".

TIFF/EP

Tag Image File Format--Electronic Photography. A format for storing bitmapped images, defined by International Standard ISO/DIS 12234-2 [TIFF/EP].

whitespace character

A newline immediately followed by an equal-sign ("\n="), which together represent a single whitespace character, a blank, or a TAB character.

whitespace

Any number of whitespace characters.

Mapping of TIFF/EP tags to PNG chunks:

Tags that provide details about the TIFF compression itself are no longer useful and are dropped. Other tags can be converted to existing PNG chunks, or to a tEXt/zTXt/iTXt chunk using the "Exif" keyword (i.e., a "textExif" chunk), as shown in this table.

Usage of the proposed Exif text keyword

All of the Exif information must be written in a single textExif chunk that contains one or more subkeywords with data. The data for a subkeyword is terminated by the appearance of a line that does not begin with an equal-sign or by the end of the chunk. In TIFF/EP tags whose data is a string ending with a NULL, the terminating NULL is removed, and embedded newlines are permitted. Any CRLF sequences in such strings are replaced with the newline character, then an equal-sign is inserted immediately after each newline in the string. If the string is not the last item in the tag (which presently only occurs in the OECF tag), it is converted to a SUBSTRING as described above. If any character outside the Latin-1 character set is present (which would violate the TIFF/EP Standard but might happen anyway), the strings must be converted to UTF-8 format and the iTXt chunk must be used. The data field of the text chunk must begin with the "Exif" keyword plus this caution not to edit the data manually:

Exif\0CAUTION=Do not manually edit the data in this chunk.\n

Applications that are cognizant of Exif and have edited the image data in a manner that does not invalidate the Exif information must update the PNG_ImageValidity check value and the PNG_TextValidity check value, if they want other applications to be able to check its integrity. If they make changes that invalidate the Exif information, they must remove the PNG_ImageValidity tag. If they change the textExif chunk without invalidating it, they should update its PNG_TextValidity check value.

If an application reorients an image, it must update the "PNG_OriginalOrientation" tag. If it edits the Exif "Orientation" tag, it must also update the "PNG_OriginalOrientation" tag, to maintain the proper relationship between the two values.

Applications that wish to determine the validity of the Exif information contained in the textExif chunks should check for the presence of the PNG_TextValidity tag. If none is present, or if its value does not match the check value when recalculated, it can be concluded that the file has been edited by an application that is not cognizant of Exif. If it is present and valid, then it can be concluded that the Exif information is still valid, if the PNG_ImageValidity check value also matches a recalculated check value over the image pixel data.

If any string in the Exif data has embedded newlines or CRLFs, the PNG_ByteOrder tag must be present.

Mapping of PNG chunk data to TIFF/EP tags:

When decoding a STRING or SUBSTRING, the "newline, equal-sign" sequence is converted to a single embedded newline. When decoding a SUBSTRING, any two consecutive semicolons must be converted to a single semicolon. A NULL character must be appended to any STRING or SUBSTRING. If whitespace follows the terminal for the preceding item in the Exif entry, the first whitespace character is ignored and the remainder form the beginning of the converted string. If necessary according to the PNG_ByteOrder tag, newlines are converted to CR,LF. After these replacements have been accomplished, the string length is computed and written in the TIFF/EP tag along with the string itself.

Any NUMBER is read according to the PNG Extensions document [PNGEXT] and stored as the appropriate type (RATIONAL, LONG, SHORT, etc.) for the TIFF/EP tag being written.

Certain data that describes the image structure (JPEG tables, TIFF tiling, etc.) is dropped during the decoding phase. The encoder must construct these tags appropriate to the JPEG or TIFF image that it is writing.

Software

Software applications for converting to and from the PNG format are beyond the scope of this document. It is clearly evident that Thierry Bousch's exifdump [EXIFDUMP] or Matthias Wandel's [JHEAD] software could be easily modified to do the job.

Calculating Validity Values

The PNG_TextValidity value is an unsigned 32-bit number resulting from calculating the Adler-32 check value on the contents of the text chunk, beginning with the first letter of the Exif keyword, up to and including the newline that precedes the PNG_TextValidity tag itself.

If the image is stored as a PNG datastream, the PNG_ImageValidity value is an unsigned 32-bit number resulting from calculating the Adler-32 check value on the pixel data, in the order that the pixels are stored. Each pixel is promoted to 48-bit RGB prior to running it through the Adler-32 function. Greyscale images are promoted by replicating the grayscale samples to form RGB samples. If an alpha channel is present, it is ignored for the purpose of calculating the PNG_ImageValidity value but is used to calculate the PNG_AlphaValidity value.

If the image is stored as a JNG datastream, the PNG_ImageValidity value is an unsigned 32-bit number resulting from calculating the Adler-32 check value on the concatenated raw data contained in the JDAT chunks.

If the image has an alpha channel, the PNG_AlphaValidity value is calculated on the alpha channel. If the image is stored as a PNG datastream, or if the image is stored as a JNG datastream with the alpha channel in IDAT chunks, the value is calculated on the alpha samples, in the order that the samples are stored, promoted to sixteen bits. If the alpha channel is stored in a PNG tRNS chunk, the tRNS data is used to determine the alpha value for each pixel, and the result is promoted to sixteen bits and used in the calculation. If the image is a JNG datastream and the alpha channel is stored in JDAA chunks, the PNG_AlphaValidity value is calculated on the concatenated raw data contained in the JDAA chunks. If the image is fully opaque, the PNG_AlphaValidity tag can be omitted.

The zlib specification [ZLIB] provides a sample implementation of the Adler-32 check value calculation.

Rationale

Why not simply embed the entire TIFF/EP data structure in binary form in a new proposed eXIF or proposed eXIf chunk?

• The data is potentially useful to human readers; this proposal allows them to view the information with existing PNG software. If it were kept in binary form, only special-purpose applications would be able to read it. Also, combining different data management methods (as in Exif format that embeds TIFF and JPEG encoded stuff), makes things unwieldy.

• Data that is of no conceivable use after the image has been converted from the original format (JPEG tables, TIFF tiling layout, etc.) would be unnecessarily saved, wasting space.

• The data would be at risk of being unnecessarily discarded by PNG editors.

The PNG_ImageValidity value for JNG datastreams is not invariant when inconsequential changes like removing comments or thumbnails is done.

• An alternative would have been to extract the DCT coefficient array and calculate the checksum over that.

• In the interest of keeping it simple, the check value is calculated over the entire contents of the JDAT chunks. Anyhow, Exif-to-JNG converters should be removing extraneous matter, and they should move COM data into PNG/JNG text chunks, before they store the JDAT chunks and calculate the check value.

To do:

• Split this document into two, one relating specifically to Exif and another describing the subkeyword syntax in general.

• Get a copy of the actual Exif specification.

• Explanation of how to write various data types needs to be included, e.g., BYTE, SHORT and RATIONAL are written as ASCII-formatted numbers as explained in the PNG Extensions document.

• Examine some real files to see if CRLF is present and accounted for properly in the character count. The TIFF/EP Standard is mute on the subject.

• Integrate this proposal with the DCF (Digital Camera Format) standard [DCFSPEC].

• Extending this proposal to address saving the Exif thumbnail image. That can be done with MNG (the "very low complexity" version, MNG-VLC [MNG-VLC]) but not with PNG or JNG, which are single-image formats.

• Approval of this proposal by the PNG Development Group according to the PNG specification.

Issues to be resolved:

• Should the keyword be "Exif" as in draft 0.0, or should it be "Exif info", "Exif information" or "Exif data"?

• Byte order for HEX strings. In draft 0.14, a requirement for writing them in network byte order was imposed, but another possibility is for the writing application to write the data in its native order and to record the HEX byte order in a PNG_ByteOrder subkeyword. In draft 0.15 we selected the approach of writing a byte-order flag at the beginning of the HEX string.

• Default byte-order to be assumed when byte-order flag is omitted from a HEX string. "Unknown" is not appropriate because we do not want to encourage that. "Little-endian" is the most commonly found in digital cameras. "Big-endian" is the byte order used in PNG files. Tentatively we specified "Little-endian" as the default in draft 0.15.

• Can we eliminate "(but only one whitespace character may separate them, if the second item of the pair being separated is a STRING or a SUBSTRING)"? Question: how to write a SUBSTRING that begins with some whitespace?

• A better name for "SUBSTRING" is desired. The term is used to refer to a STRING that is not necessarily the last item in the DATA for a subkeyword.

• Is the tag list complete? SecurityClassification and ImageHistory were missing; is anything else missing?.

• Should we invent some new global tags to hold generally useful info found in some of the MakerNotes, e.g., DigitalZoom, which appears in variant forms in all four example MakerNotes in [EXIFFORMAT], and is shown in the tables as PNG_DigitalZoom?

• Converting "Exif/JPEG" files to JNG.

• What to do with CFA (7-channel) and planar-formatted data.

• How to calculate a validity value for JNG or other non-PNG-formatted data. Draft 0.20 says to simply concatenate the contents of the JDAT/JDAA chunks, but that would not be invariant if nonessential markers like comments were to change.

• Should the validity values be 128-bit MD5 digests instead of 32-bit Adler-32 check values? PNG applications will already have adler32 code available, but the MD5 is more robust (1 out of about 2^128 false matches instead of 1 out of about 2^32).

• Items marked with "?" in the table.

Revision history:

• Draft 0.0
  • Initial draft.
• Draft 0.01
  • Added proposed eXIF chunk, for recording the editing status and current orientation.
• Draft 0.02
  • Added "Introduction"
• Draft 0.03
  • Added requirement to adjust the character count if CRLF sequence is present.
  • In the "issues" section, introduces the idea of including textExif chunk CRC's in the proposed eXIF chunk.
• Draft 0.04
  • Revised copyright and license.
  • Added instructions not to write proposed eXIF chunks PNG files until it has been registered. Until then, the exIF chunk must be used instead.
  • Revised handling of GPSinfo tag.
• Draft 0.05
  • Began "Terminology" and "Rationale" sections.
  • Revised some of the PNG encodings.
  • Added several tags found in ELIF but not in TIFF/EP.
  • Expanded the GPS and SecurityClassification tag list.
• Draft 0.06
  • Major revision of the encoding table, adding specific rules for encoding the various types of information found in the TIFF/EP tags.
• Draft 0.07
  • Changed "TIFF-EP" to "TIFF/EP" throughout.
  • Changed "EXIF" to "Exif" throughout.
  • Started work on a second table, for use in reencoding the PNG data in TIFF/EP tags.
• Draft 0.08
  • Minor editorial changes.
• Draft 0.09
  • Use semicolon plus newline as terminator, and represent any internal semicolon with a double semicolon, and eliminated the character-counts.
• Draft 0.10
  • Clarified that the final string-terminating semicolon plus newline also terminates the textExif entry (and added "textExif entry" to the terminology).
  • Changed the format of the required caution line, to prevent decoders from losing the first entry following it.
  • inserted the word "proposed" in front of every mention of the proposed eXIF chunk.
  • Distinguished between "Exif" (the file format) and "Exif information" (the extra data in TIFF tags in Exif or TIFF-EP files).
• Draft 0.11
  • Minor editorial changes.
  • Added PNG_DigitalZoom entry.
  • Broke the first table into three parts, and reduced all table widths to 96%, to work around a Netscape printing bug.
• Draft 0.12
  • Terminate textExif entries with a newline instead of a semicolon.
  • Added SUBSTRING to terminology
  • Eliminated terminal semicolon except in SUBSTRING
  • Added "newline, equal-sign" sequence to represent newlines that do not terminate a textExif entry.
  • Added "newline_type" byte in the eXIF chunk.
• Draft 0.13
  • Removed a leftover mention of using a semicolon to terminate a textExif entry
  • Changed meaning of abbreviation "tE" from "textExif chunk" to "textExif entry" as it was intended.
• Draft 0.14
  • Changed "keyword" terminology to "subkeyword"
  • Revised the description of subkeyword syntax. A subkeyword can now stand alone on a line without a terminating equal-sign.
  • Added a requirement that multibyte values in a HEX string must be written in network byte order.
• Draft 0.15
  • Added byte-order flag for HEX strings.
  • Do not allow multiple textExif chunks, and revised the eXIF chunk syntax accordingly.
• Draft 0.20
  • Eliminated the eXIF chunk proposal.
  • Added PNG_ImageValidity, PNG_AlphaValidity and PNG_TextValidity tags.
  • Added PNG_OriginalOrientation and PNG_ByteOrder tags.
  • Added links to the JEIDA Exif and DCF specifications.

References:

[DCFSPEC] Japan Electronic Industry Development Association (JEIDA), "JEIDA Standard: Design rule for Camera File System", version 1.0, December 1998, available in in PDF format at http://www.pima.net/standards/it10/PIMA15740/dcf.htm (English).

[EXIFDUMP] Bousch, Thierry, exifdump.py, v 1.13 (Python source code for exifdump), 1999/08/21, available at
http://topo.math.u-psud.fr/~bousch/exifdump.py

[EXIFFORMAT] Tachibanaya, TsuruZoh, "Description of Exif File Format", Revision 1.2, July 19, 2000, available at
http://www.butaman.ne.jp/~tsuruzoh/Computer/Digicams/exif.html (Japanese) http://www.butaman.ne.jp/~tsuruzoh/Computer/Digicams/exif-e.html (English)

[EXIFSPEC] Japan Electronic Industry Development Association (JEIDA), "Digital Still Camera Image File Format Standard (Exchangeable image file format for digital still cameras: Exif)", version 2.1, June 1998, available in English in PDF format at http://www.pima.net/standards/it10/PIMA15740/exif.htm (English).

[JHEAD] Wandel, Matthias, "Exif Jpeg camera setting parser and thumbnail remover", available at http://www.sentex.net/~mwandel/jhead/

[JNG] Randers-Pehrson, Glenn, et. al., "JNG (JPEG Network Graphics) Specification, version 0.99, December, 2000, available at
ftp://swrinde.nde.swri.edu/pub/mng/documents.

[MNG] Randers-Pehrson, Glenn, et. al., "MNG (Multiple-image Network Graphics) Format, version 0.99", December, 2000, available at
ftp://swrinde.nde.swri.edu/pub/mng/documents.

[MNG-VLC] Randers-Pehrson, Glenn, et. al., "MNG-VLC (Multiple-image Network Graphics--Very Low Complexity) Format, version 0.99", December, 2000, available at
ftp://swrinde.nde.swri.edu/pub/mng/documents.

[PNG] Randers-Pehrson, Glenn, et. al., "PNG (Portable Network Graphics) Specification, version 1.2", July, 1999, available at
ftp://swrinde.nde.swri.edu/pub/png/documents.

[PNGEXT] Randers-Pehrson, Glenn, et. al., "Extensions to the PNG 1.2 Specification, version 1.2.0", July, 1999, available at
ftp://swrinde.nde.swri.edu/pub/png/documents.

[STOKES] Stokes, Michael, "Metadata supports graphics applications", EE Times, April 25, 2000, available at http://www.planetanalog.com/story/OEG20000425S0019 [TIFF/EP] ISO/DIS 12234-2, "Photography---Electronic still picture imaging--- Removable memory---Part 2: Image data format---TIFF/EP", November 24, 1998, available at
http://www.pima.net/standards/iso/standards/documents/N4378.pdf

[ZLIB] Deutsch, L. Peter, and Jean-loup Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, Aladdin Enterprises, May 1996.
ftp://ftp.isi.edu/in-notes/rfc1950.txt

Acknowledgments

• Adam M. Costello suggested the "newline, equal-sign" pair to represent non-terminating newlines.

[HOME] | [UP]