Re: EXIF support in PNG

John Bowler <[email protected]>
Newsgroups gmane.comp.graphics.png.general
Message-ID <CAP7U398PhHgprQEMLnUsA-gZ1_-o_1VUqOepWHGE7Kbq_T0ZiQ@mail.gmail.com>
On Thu, Jan 5, 2017 at 1:22 PM, Willem van Schaik <[email protected]> wrote:

These fields are defined by the JPEG standard:

> ffd8            Start of Image
> ffe1            APP1 Marker
> 72b5            length of APP1

JPEG encodes a 16-bit number in big-endian fashion, B.1.1.1
"Parameters", "For parameters which are 2 bytes (16 bits) in length,
the most significant byte shall come first in the interchange format's
ordered sequence of bytes."  That's a long winded definition of
big-endian, avoiding the amusing term invented by Swift:

https://en.wikipedia.org/wiki/Lilliput_and_Blefuscu

Now the following is a completely different kettle of fish; this is
defined by the EXIF people, so JEITA, CIPA, whoever.  All it is and
ID/tag, like the PNG signature:

> 4578 6966       Exif (ASCII)
> 0000

The first five bytes must match "Exif\0", then comes what I believe is
a version byte, but it's too long since I read the spec.  This tag
identifies the data as "Exif 2.0.x", or something like that.

Now a whole new ball game (kettle of fish, whatever).  What follows is
a TIFF header:

> 4D4D            MM - big endian
> 002a

And then more TIFF, up to the end, using tags defined by Exif.

> if this would be little endian (II instead of MM) then the length field
> would have been "b5 72" ?

No, because it is part of JPEG.

What I can't remember at this point is whether an APPn marker is
permitted to contain 0xFF, or whether they get stuffed (this is
genuinely a technical term from an ISO standard).  I think APPn
markers are just counted and that the byte stuffing only happens in
the Huffman or arithemetic encoded bit streams, which are outside the
markers.

> then on row 000072a0 -- because the APP1 length is 72b5, then we need to
> add one byte for the SOI, therefore I think the last bytes of the EXIF
> APP1 are "ca b7 ad 24"
>
> am I doing this correct ?

The APP1 marker is a literal length of the data including the length
itself but excluding the 0xFFE1 "marker".  From the spec (well, this
is the draft, never could afford the real thing :-(

"A marker segment consists of a marker followed by a sequence of
related parameters.  The first parameter in a marker segment is the
two-byte length parameter.  This length parameter encodes the number
of bytes in the marker segment, including the length parameter and
excluding the two byte marker."

Alas it is necessary to have four standards; JPEG, Exif, ICC for the
"Exif extended data" in APP2 and TIFF.  Well, maybe TIFF got subsumed
in Exif; I'm not sure TIFF is an international standard.

John Bowler

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.