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

just to let you all know that I will vote against a COMP chunk

for me it is adding complexity for very little gain

sorry,
Willem


On 2017-01-01 12:01, John Bowler wrote:
> On Sun, Jan 1, 2017 at 10:49 AM, Glenn Randers-Pehrson
> <[email protected] <mailto:[email protected]>> wrote:
>
>         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.
>
>
> I'm still proposing something that doesn't *require* any support in the
> application, only the decoder and encoder.
>
>
>     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.
>
>
> Well, yes; I was talking about adding keywords.  I'm certainly
> interested in the possibility of allowing different compression methods
> (e.g. RLE) though it would slow down adoption.
>
> The chunk I'm talking about is just a piece of math that transparently
> results in a smaller PNG from the application point of view.  It's a
> completely reversible lossless transform that *can* be implemented
> invisibly within the current specification.  It it carries extra
> information there will be bug reports from someone, somewhere that the
> information is lost by some application and then the chunk ceases to be
> transparent.
>
> Or, to put it another way, when (20 years time?) all PNG *decoders*
> support cOMp/cOMP/COMP/COMp I can find quite a few PNGs and, completely,
> totally, losslessly make them smaller, and no app will know unless it asks.
>
> John Bowler
>
>
> ------------------------------------------------------------------------------
> 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
>


-- 

Willem van Schaik
<[email protected]>
http://www.schaik.com/


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