EXIF support in PNG [was: Modern compressor]

Cosmin Truta wrote:
>> In theory, PNG can hold any metadata. In practice, there have been two
>> or three attempts by our group to incorporate EXIF into PNG, back in
>> early 2000's, all of which failed.

John Bowler wrote:
> Ok.  In JPEG it's a binary blob contained in an APP marker.  There's lots of
> code out there to decode the blob simply because, while it is binary, the
> format is always well defined.

True. This was one of the original proposals. It fell down even before
voting stage, one of the objections being that, in PNG, only network
byte order EXIF should be allowed. (Bad idea, in my opinion. JPEG
imposes no such constraint on the embedded EXIF.)

> It's nominally safe-to-copy; there is some information in there (such as the
> modification date) which some might argue isn't, but that is really moot
> because 'modification' in the Exif context means a real change to the image,
> not the kind of encoding change that things like pngcrush or OptiPNG do.

Also true. One may argue that editing an image would leave the
embedded thumbnail out of sync, but there are many reasons for (and
few reasons against) making an EXIF chunk safe-to-copy.

> So it's eXIf; just a blob, forget the compression complexity.  Unofficially
> it would be exIf with, just, the blob as the data.

Sounds plain and simple. If anybody ever asks why hasn't it been done
this way from day one, my answer would be "no idea".

In an old, unreleased version of OptiPNG, I did produce an "exIf"
exactly like this, BTW.

Can we still standardize eXIf? Do we still have enough people eager to
discuss it and vote it? Does the big world outside of our little group
still care?

Sincerely,
Cosmin

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