This project is read-only.

PNG Gamma chunk causing problems (incorrect colors)

Sep 10, 2009 at 2:35 AM


I just started looking into using the ImageTools package but ran into an issue where the images I save as PNGs seem to have the wrong colors/brightness. I was able to narrow down the cause to the Gamma chunk that is written into the PNG. If I comment out:

WriteChunk(PngChunkTypes.Gamma, fourByteData);

...the colors look correct when I open the image. I haven't had time to look at the specs to see what this chunk should contain, but removing it is a quick workaround.

As a separate issue, I can't get the saved images to open in Windows 7's Windows Photo Viewer (right-click/Preview) which might indicate that there is something else wrong with the resulting file. This happens with and without the Gamma chunk.

//Tomi B.


Sep 10, 2009 at 7:50 AM
Thanks for your comment.

I had a look at the code and it seems that this lines are absolutly
useless. So I will just remove it after having a closer look to the png

But I dont have a problem to open a saved png file in windows 7. Can you
tell me how you have saved the file and which image do you have used?
Sep 11, 2009 at 3:11 PM

Thanks. I'll need to follow up on the Photo Viewer issue after a reboot just to make sure it isn't something else that's going on.

//Tomi B.


Oct 6, 2009 at 1:48 AM

I ran into the same gamma issue as well. Problem with setting gamma in png file is the fact that we don't know actual gamma of the device used to generate the image. Also with some allpications ignoring gamma chunk while others respecting it we get inconsistent behaviour which is worse than not setting gamma at all.

You can see result of IE8 respecting gamma chunk here: Image looks all washed-out and pale.

Oct 6, 2009 at 8:28 AM
Edited Oct 6, 2009 at 8:51 AM

I dont understand what you want to say: Do you recommend just to ignore the gamme chunk?

But nevertheless I do not understand why this line of code makes some problems. When I look at wikipedia I see the following formula:

I_{\mathrm{out}} = {I_{\mathrm{in}}}^{\gamma}

And the png specification says:

The gAMA chunk contains:

Image gamma 4 bytes

The value is encoded as a four-byte PNG unsigned integer, representing gamma times 100000.

EXAMPLE A gamma of 1/2.2 would be stored as the integer 45455.

I just write the gamma value 100.000 ( = 1 ) to the gamme stream. It shouldnt change anything.

EDIT: I think I understand the problem: I gamma value of 1 just means that its output is linearly proportional to its input. But perhaps they add an offset which makes the image looks wahsed-out and pale. So the Idea is to make two property to the encoder, where you can specify, if gamma value should be stored or not and where you specify the gamma value if you need one. What do you say?

Oct 8, 2009 at 5:50 AM

IE8 crash ate my first long winded post, so this is second try.

I agree, gamma chunk shouldn't be set at all or gamma value should be provided by the user. Defaulting to gamma of 1 is a bad solution since it is very uncommon for an image to have linear gamma. If the default value needs to be provided for some reason it is best to go with 2.2 (default gamma in Windows and sRGB) or 1.8 (Mac standard gamma).


Oct 8, 2009 at 9:27 AM

Good to know, that the default gamme value in windows is 2.2, didnt know it.

I will change this behaviour this weekend.

Dec 5, 2009 at 1:40 AM

Nice write up on the issue of PNG gamma: