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