Re: CALL for DISCUSSION: eXIf 20170115

Well, I made this proposal on Dec 31, 2016 and so far the only
substantive change to the proposal has been removal of the JPEG ID tag
from the head of this data.  One person was for that change, one
person against it and one person (me) said "it doesn't matter."

Meanwhile the whole debate has been clouded by rapid fire
modifications and suggestions that seem designed to defeat any chance
of actually adopting anything.  To top it all we now have a proposal
about how we decide on proposals.

Cosmin started off by saying that he regards EXIF metadata as
"precious", but apparently not so precious that compression isn't much
more important.  Glenn wants keywords and compression and everything.
Neither can come up with the code to do it.

I actually have that code and it is already checked in to recent
versions of libpng.   Glenn claims Mark Adler's "examples/zpipe.c"
fits the job.  It doesn't, so I can only conclude that Glenn hasn't
actually implemented anything.

The issue with zpipe, on both the compress and decompress side, is
that it *writes* the output to a *stream*.  This doesn't work because
on both read and write the length has to be known *before* the
operation starts.  The result of changing it to make this happen is
more than 50 lines.

png_inflate is here, at line 219:

https://github.com/glennrp/libpng/blob/libpng12/pngrutil.c

As Glenn observes, using it is not possible because of copyright
issues, however it runs to 94 lines and yet it *STILL* doesn't solve
the problem; it is pretty much "inf" reformatted to Glenn's coding
style.  The actual solution is the libpng function
png_decompress_chunk, which is at line 323 to 427 (another 104 lines)
and calls png_inflate.

"Git blame" assigns those two functions to Glenn, from a commit on
2010-02-12, however they are a back-port from libpng 1.4 and Glenn's
first implementation is here:

>commit 877b08d6d2ac394dfc69afa3876eb0773a5b117d
>Author: Glenn Randers-Pehrson <glennrp at users.sourceforge.net>
>Date:   Thu Jan 28 07:16:15 2010 -0600
>
>    [master] Implement two-pass png_decompress_chunk() function
>    suggested by John Bowler.  Does not waste memory, does only one malloc()
>    to the measured decompressed size.

This code comes out of a couple of serious security issues raised by
the previous implementation and THIS is why I say that pushing the
implementation of this code into the application is a bad idea.

John Bowler

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