On Sun, Jun 16, 2013 at 10:52:57PM +0200, Sebastian Geerken wrote:
[...]
Nice! BTW, I have this page bookmarked for quite some time: http://www.4p8.com/eric.brasseur/gamma.html I don't know whether this makes a difference in real life, but the examples are interesting.
Interesting!
I didn't read the whole article, but it made me wonder what effect a gamma correction has on image scaling. See the test page <http://www.4p8.com/eric.brasseur/gamma_dalai_lama.html> with:
1. dillo 3.0.3, 2. current version from the hg repository, and 3. latter with the attached patch applied.
The patch uses floating point arithmetics; perhaps there is a faster algorithm based on integer arithmetics.
I don't know, but we could cache the values as in attached patch.
Yes, I also thought about this, and probably the fastest way is to calculate all values once, at the beginning, and later only access the array.
I've been working on the other side: from what I've understood, image data is in most cases already gamma-corrected. I'd like to extend ImgBuf by the gamma value, and the different parsers (GIF, JPEG, PNG) should extract the factor from the image.
So far, I'm working on JPEG, and came upon the field "output_gamma" in "struct jpeg_decompress_struct". Unfortunately, this value seems always 1. Can someone give me a hint?
http://www.cambridgeincolour.com/tutorials/gamma-correction.htm has some info on the topic. I think we can completely ignore gamma unless we actually touch the color values. I think the only place we do that is in the image scaling code. For the web I think it's safe to simply assume a gamma value of 2.2. To improve local image browsing we might check for embedded color profiles and use the gamma value provided there. That's how I understand it at least. Johannes