PNG and MNG tools Exif and PNG

Converting TIFF/EP or Exif files to and from the PNG format (Draft 0.14, August 8, 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/d014.html

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) and a new special-purpose proposed chunk (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.

Scope:

This document proposes a new PNG [PNG] registered keyword, "Exif", and a new PNG special-purpose proposed chunk, "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 that is both machine and human readable
• a new proposed "eXIF" registered PNG chunk by which applications can determine whether the image data might have been edited in a manner that invalidates the stored Exif information. The PNG specification provides copying rules that would allow such a chunk, which would not be recognized by current applications, to serve this purpose. Applications that modify the image data and do not recognize the proposed eXIF chunk are required by the PNG specification to discard it, and applications that edit a PNG file without changing the image data are required to retain it; therefore, the presence or absence of the proposed eXIF chunk serves as the desired flag.

Terminology

CRC

Cyclic Redundancy Check (see the PNG specification).

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.

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 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 should be written in a single textExif chunk (multiple chunks can be used, provided that no particular tag appears in more than one of them), with a newline terminating each entry (a newline that does not terminate the entry is written as a newline immediately followed by an equal-sign, which pair of characters is considered to be a single whitespace character that does not terminate the entry). 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 all newlines. 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

The proposed eXIF chunk

     1 byte:  editing_status
              0: image has not been edited
              1: image has been edited by an
                Exif-cognizant application
     1 byte:  current_orientation (1, 3, 6, 8, or 9)
     1 byte:  newline_type (0: unknown 1: newline; 2: CRLF)
     2 bytes: (unsigned integer in network byte order)
              number of textExif chunks in the PNG datastream.
     4 bytes: CRC of a textExif chunk
     4 bytes: CRC of another textExif chunk
     etc.,    until the CRCs of all textExif chunks have been
              listed, in no particular order.
             

Applications that are cognizant of Exif and have edited the image data in a manner that does not invalidate the Exif information must either change the "editing_status" field to 1 or discard the chunk. If they make changes that invalidate the Exif information, they must discard the proposed eXIF chunk. If they change any textExif chunk without invalidating it, they must update its CRC in the eXIF chunk.

If an application reorients an image, it must update the "current_orientation" field. If it edits the Exif "Orientation" tag, it must also update the proposed eXIF chunk's "current_orientation" field, to maintain the proper relationship between the two values.

PNG-compliant applications that are not cognizant of Exif are required by the PNG specification to discard the proposed eXIF chunk if they edit the PNG file in any manner that changes any critical chunk.

Applications that wish to determine the validity of the Exif information contained in the textExif chunks should check for the presence of the proposed eXIF chunk. If none is present, it can be concluded that the file has been edited by an application that is not cognizant of Exif. If it is present, then it can be concluded that the Exif information is still valid. The "editing_status" field of the proposed eXIF chunk can then be used to tell whether the image data was modified or not.

If any string in the Exif data has embedded newlines or CRLFs, the "newline_type" byte must be 1 or 2. If none are present, 0 is acceptable.

Do not write the proposed eXIF chunk in any PNG files until it is registered, Until then, its specification is subject to change. For testing and evaluation purposes, write an "exIF" chunk (lower-case "x") instead, bearing in mind that the specification for the chunk might change..

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 newline_type byte of the eXIF chunk, 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.

If you wish to write software to evaluate this proposal, you must not write proposed eXIF chunks until this chunk type is registered by the PNG group. Instead, use a lower-case "x" to write an exIF chunk which has the same syntax as the proposed eXIF chunk but is a private unregistered chunk. Your software may read the proposed eXIF chunk in anticipation of its approval, however, bearing in mind that the specification for the chunk might change.

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.

Issues to be resolved:

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

• Items marked with "?" in the table.

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

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

• Get a copy of the actual Exif spec.

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

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

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

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

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.

References:

[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 still cameras: Exif)", version 2.0, November 1997. I have not seen this formal specification of the EXIF format. It is not available on-line.

[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.97, February, 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.97", February, 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.97", February, 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

Acknowledgments

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

[HOME] | [UP]