Re: EXIF support in PNG

On 2 January 2017 at 22:27, John Bowler wrote:
> Ok, three function calls.  I think I understand what you are referring to
> but I don't think it works, however given the assertion and that you are a
> zlib expert, precisely what three function calls (given Glenn's spec,
> without the keyword)?

Me, zlib expert, pfft. But thanks. [Blush]

It's deflateInit(), then deflate(), then deflateEnd(). You'd normally
put deflate() in a loop, but in this particular context, you need not
do such thing. And, ok, you have some extra initialization, which you
can move into a separate easy-to-use initialization routine
altogether.

But this is the wrong focus on the wrong counting.

To me, anything that's better than hex-encoding the EXIF blob and
putting it into zTXt is altogether a better solution. I'm thinking
here about the user who doesn't care in the slightest about
implementation: one old clunky and supposedly bad in other
inconsequential ways (I mean EXIF-in-zTXt) gets compared to the new,
shiny and well-designed eXIf chunk; and look, how much *smaller* is
the *old* file! What extra useless stuff could have they put in the
new one!

In other image formats, there are understandable complexity challenges
in compressing ICCP, EXIF or XMP data, because that would require
separate algorithms; but not in PNG, where deflate compression (be it
via the zlib reference library or anything else that's
RFC1950-compliant) comes free. This applies both to software and
hardware -- there is no need for extra silicon to be spent in
dedicated circuitry, either.

Sincerely,
Cosmin

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