Re: DRAFT: eXIF 2017-03-05

Phil Harvey <phil-CIeU6mJ2MbMd166Dz3SrqbDks+cytr/[email protected]> Mon, 6 Mar 2017 20:48:47 -0500
Newsgroups gmane.comp.graphics.png.general
Message-ID <[email protected]>
> From: Glenn Randers-Pehrson <[email protected]>
> 
> Revised this paragraph to read
> 
> The data segment of the eXIf chunk contains an Exif profile 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, and padding byte, are not included.  Therefore, it
> begins with either "II" or "MM", depending upon the byte order used,
> and it contains a TIFF header plus a 0th IFD (Image File Directory)
> and a 1st IFD; the 0th IFD contains pointers to an Exif IFD and/or a
> GPS IFD; and the 1st IFD contains a thumbnail image.  Any IFD may be
> omitted.  Any gap preceding an IFD is filled with padding bytes of
> unspecified content.

I have 2 problems with this.

1. I still object to saying that IFD0 may be omitted, because it may not.  You MUST have at least include the entry count for IFD0  (which will be 0 if the IFD is empty), so technically I maintain that IFD0 must exist if IFD1 exists.

2. There is absolutely no need to say that any gap is filled.  It is only required that the IFD pointers point to the start of the IFD.  It doesn't matter what comes before it.  Some EXIF/TIFF writers will put the values first, and others will put the IFD first.   I have also see unreferenced data come first.  Any of these is fine.

- Phil


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford