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