Converting TIFF/EP or Exif files to PNG format (Draft 0.12, August 5, 2000)

Converting TIFF/EP or Exif files to and from the PNG format (Draft 0.12, August 5, 2000)

Notices:

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.

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.
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". Abbreviated "tE" in the encoding table.
textExif entry: A "keyword=DATA;\n" sequence in a textExif chunk.
textExif keyword: The keyword 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 keywords 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.

Encodings:

drop: do not encode the item in the PNG datastream
tE: encode the item as a textExif entry in a textExif chunk, in the form "keyword=DATA;". It is terminated with a semicolon immediately followed by a newline. The keyword is the same as the tag name and is case dependent. No whitespace is permitted between the keyword and the equal-sign. Whitespace may separate the equal-sign and the DATA (but only one whitespace character may separate them, if the DATA begins with a STRING or SUBSTRING). If there is a discrepancy between the spelling given here and the spelling in [TIFF/EP], the latter shall prevail. The DATA is one or more of
- NUMBER: a numeric entry written an ASCII string as explained in [PNGEXT]. If there are multiple NUMBERs, they are separated whitespace. (NUMBER is usually an integer, but can also be a decimal with fractional part)
- CHAR: a single ASCII character.
- HEX: a string of bytes, each encoded in hexadecimal format using two ASCII characters 0-9, upper case A-F, and lower case a-f. Whitespace may be included in strings of HEX bytes to improve readability. Decoders must ignore the embedded whitespace.
- STRING: a Latin-1 string [LATIN-1] which is the same as a string contained in an Exif or TIFF/EP tag except that the terminating NULL is removed and any embedded newlines or CR,LF sequences are replaced with a newline followed by an equal-sign (\n=). A single whitespace character (the "\n=" sequence is considered to be a single whitespace character for this purpose) may precede the STRING and is not included in it. If multiple whitespace characters appear, all but the first form the beginning of the string.
- SUBSTRING: a Latin-1 string [LATIN-1] which is the same as a string contained in an Exif or TIFF/EP tag, within a tag that has more than one parameter (the OECF tag is the only known example of this). The terminating NULL is replaced with a semicolon and one optional whitespace character, any embedded CR,LF sequences are replaced with a newline and an equal-sign (\n=), and any embedded semicolons are replaced with two consecutive semicolons. Additional whitespace may follow the terminal semicolon if the next item in the list is not a SUBSTRING. For example, a typical OECF tag could be encoded as
```
    OECF= 4 3\n
    =Camera log exposure; Red output level;\n
    =Green output level; Blue output level;\n
    = -3.0  10.2  12.4   8.9\n
    = -2.0  48.1  47.5  48.3\n
    = -1.0 150.2 152.0 148.9\n
```
- other: as explained in the table

TIFF/EP Tag	Exif Item Name	Note	PNG encoding

0x0FE *	NewSubfileType		drop
0x0FF *	SubfileType		drop
0x100	ImageWidth	[1]	width in IHDR and tE NUMBER
0x101	ImageLength		height in IHDR and tE NUMBER
0x102	BitsPerSample	[2]	sBIT
0x103	Compression	[3]	tE NUMBER
0x106	PhotometricInterpretation		tE
0x10A	FillOrder	[4]	drop?
0x10D	DocumentName		text Title STRING
0x10E	ImageDescription		text Description STRING
0x10F	Make		tE STRING
0x110	Model		tE STRING
0x111	StripOffsets		drop
0x112	Orientation	[5]	tE NUMBER
0x115	SamplesPerPixel		drop
0x116	RowsPerStrip		drop
0x117	StripByteCounts		drop
0x11A	XResolution	[6]	xppm in pHYs
0x11B	YResolution	[6]	yppm in pHYs
0x11C	PlanarConfiguration		tE NUMBER
0x128	ResolutionUnit	[6]	unit=1 in pHYs
0x12D *	TransferFunction	[7]	tE 3*NUMBER
0x131	Software		tE STRING
0x132	DateTime	[8]	text Creation time STRING
0x13B	Artist		text Author STRING
0x13D *	Predictor		drop
0x13E	WhitePoint		white point in cHRM
0x13F	PrimaryChromaticities		chromaticities in cHRM
0x156 *	TransferRange		tE ?
0x15B	JPEGTables	[9]	drop
0x200	JPEGProc		drop
0x201	JPEGInterchangeFormat		drop
0x202	JPEGInterchangeFormatLength		drop
0x211	YCbCrCoefficients	[10]	drop
0x212	YCbCrSubSampling		drop
0x213	YCbCrPositioning		drop
0x214	ReferenceBlackWhite		tE 2*NUMBER
0x828D	CFARepeatPatternDim		tE 2*NUMBER
0x828E	CFAPattern		CFArowsCFAcolsNUMBER
0x828F	BatteryLevel		tE NUMBER or STRING
0x8298	Copyright		text Copyright
0x829A	ExposureTime		tE (1 or 2)*NUMBER
0x829D	FNumber		tE (1 or 2)*NUMBER
0x83BB	IPTC/NAA		tE NUMBER or STRING
0x8769	ExifOffset		drop
0x8773	InterColorProfile	[11]	iCCP
0x8822	ExposureProgram		tE NUMBER
0x8824	SpectralSensitivity		tE STRING
0x8825	GPSInfo		write individual GPS tags as tE
	GPSVersionID		tE 4*NUMBER
	GPSLatitudeRef		tE CHAR
	GPSLatitude		tE 3*NUMBER
	GPSLongitudeRef		tE CHAR
	GPSLongitude		tE 3*NUMBER
	GPSAltitudeRef		tE CHAR
	GPSAltitude		tE NUMBER
	GPSTimeStamp		tE 3*NUMBER
	GPSSatellites		tE STRING
	GPSStatus		tE CHAR
	GPSMeasureMode		tE CHAR
	GPSSDOP		tE NUMBER
	GPSSpeedRef		tE CHAR
	GPSSpeed		tE NUMBER
	GPSTrackRef		tE CHAR
	GPSTrack		tE NUMBER
	GPSImgDirectionRef		tE CHAR
	GPSImgDirection		tE NUMBER
	GPSMapDatum		tE STRING
	GPSDestLatitudeRef		tE CHAR
	GPSDestLatitude		tE 3*NUMBER
	GPSDestLongitudeRef		tE CHAR
	GPSDestLongitude		tE 3*NUMBER
	GPSDestBearingRef		tE CHAR
	GPSDestBearing		tE NUMBER
	GPSDestDistanceRef		tE CHAR
	GPSDestDistance		tE NUMBER
0x8827	ISOSpeedRatings		tE (1 or 2)*NUMBER
0x8828	OECF	[12]	tE ...
0x8829*	Interlace		drop
0x882A	TimeZoneOffset		tE (1 or 2)*NUMBER
0x882B	SelfTimerMode		tE NUMBER
0x9000	ExifVersion		tE 4*NUMBER
0x9003	DateTimeOriginal	[13]	tE STRING
0x9004	DateTimeDigitized	[14]	tE STRING
0x9101	ComponentsConfiguration		tE 4*NUMBER
0x9102	CompressedBitsPerPixel		tE NUMBER
0x9201	ShutterSpeedValue		tE NUMBER
0x9202	ApertureValue		tE NUMBER
0x9203	BrightnessValue		tE (1 or 2)*NUMBER
0x9204	ExposureBiasValue		tE (1 or 2)*NUMBER
0x9205	MaxApertureValue		tE NUMBER
0x9206	SubjectDistance		tE (1 or 2)*NUMBER
0x9207	MeteringMode		tE NUMBER
0x9208	LightSource		tE NUMBER
0x9209	Flash		tE NUMBER
0x920A	FocalLength		tE (1 or 2)*NUMBER
0x920B	FlashEnergy	[15]	tE (1 or 2)*NUMBER
0x920C	SpatialFrequencyResponse		tE STRING
0x920D	Noise		tE STRING
0x020E	FocalPlaneXResolution		tE NUMBER
0x920F	FocalPlaneYResolution		tE NUMBER
0x9210	FocalPlaneResolutionUnit		tE NUMBER
0x9211	ImageNumber		tE NUMBER
0x9212	SecurityClassification		tEXt Warning Classified
	FileSecurityClassification		tE STRING
	FileCodewords		tE STRING
	FileControlAndHandling		tE STRING
	FileReleasingInstructions		tE STRING
	FileClassificationAuthority		tE STRING
	FileSecurityControlNumber		tE STRING
	FileSecurityDowngrade		tE STRING
	FileSecurityDowngradingEvent		tE STRING
