Re: EXIF support in PNG
Glenn Randers-Pehrson <[email protected]>
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Message-ID | <CA+PdXcuyChPBZOkhWK1cfadbDb95BgAVJxMd8CKrx8UcWSiTWg@mail.gmail.com> |
On Mon, Jan 2, 2017 at 9:15 PM, Cosmin Truta <[email protected]> wrote: > even if we, non-optionally, mandate deflate > streams, the opportunity to store uncompressed EXIF binary data still > exists within these streams. > > Indeed. We did that with iCCP. I wonder how many such uncompressed iCCP chunks exist, using this method. Based on this, perhaps we should go ahead and do it the same as iCCP: only define a compression_method byte with only "zlib/deflate" being valid. Camera builders can do what you suggested, send deflate-encoded but uncompressed data. I think this would actually help with uptake of PNG+EXIF+iCCP, being friendly to both encoders (fast and simple) and decoders (no "uncompressed" variant except via deflate-encoding, which needs no special handling by the decoder). This "deflate-encoded uncompressed" data doesn't need to be mentioned in the spec but should probably appear in the "rationale" section, or perhaps in the middle of Section 5, Deflate/Inflate Compression (or Section 10.1 of the ISO version) 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