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

On 01/01/17 04:49 PM, Glenn Randers-Pehrson wrote:
>
>
> On Sun, Jan 1, 2017 at 1:33 PM, John Bowler 
> <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     On Sun, Jan 1, 2017 at 10:19 AM, Glenn Randers-Pehrson
>     <[email protected] <mailto:[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
>

Why not make it COMP and require everything to verify the inner chunk? 
That way COMP could be added to chunks like PLTE and stuff.

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