Hi! I've just push some changes for a better image scaling. See these two examples for the effect: - http://www.dillo.org/~sgeerken/grid.html - http://www.dillo.org/~sgeerken/tenniel.html I'm not completely sure about the side-effects. It should be slightly slower (see comment: it can be improved), and it will not work with other that RGB and RGBA data (for the case that Imgbuf is used for other representations). The old code is still there; just look at FltkImgbuf::scaleRow. Sebastian
On Fri, Jun 14, 2013 at 08:01:00PM +0200, Sebastian Geerken wrote:
Hi!
I've just push some changes for a better image scaling. See these two examples for the effect:
- http://www.dillo.org/~sgeerken/grid.html - http://www.dillo.org/~sgeerken/tenniel.html
I'm not completely sure about the side-effects. It should be slightly slower (see comment: it can be improved), and it will not work with other that RGB and RGBA data (for the case that Imgbuf is used for other representations). The old code is still there; just look at FltkImgbuf::scaleRow.
Nice! BTW, I have this page bookmarked for quite some time: http://www.4p8.com/eric.brasseur/gahttp://www.4p8.com/eric.brasseur/gamma.ht... I don't know whether this makes a difference in real life, but the examples are interesting. Johannes
On Sa, Jun 15, 2013, Johannes Hofmann wrote:
On Fri, Jun 14, 2013 at 08:01:00PM +0200, Sebastian Geerken wrote:
Hi!
I've just push some changes for a better image scaling. See these two examples for the effect:
- http://www.dillo.org/~sgeerken/grid.html - http://www.dillo.org/~sgeerken/tenniel.html
I'm not completely sure about the side-effects. It should be slightly slower (see comment: it can be improved), and it will not work with other that RGB and RGBA data (for the case that Imgbuf is used for other representations). The old code is still there; just look at FltkImgbuf::scaleRow.
Nice! BTW, I have this page bookmarked for quite some time: http://www.4p8.com/eric.brasseur/gahttp://www.4p8.com/eric.brasseur/gamma.ht... 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. Sebastian
On Sun, Jun 16, 2013 at 11:42:35AM +0200, Sebastian Geerken wrote:
On Sa, Jun 15, 2013, Johannes Hofmann wrote:
On Fri, Jun 14, 2013 at 08:01:00PM +0200, Sebastian Geerken wrote:
Hi!
I've just push some changes for a better image scaling. See these two examples for the effect:
- http://www.dillo.org/~sgeerken/grid.html - http://www.dillo.org/~sgeerken/tenniel.html
I'm not completely sure about the side-effects. It should be slightly slower (see comment: it can be improved), and it will not work with other that RGB and RGBA data (for the case that Imgbuf is used for other representations). The old code is still there; just look at FltkImgbuf::scaleRow.
Nice! BTW, I have this page bookmarked for quite some time: http://www.4p8.com/eric.brasseur/gahttp://www.4p8.com/eric.brasseur/gamma.ht... 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. Johannes
[...]
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? Sebastian
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
On Mo, Jun 17, 2013, Johannes Hofmann wrote:
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.
Thanks.
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.
I've just added gamma information to the whole chain (from image decoders to FltkImgBuf), without using it at all. Currently, all image decoders pass a value of 1/2.2, ignoring the possible values in the file. May be fixed. I found it useful just to have this value stored. I do not plan to correct any image values (assuming that the display has a gamma of 2.2), but just to use gamma for scaling. Sebastian
Hi! Gamma is now considered when scaling images, e. g. at <http://www.4p8.com/eric.brasseur/gamma_dalai_lama.html>, you will see Mr Tenzin Gyatso four times. There is an enumeration value at the begining of dw/fltkimgbuf.cc: if it turns out that there are performance problems on some platforms, the scaling mode may made configurable. Now back to more important tasks. :-) Sebastian
participants (3)
-
Johannes.Hofmann＠gmx.de -
johannes.hofmann＠gmx.de
-
sgeerken＠dillo.org