Re: CALL for DISCUSSION: cOMp/cOMP/coMp/coMP: compression wrapper chunks

On 29 January 2017 at 15:41, Willem van Schaik <[email protected]> wrote:
> I really think this should be called the COMPlexity chunk :)
>
> really, who is waiting for this ??
>
> yes John, another zTXt ...

Absolutely not. (I realize that an "absolutely not" vote should still
count as "no", but there we go.)

I understand Willem's opposition to compression (I mean, I still
respectfully disagree, although, at least, I understand.) But
this?!...

Let me clarify my voting criteria:

I generally vote "yes" for anything that I consider to be beneficial
for the technical advancement of the PNG specification. I vote
"abstain" if I have nothing to win or lose (but realize that other
people might), and I vote "no" if a proposal would actually hurt the
format and its implementations.

Therefore, "absolutely not" means I absolutely do not agree with the
idea of breaking virtually all existing applications processing
metadata, just because this COMP thing suddenly appears around
ancillary chunks that so far applications were fine processing it, and
from now on, they won't be. (And, no, simply adding some arbitrary
list of privileged chunks isn't going to make much difference.)

If you want an int and a float in a FooBar structure, make a fOOB
chunk with an int and a float. If you want a float and a
zero-terminated string in a BarBaz structure, make a bARB chunk. And
if you want a zero-terminated string, a boolean and a deflate stream
for a BazQux, then make it so, into bAZQ.

I mean, if you want to use deflate streams, use them; and if not,
don't. iCCP is a perfect example.

But now, suddenly, according to my understanding of COMP, *every*
*single* *decoder* that recognizes metadata (other than some specific
list) must be updated, or else there is a risk of breakage. And in the
future, no more simplicity for you: *every* *single* *decoder* wanting
to process BarBaz, or what have you, will have to recognize bARB and
"that other chunk".

Look, I still want my EXIF-in-PNG, but not at this expense. So I will
still vote "yes", regardless whether compression is allowed or not,
for the EXIF proposal. But if getting that in the spec will mean
piggybacking this in also, then I'll rather prefer to continue using
deflate-compressed TIFFs, thank you very much.

Sincerely,
Cosmin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot