Re: EXIF support in PNG

There are two separate things in here, one is about the compression-or-not
issue, which I feel strongly about, the other is safe-to-copy which works
either way for me for reasons I will explain below.

On Mon, Jan 2, 2017 at 11:19 AM, Cosmin Truta <[email protected]> wrote:

> This objection is interesting, but in the end, I don't see it as a big
> problem. A PNG-processing application should be able to expand
> deflate-compressed raw data with little effort.
>

Well, I am a very experienced zlib programmer and you are certainly a zlib
expert far more experienced that I.  I think zlib has a very fine
interface, but:

Me:
> > What I'm suggesting instantly adds EXIF support to any existing PNG
> > implementation that supports returning the data of an unknown chunk
> > to the application.  Instant, now, not 10 years or more in the future.
>
> Good point. But is there a big difference, from recognizing the eXIf
> chunk and extracting the data, to recognizing the eXIf chunk, extract
> the compressed data, then decompress it? It's three more function calls
> to the zlib decompressor.
>

Ok, three function calls.  I think I understand what you are referring to
but I don't think it works, however given the assertion and that you are a
zlib expert, precisely what three function calls (given Glenn's spec,
without the keyword)?

Ok: other point:


>
> > The chunk needs to be unsafe-to-copy; it contains color space
> > information so it behaves in a way similar to iCCP.  Here's a
> > modified proposal:
>
> This is what I strongly disagree.
>
> The camera parameters (including the sensor's color parameters) are
> unchanged, even if the user edits the photo.


That is correct, the camera information does not relate to the image in the
JPEG (it might to the RAW image, but even that isn't certain).


> Even more importantly, however, we should want the EXIF info to travel
> as far as possible, and not get lost in the first application that
> doesn't know what's inside.
>

True, and I agree.  My original proposal using unsafe-to-copy was because
of that and it is a powerful argument.

>
> I can't stress enough how important I think it is to make eXIf safe to
> copy.
>

Ok.  I think I agree, but for the record I think I need to explain my
reason for safe-to-copy:

>
> The past decisions were to make chunks like sRGB and iCCP unsafe-to-copy
> (correctly so),


You have to know both sides of the equation to work out the reverse
transform from the image data to the original camera data.  If you can't
get back to the original data the only way of editing the image is to do it
by eye, effectively using our brains (which, true, are the source of all
this data) to undo the transformations necessary to render the image on an
image editing station.

Modifying the PNG image data makes the previous colorspace information
invalid, it is necessary to record the new information, however the only
way of doing this is with sRGB or iCCP.

An application *can* work this out so long as something is recorded; if
there is a gAMA or cHRM in there then the app can't map back to the
original; there isn't enough information in those chunks.  If sRGB or iCCP
are there, fine.  So if the app does the right thing a second app can too.
If the app records nothing the second app can only assume that the EXIF is
correct, well; that's also fine.  We're back to eyeballs and brains and,
realistically, they are the original implementation and they are orders of
magnitude more reliable than any of this other stuff.

So eXIf.

-- 
John Bowler <[email protected]>
+1 (541) 450-9885 <(541)%20450-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

_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc