Re: EXIF support in PNG [was: Modern compressor]

On Sat, Dec 31, 2016 at 2:57 PM, Glenn Randers-Pehrson <[email protected]>
wrote:

> -rw-rw-r-- 1 glennrp glennrp 53679 Dec 31 17:45 51.exif
> -rw-rw-r-- 1 glennrp glennrp 27936 Dec 31 17:45 51.exif.gz
> -rw-rw-r-- 1 glennrp glennrp 31355 Dec 31 17:43 51.png.0005.zTXt
>
> I wouldn't give up compression.
>

Then you are going to throw the baby out with the bath water by specifying
a chunk that is not going to get used because of the simple fact that most
distros are stuck with a PNG decompressor which is not being enhanced; e.g.
Ubuntu which is stuck at libpng 1.2.

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.)

And, indeed, you have argued with me that I should not use iTXt in the test
PNG files distributed with recent (iTXt supporting) libpng releases because
iTXt isn't commonly supported!

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.

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 :

<chunk-length>: compressed length + 9
'comp': chunk tag (see below)
<original-length>: 4 bytes
'data': original chunk tag (see below)
<compression-method>: 1 byte, typically 0 for deflate
<compressed-chunk-data>
<crc32>

So, to compress eXIf:

<chunk-length>
"cOMp": the tag preserves the safe/etc bits
<uncompressed-length>
"eXIf":  so this exactly matches the original eXIf chunk header
<compression-method>
<compressed-EXIF-data>
<crc32>

A decoder that does not support 'comp' treats the data as unknown.

A decoder that does support 'comp' tells the application that it has an
'eXIf' chunk and, if it gets asked for it (e.g. by a call to
get_unknown_chunks) it decompresses the data on demand; it knows the buffer
size so it can do this efficiently.

This approach means that the whole, "Oh, we're PNG so we have to compress
everything, even if it means that it takes more than 10 years for a new
chunk to be supported" debate go away.  I mean, libpng 1.2?  All we have to
do is wait 10+ years for 'comp' support everywhere and people can start
using it, but *meanwhile* we can add chunks that use uncompressed data
without requiring decoders to support anything more significant than an
unknown chunk.

John Bowler

------------------------------------------------------------------------------
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