Re: Endless gamma in eXIf 2017-0119

On Tue, Feb 7, 2017 at 7:32 PM, Glenn Randers-Pehrson <[email protected]> wrote:
> I suggest three things.
>
> 1: make the chunk unsafe-to-copy,

Yes.

> 2. remove the Security Considerations paragraph from
> the eXIf proposal (but keep the other part of Security considerations
> about uncontrolled expansion in the zXIf proposal, and

Yes

> 3. include the following three paragraphs:

These paragraphs are too open ended for a spec; they reflect the
conclusions I came to but they are wishy-washy.

The following is a bit long but these are the conclusions I came to
today (nothing like driving 200 miles through severe weather warnings
to give you time to think :-)

The normative part of a specification needs to contain direct,
unambiguous, yet minimal directives for a conforming implementation.
This is possible.  Recommendations for decoders, transcoders, encoders
and editors may be helpful but are informative, not normative.
Rationales are something that happens on this list or in an appendix
;-)

That said, CIPA created the underlying problem when they dealt with
the issues caused by the lack of formal metadata in JPEG; they ended
up creating tags for information which is directly and solely related
to the JPEG encoding such as colorspace (YCbCr) and subsampling.
Well, ok; the only other solution was to invent a formal JPEG APPn
based specification independent of EXIF but that would be an extension
to JPEG, not part of EXIF.

At the same time they semi-resolved the PNG issue by adding those
JPEG-specific EXIF tags and stating that the corresponding TIFF IFD
tags could not be included.  An analogous PNG implementation would
exclude the JPEG tags along with the relevant TIFF ones and insist
that all PNG data was stored in the normal PNG form.  For example, the
JPEG chroma sub-sampling information and the PNG sBIT information are
similar, but there would be no EXIF 'sBIT' tag, only the PNG sBIT
chunk.

This can be expressed as a simple rule for the encoder; anything that
affects the interpretation or use of the PNG image data and can be
encoded as a PNG tag shall be so encoded unless the CIPA spec already
includes a direct equivalent.  In the latter case the EXIF tag(s) may
be used instead or or as well as the PNG tag.  This is similar to
iCCP, which encodes much more powerful (and better specified) versions
of cHRM and gAMA.

That creates a problem for transcoders, which take an existing non-PNG
EXIF and transcode that and the image data to PNG format.  By the
encoder rule the transcoder would have to massage the EXIF, deleting
JPEG or TIFF specific tags, before writing it into the PNG.

A simple rule for decoders removes that requirement so that a
transcoder can copy the original EXIF verbatim.  A decoder shall
ignore any format-specific tags not directly applicable to PNG unless
external information or instructions direct otherwise.  E.g. the user
can tell the decoder to use a JPEG-specific chroma subsampling tag to
deduce that the 24-bit RGB samples actually only contain 8-bits of
luma (Y) information and 8-bits of color information, maybe allowing
processing optimizations, but, absent such a directive, the decoder
shall not assume the data is relevant.

This is slightly more complicated than the alternative, which is to
require any non-PNG related image tags to be deleted, but is more
likely to be obeyed in practice.  In any case an encoder may always
use the simple approach of only preserving the tags it understands and
a decoder, obviously, will only use the tags it does understand.

John Bowler

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot