Re: EXIF support in PNG
Cosmin Truta <[email protected]>
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Message-ID | <CAAoVtZyR7vNka2ki3af_tsxA5k2DVHNNcBUddk1ponBJ4XN5gA@mail.gmail.com> |
On 2 January 2017 at 20:38, Glenn Randers-Pehrson wrote: > On Mon, Jan 2, 2017 at 8:32 PM, Cosmin Truta wrote: >> 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. It is KISS to enforce deflate streams. If somebody expertly decides to use uncompressed deflate streams, they have that choice, which would be outside of the normative scope of the EXIF proposal. >> 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. Using a boolean to signify raw EXIF vs. deflate-encoded EXIF would be KISS for encoders. Enforcing deflate-encoded EXIF would be KISS for decoders. I am not implying that I would absolutely want this. I am just presenting it as a choice: even if we, non-optionally, mandate deflate streams, the opportunity to store uncompressed EXIF binary data still exists within these streams. Sincerely, Cosmin ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot