Re: cOMp chunk [was: EXIF support in PNG]

On Sun, Jan 1, 2017 at 1:33 PM, John Bowler <
[email protected]> wrote:

> On Sun, Jan 1, 2017 at 10:19 AM, Glenn Randers-Pehrson <[email protected]>
> wrote:
>
>> Of course, consistency would also suggest having a keyword, which I
>> happen to like.  Simple
>> handles can be useful.
>>
>
> What I'm proposing is a set of chunks which the application never sees; if
> I ask the encoder will write an sPLT as cOMP/sPLT but I never seer that; I
> give the encoder an sPLT.  When an app reads this using a decoder which
> supports cOMP the decoder reports an sPLT, not a cOMP.
>

You cannot count on applications not seeing the chunk.
You can, however, count on the fact that some applications won't recognize
it, and will report cOMP but not the embedded sPLT.

If the compressed chunk had a keyword before compression it has one after
> compression.  Any extra data on the wrapper cOMP chunk is spurious noise.
>

I'm talking about a cOMP chunk that contains a chunk that doesn't have its
own compression, either because the chunk
spec doesn't allow it or because the author chose not to compress it.  The
cOMP chunk should contain a compression_method byte in order to
future-proof the chunk against improved compression methods that might come
along, just as IHDR, zTXt, etc. do.

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