Image Scaling

Post by Sebastian Geerken
Hi!
I've just push some changes for a better image scaling. See these two
- 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.htmlmma.html
I don't know whether this makes a difference in real life, but the
examples are interesting.

Johannes

Sebastian Geerken

2013-06-16 09:42:35 UTC

http://www.4p8.com/eric.brasseur/gahttp://www.4p8.com/eric.brasseur/gamma.htmlmma.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.

Sebastian

Johannes Hofmann

2013-06-16 20:29:02 UTC

http://www.4p8.com/eric.brasseur/gahttp://www.4p8.com/eric.brasseur/gamma.htmlmma.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
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

Sebastian Geerken

2013-06-16 20:52:57 UTC

[...]

Post by Johannes Hofmann
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.

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

Johannes Hofmann

2013-06-17 08:02:13 UTC

Post by Sebastian Geerken
[...]

Post by Johannes Hofmann
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.

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

Sebastian Geerken

2013-06-17 09:30:28 UTC

Post by Sebastian Geerken
[...]

Post by Johannes Hofmann
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.

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.

Post by Johannes Hofmann
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

Sebastian Geerken

2013-06-17 10:42:23 UTC