Re: pngcrush and optipng notes

On 04/20/2008 04:38 AM, Glenn Randers-Pehrson wrote:

> I looked at four example PNGs that Matthias sent me.  In all 4 cases, the
> filesize increase was due to pngcrush adding a gAMA chunk (the originals
> contain an sRGB chunk but no gAMA).
>
> It is probably a mistake for pngcrush to be adding gAMA without the user
> explicitly asking for it.


I'm not so sure about that.

The semantics are clear:

1) A sRGB chunk, if present and recognized, overrides any gAMA chunk.
  http://www.w3.org/TR/PNG/
so the gAMA chunk doesn't do any harm in the normal case (except for
the extra 8 bytes of size).

2) Therefore the interesting case is where the sRGB chunk is present
but not recognized by the decoder.  To cover this case:

   "It is recommended that a PNG encoder that writes the sRGB chunk
    also write a gAMA chunk (and optionally a cHRM chunk)
    for compatibility with decoders that do not use the sRGB chunk."
      http://www.w3.org/TR/PNG/

Tangential remark:  This compatibility will necessarily be imperfect,
because the sRGB transfer function is not well described by power law,
i.e. not well described by any single value of "gamma".

==================================

Bottom line:  It seems that the observed pngcrush behavior is in strict
compliance with recommendations of the PNG spec.

You could perhaps make an argument for deviating from the recommendations
in some cases, but it would be a nontrivial argument, weighing the pros
and cons.


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement