Re: CFD: zXIF 2017-0207

Cosmin Truta <[email protected]> Sun, 12 Feb 2017 15:10:51 -0500
Newsgroups gmane.comp.graphics.png.general
Message-ID <CAAoVtZxXGgUr=7jH80bO24+CbBmEFv380d5ebEO30HoCDu5gdA@mail.gmail.com>
On 12 February 2017 at 12:53, Pavel Zlatovratskii <[email protected]> wrote:
> Well, I see I had some misunderstanding about EXIF gamma, but I still
> think it should be unsafe-to-copy(like mentioned in CIPA 2016).

See the following statement in the draft document:

"It is beyond the scope of this specification to resolve potential
conflicts between data in the eXIf chunk and in other PNG chunks"

Also, could you clarify in what context are you talking about gamma?
Because sRGB does not have a gamma, only AdobeRGB has one. In sRGB,
the transfer function is not a gamma function, but only an
approximation of it (with an approximate value 2.2). For this reason,
in all of my photos, I only see a gamma value when I save the image in
the AdobeRGB profile, and I see no such thing when I save the image in
the sRGB profile.

Also for this reason, the PNG specification says the following, explicitly:

"When the sRGB chunk is present, it is recommended that decoders that
recognize it and are capable of colour management [ICC] ignore the
gAMA and cHRM chunks and use the sRGB chunk instead."

and:

"When the iCCP chunk is present, PNG decoders that recognize it and
are capable of colour management [ICC] shall ignore the gAMAand cHRM
chunks and use the iCCP chunk instead and interpret it according to
[ICC-1] and [ICC-1A]."

So:

There is no gamma field in sRGB EXIF images, because it strictly
doesn't apply. (There is gAMA in sRGB PNG, because PNG allows it to
loosely apply, but we're talking about EXIF here.) There is a gamma
field in AdobeRGB EXIF images, but that is a redundant piece of
information, because the ICC profile that comes with AdobeRGB images
already have that.

You may add a gamma field of value 2.2 to an sRGB image, but it will
change nothing, because it is a redundant.

You may add a gamma field of value other than 2.2 to an sRGB image,
but that would be incorrect.

You may add a gamma field of any value to any image that is not an
sRGB image (and has a custom ICC profile, AdobeRGB or anything else).
But again, that would be redundant.

A gamma value only has effect when you have no other color profile
information. I would like to see a sample image with that sort of EXIF
data (i.e. with gamma but with no color profile, and not even a
reference to a color profile).

Being opposed to an EXIF chunk on the grounds of the importance of
gamma, an utterly redundant field for all practical purposes that I'm
aware of, is just not the best thing to do. (Although you are entitled
to your opinion, of course.)

>> As a further example, take a look at Google WebP container
>> specification. Like the current PNG eXIf design that comes in addition
>> to our current colorimetry info, they have designed provisions for
>> both EXIF and ICC.
>> https://developers.google.com/speed/webp/docs/riff_container

> Google prefer does not develop their own way to keep metadata and rely
> on EXIF(XMP).

Yes. That's why WebP is technically more desirable for digital
photography applications than PNG and JPEG combined. It does lossy
compression that's better than JPEG, and lossless true-color
compression that's better than PNG. And it does ICC, EXIF and XMP. It
really does everything that's needed.

With PNG/EXIF, we try to compete with TIFF/EXIF, and to a lesser
extent (due to lack of popularity but definitely not due to lack of
merit), with WebP.

> PNG prefer to use own way to keep metadata. That's very important
> difference for me. And that's why I prefer PNG(and don't want it to
> morph into PNG image + EXIF).

In theory, that would be nice :-)

In reality, there have been a few attempts in the past, all of which failed.

We have no expertise to define them, Pavel, and no spare time to do it
for the hundreds.

We need people to do *work* to define each one of them. We need people
to have *knowledge* of what should go into each one of them. Or else,
we will end up remaining where we currently are, with no way to store
EXIF data for reliable retrieval.

So if you come and tell us that's not what we should do, we should do
it in this other harder way, it would be nice to bring some knowledge
of your own to the table. Reading the CIPA document is far from
sufficient.

>> You are right in principle, but it's impossible in practice. [...]

> It's about 80 if we're talking about EXIF IFD.

The bulk are in the MakerNotes. The semantics are in the various
technical and scientific documents. It's not just many fields; it's a
huge amount of information behind them, also.

> And these 80 attributes is lack some properties which are saved by
> camera makers within 'MakerNote': manual or auto focus(and so we need
> difference between measured subject distance and set focal plane
> distance); type of auto focus; flash energy compensation; age of camera
> (in days or in shots)...

Right. A lot more. And some of them are fundamentally important, such
as lens distortion information.

> By the way, I've not found in EXIF specification marker that lens
> distortion was removed (like "de-fish" in your example). Is there any?

Of course! There is the lens make and model, then there is the
aperture and focal length used at the time of capture, and from this,
query the database of lenses and apply the correction based on the
information found. This is how DxO tools do it, for example. (And no,
I didn't say that it was easy.)

And then, there are also lens-specific (therefore
manufacturer-specific) parameters in the MakerNotes.

For informative purposes, have a look at this article:
http://www.kenrockwell.com/tech/dxo/optics-pro.htm

But even more importantly, please do some in-depth studying on this
matter and understand how difficult it is. We can barely go forward
with this compressed-vs-uncompressed disagreement, or
safe-to-copy-vs-unsafe-to-copy disagreement; do you think we will have
any better chances with these very very many EXIF fields, some of
which are very very hard to understand?

I challenge you to understand the lens distortion parameters in
MakerNotes, at the very least, and explain to us how would you propose
to standardize that thing alone in a PNG chunk. And after that,
extrapolate your effort to the plethora of other fields found in EXIF
(and I emphasize on "found", which is way beyond what's written in
CIPA-2016).

Sincerely,
Cosmin

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