Re: EXIF support in PNG

On Mon, Jan 2, 2017 at 8:32 PM, Cosmin Truta <[email protected]> wrote:

> Willem van Schaik wrote:
> > no ... KISS   :-)
>
> The option to compress or not large volumes of data already exists,
> e.g., in tEXt vs. zTXt, uncompressed iTXt vs compressed iTXt.
>
> > and at least it should be the other way around: 0 for no compression and
> > 1 for zlib compressed
>
> We should use zero for deflate-compressed content, as it is the case
> everywhere else (in IHDR, in zTXT/iTXt, and in iCCP). Other numbers
> should be reserved for other compression methods.
>
> > but I don't like options, because good decoding software then needs to
> > support both, adding complexity
>
> That is correct in general, but EXIF decoding software is already very
> complex, and the complexity overhead incurred by extracting compressed
> or uncompressed EXIF data is minimal.
>
> But here's an idea:
>
> Why not enforce deflate *encoding*? (Here I emphasize on *encoding*
> not compression.)
>

That's not KISS, and people are going to get it wrong.


>
> Let us recall that deflate streams may be uncompressed, this being a
> simple matter of enclosing uncompressed blocks up to 64KB minus 1,
> each block prefixed with a 2-byte length code.
>

True, but putting a 1 in front ito signify uncompressed is an even simpler
matter.

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