Re: EXIF support in PNG

No one seems to like the idea of a keyword or handle in the eXIF chunk,
and I won't pursue it further, but I still like it because it gives you
something human-readable if you do an "od" or "xxd" on the file.

I'm strongly in favor of compression.  iCCP may have been a disaster, but
that's unrelated to the fact that the data is compressed.  One downside
of compression is the amount of in-camera CPU time needed, but
cameras could use a fast zlib compression level (such as 2-4) and a fast
PNG filter (SUB).  They could of course choose any set of compression
parameters they want, and users could apply third-party software like
pngcrush or optipng could recompress them better.

I've put up some test files, in www.simplesystems.org/users/glennrp/exIF

-rw-r--r-- 1 glennrp visitor 11849 Jan  2 16:53 nikon_exIF.png
-rw-r--r-- 1 glennrp visitor 25091 Jan  2 16:53 nikon_exIF_uncompressed.png
-rw-r--r-- 1 glennrp visitor 22516 Jan  2 16:54 sony_exIF.png
-rw-r--r-- 1 glennrp visitor 53776 Jan  2 16:54 sony_exIF_uncompressed.png

The uncompressed ones just contain a raw EXIF profile.  The
others contain a zero byte (compression type) followed by a
zopfli-compressed EXIF profile

The chunks are "exIF" but otherwise identical to what would be
in a registerd eXIF chunk.

Glenn


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

