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