Re: EXIF support in PNG

Cosmin Truta <[email protected]>
Newsgroups gmane.comp.graphics.png.general
Message-ID <CAAoVtZxZ4Fwd2Qr+Wu1F-OPG67+o1x7BZ5A-TLVjC9p_5fGk=g@mail.gmail.com>
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.)

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.

Sincerely,
Cosmin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
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.