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

in a time where people are downloading GB's of video data from YouTube, 
it is my opinion that squeezing the last couple of bytes (even kB's) out 
of an image file is irrelevant

if we allow applications to create compressed chunks that were 
originally meant not to be compressed, then we create a huge adoption 
problem

when an application (reading PNG's) is not updated to support COMP and 
then tries to open an image file that was created by a writing 
application that did use COMP, then you can debate which of the three is 
broken (writing app, reading app, the PNG file itself), but at least one 
of the three is and the user will be pissed off

for the EXIF chunk, I'm in line with Jon's original proposal, no 
compression needed, the chunk is just a black box; but in this case I 
have a strong preference to keep things simple, but I wouldn't vote against

Willem



On 2017-01-01 12:36, Glenn Randers-Pehrson wrote:
> Willem, would you allow a compression byte on the eXIf chunk, then?
>
> Glenn
>
> On Sun, Jan 1, 2017 at 2:35 PM, Glenn Randers-Pehrson <[email protected]
> <mailto:[email protected]>> wrote:
>
>     Not COMp -- according to the PNG spec, "the safe-to-copy bit will
>     always be 0 for critical chunks".
>
>     Glenn
>
>     On Sun, Jan 1, 2017 at 2:07 PM, John Bowler
>     <[email protected]
>     <mailto:[email protected]>> wrote:
>
>         On Sun, Jan 1, 2017 at 11:00 AM, Soni L. <[email protected]
>         <mailto:[email protected]>> wrote:
>
>>
>             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.
>
>
>         I'm suggesting a set of four chunks; cOMp, cOMP, COMp and COMP,
>         but I've just realized that PLTE cannot be compressed without
>         violating the specification because that would result in a file
>         that cannot be read by a fully conformant ISO-PNG decoder, so it
>         wouldn't be a PNG.
>
>         PLTE on color type != 3 (not palette) cannot even be compressed
>         using cOMP because the potential result is a PNG that contains
>         multiple PLTE chunks.
>
>         Hum, this requires a little thought; I'm not sure unknown chunks
>         can be compressed this way.
>
>         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]
>         <mailto:[email protected]>
>         https://lists.sourceforge.net/lists/listinfo/png-mng-misc
>         <https://lists.sourceforge.net/lists/listinfo/png-mng-misc>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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