Re: DRAFT: eXIF 2017-03-05

Willem van Schaik wrote:
> The first two bytes of data are either "II" for little endian or "MM"
> for big endian. Decoders should check the first four bytes to ensure
> that they have the following decimal values:

Good idea also, not strictly necessary, but useful for clarity. It's
not necessary because it's been said already, in a previous paragraph,
that "it begins with either "II" or "MM" [...] and contains a TIFF
header [...]"; so the section "Recommendations for Decoders" directly
translates this prose into plain pseudocode-ish "check and see if it's
these four bytes or those four bytes". I agree with the clarification,
though, because it's not immediately obvious that 73,73 stand for "II"
and 77,77 stand for "MM".

But I find it mildly confusing, because it "almost" looks like a typo.
(So what should I check after all, the first two bytes, or the first
four bytes?...)

How about:

"Decoders should check the first four bytes of data to ensure that
they have the following decimal values:
<pre>
    73, 73, 42, 0
    (ASCII "II", followed by the TIFF version number in the Intel byte order)
</pre>
or
<pre>
    77, 77, 0, 42
    (ASCII "MM", followed by the TIFF version number in the Motorola byte order)
</pre>"

Welcome back, Willem :-)

John Bowler wrote:
> Simpler (a response to Phil, Cosmin and Willem all):
> "The data shall be a valid TIFF stream conforming to the EXIF requirements."

I am ok in principle if the text is made simpler, instead of more
complex, except:

> Saying anything more than the above paragraph will end up not
> permitting raw JPEG APP1 data to be included and will lead down a
> twisty path to an expectation that decoding libraries can be dinged
> for not enforcing spurious data consistency checks.

You should at least enforce encoders and decoders to agree, or else
there can and will be loss of user data. Decoders should know to check
for "II\x2a\x00" or "MM\x00\x2a", at the very least (which should be
clearly stated). Encoders should know to start the stream with
"II\x2a\x00" or "MM\x00\x2a", at the very least (which needs not be
re-stated if it's clearly implied).

This should not be any different from recommending a PNG-embedding
file format (such as the Microsoft Office document format) to check
for the PNG signature (8 bytes), at the very least.

JPEG-to-PNG conversion is a broken use case, anyway, and complicating
the design in order to accommodate this use case is a bad idea. What
we are importantly borrowing from JPEG, and following (as Chris said
explicitly), is the EXIF workflow.

Sincerely,
Cosmin

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