Re: EXIF support in PNG

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