Re: CALL for DISCUSSION: eXIf 20170115

Glenn Randers-Pehrson <[email protected]>
Newsgroups gmane.comp.graphics.png.general
Message-ID <CA+PdXct_iPCAiSqWoY32ET+aAhqxrk2tCMRpy-0mCus_=Khu_A@mail.gmail.com>
I'd slightly revise the "comp" chunk proposal slightly so that
the keyword or other prefix would be copied rather than compressed,
so that they are still readable in "xxd" or "od" dumps and such.

On Sat, Jan 28, 2017 at 6:06 PM, John Bowler <
[email protected]> wrote:

> On Sat, Jan 28, 2017 at 4:51 AM, Glenn Randers-Pehrson
> <[email protected]> wrote:
> > Back to the drawing board for zxIf.  It needs an "uncompressed length"
> byte
> > at the beginning.
>
> Well, it's off topic, but that's why I was suggesting "cOMp":
>
> <chunk-length>: compressed length + 9
> 'comp': chunk tag (case matches case of the embedded chunk)
> <compression-method>: 1 byte, typically 0 for deflate
>

    <prefix-length> 1 byte, 0 if no prefix, not more than 80


> <original-length>: 4 bytes (original-length includes any prefix)
> 'data': original chunk tag (see below)
>

 ==>   <original prefix> (includes its NULL terminator)


> <compressed-chunk-data>


 ==>    (does not include prefix or its NULL)

<crc32>
>
> Regardless of debates about where the compression byte goes it is
> possible to write a simple, streaming, filter for this which simply
> copies a PNG from input to output except for replacing every cOMp
> chunk, as above, with:
>
> <original-length>: 4 bytes
> 'data': original chunk tag (see below)
>

 ==>  <original prefix>


> <original-chunk-data>
>

 ==> does not include prefix or its NULL


> <generated-crc32>
>
> There is no non-trivial buffering requirement.  Neither is there a
> buffering requirement to handle cOMp transparently above a library
> like libpng; the read callback identifies 'cOMp' and returns the
> original header to libpng then when asked for the data it runs a zlib
> inflate engine; libpng actually provides the output buffer!
>

In effect, the decoder copies the original prefix, then decompresses
the rest of the data.  For chunks that don't have a prefix, the only
difference from John's proposal is the presence of a prefix-length byte
containing a zero.

Glenn

------------------------------------------------------------------------------
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.