Re: Endless gamma in eXIf 2017-0119

John Bowler <[email protected]>
Newsgroups gmane.comp.graphics.png.general
Message-ID <CAP7U399g+CMXSrPyGgEEQZZvvw0ety-VJMO_HcDj3=ot27=ZiA@mail.gmail.com>
I think people need to consider this issue carefully when voting, it
would also be helpful to know when a voter felt that the issue was
decisive one way or the other, just like Pavel did.

Certainly there are two possible approaches.  The one used in both the
eXIf and zXIf proposals allows an EXIF chunk aware PNG editor to store
the *original* information even though it may no longer apply.

This happens because the "security considerations" section permits it;
if that section was not there, regardless of the safe-to-copy bit, an
editor would have to ensure the consistency of the information either
by updating it or discarding it.  This is mandated by the section of
the ISO-PNG spec that I quoted.

So, by default, the chunk would have to be eXIF (not safe to copy) and
editors which supported it would have to either modify the chunk or
completely remove it when the image was changed.  If you want that
vote NO on both proposals.  If you want the behavior with Soni L.
described and are satisfied that the specification (compressed or not)
has adequate description for decoders then you might choose to vote
YES on on or the other, or both, proposals.

Notice that the current proposals are not intended to prevent the use
of the image-related metadata from the chunk; rather it is the case
that it may be outdated and, as in Glenn's edited examples, there may
be no indication of this.  As Soni L. observed:

>Shouldn't eXIf be considered "sensor/camera data" and thus only useful for ppl who >know what they're doing, and not automatically mangled into the image?

Yes; that's how I see it.  It's used to allow a digital camera image
to be expressed in PNG and the workflows which use it will be similar
to the ones which use EXIF in JPEG or TIFF.   Exactly the same problem
of maintaining it without updating it exists in JPEG and TIFF too, and
of course it already exists in the current zTXt encoding.

-- 
John Bowler <[email protected]>
+1 (541) 450-9885
PO BOX 3151
KERBY OR 97531-3151
USA

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