Re: CALL for DISCUSSION: eXIf 20170115

On Mon, Jan 23, 2017 at 9:34 AM, Willem van Schaik <[email protected]> wrote:
>
> So if we add both compressed and uncompressed into the spec, in all
> likelihood nobody will ever use it. But on the other hand, every decoder
> of PNG with EXIF will have to (!!) implement both options.

A decoder is permitted to implement or not implement support for
ancillary chunks as it requires.  An encoder typically only implements
one thing; this is why you found that encoders don't provide support
for zTXt.

The read side is the critical side, despite what Glenn keeps saying.
There's no point writing it if nothing reads it.  As I demonstrated
the read side of eXIf is already supported by libpng 1.2 and later (I
didn't check 1.0), but read of compressed versions is not supported.

The *Magick programs did not implement a private chunk, which would
have been reasonable, they implemented a private *keyword*.  Go
figure; there was a reason for doing such a weird thing and I'm
guessing that it is because the library code (libpng 1.2) does support
zTXt but does not support *compression* of private chunks.  So the
religion of "compress it whatever" triumphed over common sense.

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