> Willem van Schaik wrote:
> > At this moment I think I'm aligning with John Bowler, therefore no
> > keyword, no compression. KISS
>
> I am in favor of KISS, too, and reject the idea of a keyword. No other
> image formats have it, and there is no need for one.
>
> I do not reject the idea of using compression, though. (So I would vote
> in favor of a proposal, regardless whether it has compression or not.)
>
> > Problem is of course what to do with that thumbnail that can be either
> > JPEG or two types of TIFF. For us a PNG thumbnail would of course make
> > most sense, but that will likely break a lot of standardization.
>
> In JPEG, the thumbnail can be JPEG or plain uncompressed pixel data. In
> PNG, the thumbnail may be JPEG also; I mean, why not?
>
> John Bowler wrote:
> > EXIF already has, internally, support for manufacturer specific
> > information (MakerNote).  It makes some sense to have a keyword
> > identification of ICCP profiles because they are *not* specific to
> > the image, it doesn't make sense for EXIF because it *is* specific
> > to the image.  There should be only one chunk but it should be
> > permitted before or after the IDAT (unlike ICCP).
>
> Agreed.
>
> > I don't like compression for the reasons I implied before; it means
> > that someone has to decompress it which means just reading it from
> > the unknown chunk list can't be done.  It also gets PNG
> > implementations like libpng into the business of validating the data;
> > at least I think that is how we ended up doing format checks on ICCP
> > data and look at what a disaster that is.
>
> 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.
>
> If it's uncompressed, but in an unknown chunk, the application may not
> know what's in there, regardless.
>
> libpng may or may not get in the business of validating EXIF data,
> regardless whether it's compressed or not; and that may or may not
> be a good thing to do. But concerning deflate compression, yes, libpng
> should validate the deflate stream (and that should be business as
> usual in the PNG world).
>
> > What I'm saying is that it is a *complete* black box except for some
> > reference to a spec that is not under our control.  If someone ends
> > up with a PNG with EXIF data which crashes an app (and this is
> > certain to happen) that is the problem of the app or the EXIF library
> > they use; nothing to do with any PNG file decoding implementation.
>
> I agree 100%.
>
> Glenn Randers-Pehrson wrote:
> > I wouldn't give up compression.  For the EXIF out of my
> > camera, an ImageMagick zTXt/EXIF chunk is half the size
> > of the uncompressed EXIF.  Because of the hex expansion
> > followed by zlib compression it doesn't do as well as zlib
> > by itself.
>
> I see John's point, and I see Glenn's point, and in the end I am weakly
> siding with Glenn.
>
> > I didn't intend for the keyword to be a camera identifier, I just
> > picked it as a n example of something I might write in the keyword
> > field, and it's probably what I would put in the keyword field, so
> > pngcheck would easily tell me about it.  It's just there for symmetry
> > with other PNG chunks; we know how to read a keyword (it's just text)
> > but we don't necessarily know how to read the blob that follows the
> > keyword.
>
> I still think that a keyword field is an unnecessary complication that
> is not done elsewhere. This comes on top of already many names (e.g.
> camera name, software name, author name, copyright holder name, etc.)
> It complicates both the spec, the user's decision making (i.e. what
> name to choose?), and worst of all, the implementor's decision making
> (i.e. what name to choose by default? should I let the user decide that?
> should I make a text box like this, or should I make a text box like
> that? should I have unit tests for it, or should I not bother because
> it's too esoteric and I have other more important things to do? etc...)
>
> The eXIf chunk name is good enough of an indication of what's inside.
>
> Willem van Schaik wrote:
> > if we think that the main purpose for a PNG EXIF chunk is to let
> > cameras compress raw images in a lossless fashion, then having a
> > lossy JPEG thumbnail in the EXIF chunk is not such a bad thing
>
> Agreed.
>
> > completely separately we could always request the CIPA folks to add
> > PNG as a fourth compression method for thumbnails in the EXIF
> > standard;
>
> I'd be happy to see this successfully proposed, voted in, and, most of
> all, getting industry adoption. Everything else would be cherry on top.
>
> John Bowler wrote:
> > Anyway, this is a matter for JEITA; they control the format, camera
> > manufacturers embed it in JPEG uncompressed.  If it was an issue for
> > them they would compress it.  Indeed, they have their own proposal
> > mechanism for enhancements; compression is effectively an EXIF
> > enhancement, PNG should not be doing it .  The only place this data
> > comes from so far as I can see is a camera (but that means it is
> > pretty common.)
>
> Perhaps JEITA was concerned with the actual content, not so much with
> details concerning its embedding. On top of that, JEITA did not have
> readily-available universal compression (like we, the PNG folks, have
> zlib).
>
> For example, WebP does specify an EXIF container, without any
> involvement from JEITA. But again, WebP have compression dedicated
> to pixels only, and EXIF compression would have been a significant
> complication for them. On the other hand, we have zlib, which is free
> for us to use here.
>
> > 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.
>
> > I have a better approach that doesn't force compression onto someone
> > else's data and can be handled independent of this chunk proposal.
> > It's simply a 'comp' chunk that consists of : [SNIP]
>
> That would impose ordering constraints with would really complicate the
> apps that do not recognize the chunks but decide to keep them, *not*
> *necessarily* in the original order.
>
> > 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. See, for example, Adobe
> Lightroom, you can change the colors all you want, but the colorimetry
> remains unchanged.
>
> 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.
>
> Yes, the thumbnail can get out of sync if the editing app doesn't know
> about EXIF, but you know what? We have survived JPEG-processing apps
> that updated the actual images while leaving the thumbnail intact and
> out of sync. The thumbnail can be reconstructed at any time. The rest of
> the EXIF data may be very very important, and once it's lost, it's lost.
>
> Then we (those who care about EXIF) go back to using TIFF because EXIF
> data is safe in a TIFF container, not so much in a PNG container.
>
> I can't stress enough how important I think it is to make eXIf safe to
> copy.
>
> Adam M. Costello wrote:
> > Just an idea:  Define eXIF and eXIf to have the exact same syntax, but
> > slightly different meaning: [SNIP]
>
> The past decisions were to make chunks like sRGB and iCCP unsafe-to-copy
> (correctly so), and tEXt/zTXt/iTXt safe-to-copy (also correctly so).
>
> This was a really good practice that we should keep on doing.
>
> Sincerely,
> Cosmin
>
> ------------------------------------------------------------
> ------------------
> 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