0x9213	ImageHistory		tE STRING
0x9214	SubjectLocation		tE (2, 3, or 4)*NUMBER
0x9215	ExposureIndex		tE (1 or 2)*number
0x9216	TIFF/EPStandardID		tE 4*NUMBER
0x9217	SensingMethod		tE NUMBER
0x927C	MakerNote	[16]	tE HEX
0x9286	UserComment		text Comment/tE
0x9290	SubSecTime		tE STRING
0x9291	SubSecTimeOriginal		tE STRING
0x9292	SubSecTimeDigitized		tE STRING
0xA000	FlashPixVersion		tE 4*NUMBER
0xA001	ColorSpace		tE NUMBER
0xA002	ExifImageWidth		tE NUMBER
0xA003	ExifImageLength		tE NUMBER
0xA004*	RelatedSoundFile		tE STRING
0xA005	InteroperabilityOffset		drop
0xA20B*	FlashEnergy	[17]	tE (1 or 2)*NUMBER
0xA20C*	SpatialFrequencyResponse		tE STRING
0xA20E*	FocalPlaneXResolution		tE NUMBER
0xA20F*	FocalPlaneYResolution		tE NUMBER
0xA210*	FocalPlaneResolutionUnit		tE NUMBER
0xA214*	SubjectLocation		tE (2, 3, or 4)*NUMBER
0xA215*	ExposureIndex		tE (1 or 2)*number
0xA217*	SensingMethod		tE NUMBER
0xA300*	FileSource		tE NUMBER
0xA301*	SceneType		tE NUMBER
	PNG_DigitalZoom	[18]	tE NUMBER

The tag list was obtained from the exifdump source code [EXIFDUMP], and compared with the tag list in the TIFF/EP Standard [TIFF/EP]. See also the "Description of the Exif file format" [EXIFFORMAT], which was generated by inspection of Exif files, without reference to the actual Exif specification [EXIFSPEC].
Notes:
[*] Not in TIFF/EP
[1] If the file is later cropped, don't change the textExif width and height; they record the original width and height.
[2] The sBIT chunk is unnecessary and should not be written if the original file and the PNG file to which it is being converted have the same sample depth.
[3] This identifies the compression method used in the original file.
[4] Details about the original compression are of no further use and should be dropped. If an application converts the PNG file back to a TIFF/EP or ELIF file, it must supply these details with respect to the new file that it is creating.
[5] This identifies the orientation of the original file. Converters should orient the pixels in the PNG or JNG file with the first pixel representing the top left corner of the image, using a lossless method of rotation. An application that converts a PNG or JNG back to TIFF/EP format must restore the image to an orientation that has the same width and height as the original, using a lossless method of rotation. If the proposed eXIF chunk is present, its "current_orientation" field can be consulted to distinguish between right-side-up and upside-down images, and the application can either reorient the image or revise the value in the "Orientation" tag that it writes.
[6] Resolution must be converted to meters
[7] Is this related to gamma? If so, a gAMA chunk should be written. It is recorded in EV units, so it isn't directly gamma.
[8] This is the time the image was originally recorded by the camera. But see also [13]; how do these tags differ?
[9], [10] This information is recorded in the JPEG datastream.
[11] If the ICC profile is the sRGB profile, then write an sRGB chunk instead of an iCCP chunk (note that DCF images are always in sRGB).
[12] The OECF table is stored as
tE rows columns n*header n*value
where n=rows*columns. "rows" and "columns" are written as NUMBER, the n headers are each written as a SUBSTRING (with a semicolon terminating each), and the values are written as NUMBER. [13] A tIME chunk can also be written, containing the time that the image was first converted to the PNG or JNG format. If the image is later modified, the tIME chunk will be overwritten with the modification time.
[14] A text "Creation time" chunk should also be written with this time.
[15] Some of the TIFF tags 0x920B through 0x9217 are duplicates of 0xA20B through 0xA217. The former appear in the ISO Standard for TIFF/EP [TIFF/EP], but the latter have been written by some applications.
[16] Since the contents of MakerNote are not known for all vendors, and since it can contain NULL-terminated strings, it is stored as a string of hexadecimal numbers.
[17] See [15].
[18] Extract the digital zoom factor from the MakerNote, if present, and convert it to a rational number (e.g., PNG_DigitalZoom 2.0). Normal is 1.0.

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

The proposed eXIF chunk contains the editing status of the PNG file. Its data field contains the following:

     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.

Exif Item Name	PNG encoding	TIFF/EP Tag
ApertureValue	tE NUMBER	0x9202
Artist	text Author STRING	0x13B
BatteryLevel	tE NUMBER or STRING	0x828F
BitsPerSample	sBIT	0x102
BrightnessValue	tE (1 or 2)*NUMBER	0x9203
CFAPattern	CFArowsCFAcolsNUMBER	0x828E
CFARepeatPatternDim	tE 2*NUMBER	0x828D
ColorSpace	tE NUMBER	0xA001
ComponentsConfiguration	tE 4*NUMBER	0x9101
CompressedBitsPerPixel	tE NUMBER	0x9102
Compression	tE NUMBER	0x103
Copyright	text Copyright	0x8298
DateTime	text Creation time STRING	0x132
DateTimeDigitized	tE STRING	0x9004
DateTimeOriginal	tE STRING	0x9003
DocumentName	text Title STRING	0x10D
ExifImageLength	tE NUMBER	0xA003
ExifImageWidth	tE NUMBER	0xA002
ExifOffset	none	0x8769
ExifVersion	tE 4*NUMBER	0x9000
ExposureBiasValue	tE (1 or 2)*NUMBER	0x9204
ExposureIndex	tE (1 or 2)*number	0x9215
ExposureIndex	tE (1 or 2)*number	0xA215*
ExposureProgram	tE NUMBER	0x8822
ExposureTime	tE (1 or 2)*NUMBER	0x829A
FNumber	tE (1 or 2)*NUMBER	0x829D
FileClassificationAuthority	tE STRING	none
FileCodewords	tE STRING	none
FileControlAndHandling	tE STRING	none
FileReleasingInstructions	tE STRING	none
FileSecurityClassification	tE STRING	none
FileSecurityControlNumber	tE STRING	none
FileSecurityDowngrade	tE STRING	none
FileSecurityDowngradingEvent	tE STRING	none
FileSource	tE NUMBER	0xA300*
FillOrder	none	0x10A
Flash	tE NUMBER	0x9209
FlashEnergy	tE (1 or 2)*NUMBER	0xA20B
FlashEnergy	tE (1 or 2)*NUMBER	0x920B
FlashPixVersion	tE 4*NUMBER	0xA000
FocalLength	tE (1 or 2)*NUMBER	0x920A
FocalPlaneResolutionUnit	tE NUMBER	0xA210*
FocalPlaneResolutionUnit	tE NUMBER	0x9210
FocalPlaneXResolution	tE NUMBER	0xA20E*
FocalPlaneXResolution	tE NUMBER	0x020E
FocalPlaneYResolution	tE NUMBER	0x920F
FocalPlaneYResolution	tE NUMBER	0xA20F*
GPSAltitude	tE NUMBER
GPSAltitudeRef	tE CHAR
GPSDestBearing	tE NUMBER
GPSDestBearingRef	tE CHAR
GPSDestDistance	tE NUMBER
GPSDestDistanceRef	tE CHAR
GPSDestLatitude	tE 3*NUMBER
GPSDestLatitudeRef	tE CHAR
GPSDestLongitude	tE 3*NUMBER
GPSDestLongitudeRef	tE CHAR
GPSImgDirection	tE NUMBER
GPSImgDirectionRef	tE CHAR
GPSInfo	write individual GPS tags as tE	0x8825
GPSLatitude	tE 3*NUMBER
GPSLatitudeRef	tE CHAR
GPSLongitude	tE 3*NUMBER
GPSLongitudeRef	tE CHAR
GPSMapDatum	tE STRING
GPSMeasureMode	tE CHAR
GPSSDOP	tE NUMBER
GPSSatellites	tE STRING
GPSSpeed	tE NUMBER
GPSSpeedRef	tE CHAR
GPSStatus	tE CHAR
GPSTimeStamp	tE 3*NUMBER
GPSTrack	tE NUMBER
GPSTrackRef	tE CHAR
GPSVersionID	tE 4*NUMBER
IPTC/NAA	tE NUMBER or STRING	0x83BB
ISOSpeedRatings	tE (1 or 2)*NUMBER	0x8827
ImageDescription	text Description STRING	0x10E
ImageHistory	tE STRING	0x9213
ImageLength	height in IHDR and tE NUMBER	0x101
ImageNumber	tE NUMBER	0x9211
ImageWidth	width in IHDR and tE NUMBER	0x100
InterColorProfile	iCCP	0x8773
Interlace	none	0x8829*
InteroperabilityOffset	none	0xA005
JPEGInterchangeFormat	none	0x201
JPEGInterchangeFormatLength	none	0x202
JPEGProc	none	0x200
JPEGTables	none	0x15B
LightSource	tE NUMBER	0x9208
Make	tE STRING	0x10F
MakerNote	tE HEX	0x927C
MaxApertureValue	tE NUMBER	0x9205
MeteringMode	tE NUMBER	0x9207
Model	tE STRING	0x110
NewSubfileType	none	0x0FE*
Noise	tE STRING	0x920D
OECF	tE ...	0x8828
Orientation	tE NUMBER	0x112
PhotometricInterpretation	tE	0x106
PlanarConfiguration	tE NUMBER	0x11C
PNG_DigitalZoom	tE NUMBER
Predictor	none	0x13D*
PrimaryChromaticities	chromaticities in cHRM	0x13F
ReferenceBlackWhite	tE 2*NUMBER	0x214
RelatedSoundFile	tE STRING	0xA004*
ResolutionUnit	unit=1 in pHYs	0x128
RowsPerStrip	none	0x116
SamplesPerPixel	none	0x115
SceneType	tE NUMBER	0xA301*
SecurityClassification	tEXt Warning Classified	0x9212
SelfTimerMode	tE NUMBER	0x882B
SensingMethod	tE NUMBER	0x9217
SensingMethod	tE NUMBER	0xA217*
ShutterSpeedValue	tE NUMBER	0x9201
Software	tE STRING	0x131
SpatialFrequencyResponse	tE STRING	0x920C
SpatialFrequencyResponse	tE STRING	0xA20C*
SpectralSensitivity	tE STRING	0x8824
StripByteCounts	none	0x117
StripOffsets	none	0x111
SubSecTime	tE STRING	0x9290
SubSecTimeDigitized	tE STRING	0x9292
SubSecTimeOriginal STRING	tE	0x9291
SubfileType	none	0x0FF*
SubjectDistance	tE (1 or 2)*NUMBER	0x9206
SubjectLocation	tE (2, 3, or 4)*NUMBER	0x9214
SubjectLocation	tE (2, 3, or 4)*NUMBER	0xA214*
TIFF/EPStandardID	tE 4*NUMBER	0x9216
TimeZoneOffset	tE (1 or 2)*NUMBER	0x882A
TransferFunction	tE 3*NUMBER	0x12D*
TransferRange	tE ?	0x156*
UserComment	text Comment/tE	0x9286
WhitePoint	white point in cHRM	0x13E
XResolution	xppm in pHYs	0x11A
YCbCrCoefficients	none	0x211
YCbCrPositioning	none	0x213
YCbCrSubSampling	none	0x212
YResolution	yppm in pHYs	0x11B

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

This section provides some of the reasoning behind the decisions made in forming this proposal.

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:

Items marked with "?" in the table.
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.

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]