PNG and MNG tools EXIF and PNG

Converting TIFF-EP or EXIF files to PNG format (Draft 0.05, July 31, 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/d005.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 the preceding editions, 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 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.

Scope:

This document proposes a new PNG [PNG] registered keyword, "EXIF", and a new PNG special-purpose 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

It is desireable to save the EXIF information present in some camera images because

• The information is useful in its own right
• 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.

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

Applications that convert an image back to the original format need to know whether the image data has been changed, and must be able to rely on the saved EXIF data being in a machine-parseable format and to rely on the data being valid.

The PNG format does not presently formally accommodate EXIF data. It could be stored in PNG text chunks, but a formal specification for storing EXIF data is required, to ensure that the data will remain valid and be machine-parseable. This proposal includes a provision that text chunks containing EXIF data provide a warning that the chunk is not to be edited manually.

A flag is required by which applications can determine whether the image data might have been edited in a manner that invalidates the stored EXIF data. The PNG specification provides copying rules that would allow a new "eXIF" chunk, which would not be recognized by current applications, to serve this purpose. Applications that modify the image data and do not recognize the 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 eXIF chunk serves as the needed flag.

Terminology

textEXIF chunk

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

Mapping of TIFF-EP data 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 the data for each item. In TIFF-EP tags whose data is a string ending with a null, the terminating null is replaced with a newline character, and embedded newlines are permitted. Converters must verify that the character-count field in tags that contain strings is correct, because the terminating null is not available for use by decoders. Any CRLF sequences in such strings are replaced with the newline character, and the character-count is adjusted accordingly. 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 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)
     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 data must either change the "editing_status" field to 1 or discard the chunk. If they make changes that invalidate the EXIF data, they must discard 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 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 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 data contained in the text/EXIF chunks should check for the presence of an 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 data is still valid. The "editing_status" field of the eXIF chunk can then be used to tell whether the image data was modified or not.

Do not write the 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..

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] software could be easily modified to do the job.

If you wish to write software to evaluate this proposal, you must not write 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 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 eXIF or 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:

• Items marked with "?" in the table.

• Get a copy of the actual EXIF spec.

• Is the tag list complete? (no, e.g. SecurityClassification and ImageHistory are 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 all four example MakerNotes in [EXIFFORMAT]?

• 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. One possibility is to translate CRLF to "space, newline" and not change the character count, and to require converters to check the character-count for correctness. It is important for the character count to be correct, so the decoder will find the end of string and beginning of the next keyword.

• 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 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 text/EXIF chunk CRC's in the eXIF chunk.
• Draft 0.04
  • Revised copyright and license.
  • Added instructions not to write 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.

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] I have not seen the formal specification of the EXIF format. It is not available on-line.

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

[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

[HOME] | [UP]