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
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.