Re: CFD: zXIF 2017-0207

Pavel, there is zero amount of overlapping between EXIF and
gAMA/cHRM/sRGB/iCCP. This is by design.

As a proof, take a look at the JPEGs or TIFFs coming out your
smartphone or digital camera. There are very high chances that you
will see both an EXIF structure and an ICC profile.

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

The reason is not just coincidence. EXIF contains colorimetry
information for the *source* (i.e. from the photo-electronic sensor to
the RGB pixels). gAMA/cHRM/sRGB/iCCP contains colorimetry information
for the *destination* (i.e. from the RGB pixels to the electronic
display or print image). In particular, there is nothing equivalent to
gAMA in EXIF (as far as I know) because the photo sensors are (as far
as I know) linear in sensitivity.

ICC information is about pixels-to-display or pixels-to-print,
therefore, if the image gets edited, and don't know what new display
is being used, you should discard the old info. In conclusion, the PNG
iCCP chunk is (as it should be) unsafe-to-copy. The same goes about
sRGB, cHRM and gAMA.

EXIF information is about source-to-pixels, therefore, even if the
image gets edited, it's still the same source information.
(Notwithstanding the thumbnails, of course, but that's easy to fix,
and we already addressed that.) In conclusion, the PNG eXIf chunk
should be safe-to-copy.

Even more so, important details such as camera, lens and exposure
information needs to be preserved, and not lost in the first
application that doesn't recognize the EXIF chunk. This is how it's
done in JPEG and TIFF editing applications, and this is how it should
be done in PNG editing applications, also.

> That's why PNG should have better metadata. And it's impossible if we
> use same EXIF.

You are right in principle, but it's impossible in practice. EXIF as a
whole has hundreds and hundreds of fields, describing virtually all of
the minutiae regarding digital photo capture. The experts who design
and manufacture digital cameras know exactly what needs to go in
there, and they do the hard work of agreeing (even if they're
competitors) and updating the EXIF specification. So what you're
saying would be nice, but we just don't have such expertise in our
group, and we should defer to their expertise instead.

Just as we deferred to the Internet Color Consortium's expertise when
we defined the iCCP chunk.

Sincerely,
Cosmin

On 10 February 2017 at 09:29, Pavel Zlatovratskii <[email protected]> wrote:
> 10.02.2017 10:07, Cosmin Truta пишет:
>> As I have already stated in my "yes" vote for eXIf, I would not
>> support an unsafe-to-copy form in any incarnation.
> My opinion is about inverse: I rather support unsafe-to-copy than
> safe-to-copy chunk(I could support some ways of safe-to-copy, but prefer
> not to do this). So I feel myself obliged to explain my position.
>
> At first I don't like idea that 'raw exif' chunk will be final and main
> way to keep camera metadata. EXIF is not 'container with camera
> metadata', it is full-featured image header with it's own logic of
> keeping properties. Sometimes EXIF duplicate PNG chunks and of course
> specification of 'full-featured Exif' may slow down proposal of keeping
> separate properties kept in EXIF.
> Like:
> *Why do we need chunk with geographic position? We have eXIf.
> *Why do we need chunk with lens specification? We have eXIf.
> Or even further:
> *Why write pHYs? We have eXIf.
> *Why write copyright tEXt? We have eXIf.
>
> Ok. I over-dramatise. I don't believe such problems will occur.
> But if there is way when even such problems couldn't be possible, I
> prefer it. And unsafe-to-copy eXIF(zXIF) is look like such way for me.
> Of course if there will be future proposals about keeping data from EXIF
> (I will make at least one simple soon, I promise!)
>> The EXIF structure has hundreds of safe-to-copy fields, many of which
>> are highly significant; and two unsafe-to-copy fields (thumbnail and
>> preview image), both of which are redundant and therefore
>> informationally insignificant.
> There are more than two: thumbnail, gamma, orientation, subject
> location, custom processing...
> I'm not sure why  white point and chromaticities described as
> safe-to-copy (may be because they're marked as 'legacy' and don't
> supposed to rely on).
>> Any application that recognizes thumbnails and previews may (and
>> probably should) regenerate them at any time, as instructed by the
>> specification; or may even drop them, just as it may drop any other
>> EXIF fields not applicable to PNG (such as, for example, JPEG-only
>> fields).
> Modification of EXIF is not always as safe as it seems. E.g.
> modification may break 'Maker Note' as it may(or may not) depend on it's
> position in EXIF.
>> I believe that adoption for PNG in the area of digital photography
>> cannot happen if the important photographic information is preserved.
>> What exactly should make photographers switch from TIFF to PNG?
>> Deflate-compressed TIFF has been working just fine. Even uncompressed
>> TIFF (where compression is not important) is equally fine.
> That's why PNG should have better metadata. And it's impossible if we
> use same EXIF.
> With EXIF we may save no more than TIFF, so if compression doesn't
> matter there is no reason to use PNG when you are familiar with TIFF.
>
> --
> Pavel Zlatovratskii [email protected]; [email protected]
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> png-mng-misc mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/png-mng-misc

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc