Re: [png-mng-implement] libpng-1.6.6 vs 1.5.17 size

[John B. <joh...@gm...>]

On Sat, Sep 28, 2013 at 12:08 PM, Glenn Randers-Pehrson
<gl...@gm...>wrote:

> Anyhow the bug I mentioned does not have to do with "known incorrect"
> sRGB profiles.  It's observed with good sRGB profiles (e.g., argyll)
> and with the sRGB chunk, but not with a gAMA 0.45455 chunk or
> with no colorspace chunk at all.  I concluded that this means mozilla
> displays HTML backgrounds with gamma=1/2.2, not precisely sRGB.
>

It sounds like the bug in question is inside the firefox color space
handling.  The simplified API *does* process a known sRGB PNG differently,
but that's because there is special code written into the simplified API
implementation to get it right.  If the simplified API is compiled out then
the relevant sRGB<->linear tables and associated macros don't appear in the
code at all.

Even if firefox *is* using the simplified API (that would certainly explain
the increase in size of pngread.o) there is still only a difference if
firefox asks *libpng* to do gamma correction, but why on earth would it do
that, as it has full color management built in?

So unless firefox is doing something weird changes to output colors must be
a result of color handling inside firefox.

One possibility is that firefox has changed the sRGB profile it uses.  With
1.5 code an iCCP chunk will not be automatically recognized as sRGB, with
1.6 a matching (or broken) chunk *is* recognized and png_get_sRGB will
start to return true.

John Bowler