- Dillo-dev - lists.mailman3.com

Image Scaling

by sgeerken＠dillo.org

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

June 17, 2013

Image Scaling

by johannes.hofmann＠gmx.de

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

June 17, 2013

Image Scaling

by sgeerken＠dillo.org

[...] > > > 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

June 16, 2013

Image Scaling

by Johannes.Hofmann＠gmx.de

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.h… > > 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

June 16, 2013

Image Scaling

by sgeerken＠dillo.org

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.h… > 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

June 16, 2013

Image Scaling

by Johannes.Hofmann＠gmx.de

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.h… I don't know whether this makes a difference in real life, but the examples are interesting. Johannes

June 15, 2013

do not truncate long filenames beginning with dot

by sgeerken＠dillo.org

On Sa, Jun 15, 2013, Dennis New wrote: > On Tue, 11 Jun 2013 23:26:21 -0400, Jorge Arellano Cid wrote: > > On Tue, Jun 11, 2013 at 09:23:29PM +0200, Johannes Hofmann wrote: > > > On Mon, Jun 10, 2013 at 07:15:45PM -0400, Jorge Arellano Cid wrote: > > > > On Mon, Jun 10, 2013 at 10:41:23PM +0200, Johannes Hofmann wrote: > > > > > On Wed, May 29, 2013 at 04:50:21AM -0400, Dennis New wrote: > > > > > > Sometimes, when trying to save a document with long > > > > > > filenames, the truncated default save-as filename will start > > > > > > with a dot. (Ie. a hidden file.) This behaviour should > > > > > > change. Perhaps truncate the end of the filename instead (and > > > > > > preserve the file extension)? > > > > > > > > > > Do you have an example where this happens? I see that it can > > > > > happen with URLs like http://dillo.org/bla/.blub > > > > > Is this the case where you are seeing the issue or do you get it > > > > > with other types of URLs as well? > > > > > > > > I was to ask the same question days ago (yes I reviewed the > > > > code to make a quick patch and it cuts starting from the end). An > > > > example would be clarifying. > > > > > > If we don't get any more feedback, I'd just replace dots with > > > underscores as well. What do you think? > > > > That was one of the first things I considered, but thought that > > when saving a ".config" file it was good to keep the name. I'd like > > to know the real problem the user had. > > The problem is with very long filenames, such as: > > http://dennisn.dyndns.org/guest/pubstuff/dillo.long.file.name-0.69_r1337.fi… > > Dillo seems to truncate with just the last 64 chars. So, in this > example, the save-as filename would be saved as a hidden file > ".file.name-....txt". > > Perhaps a better solution would be to truncate the *middle* of the > filename, thus preserving the beginning and file extension? The attached patch does this, and inserts an ellipsis to indicate that something was replaced. The above URL becomes dillo.long.file.name-0.69_r133...789012345678901234567890123.txt which is 64 characters long. I like this approach, because both the beginning and the end are the most characteristic parts of a filename. Sebastian

June 15, 2013

do not truncate long filenames beginning with dot

by dennisn＠dennisn.dyndns.org

On Tue, 11 Jun 2013 23:26:21 -0400, Jorge Arellano Cid wrote: > On Tue, Jun 11, 2013 at 09:23:29PM +0200, Johannes Hofmann wrote: > > On Mon, Jun 10, 2013 at 07:15:45PM -0400, Jorge Arellano Cid wrote: > > > On Mon, Jun 10, 2013 at 10:41:23PM +0200, Johannes Hofmann wrote: > > > > On Wed, May 29, 2013 at 04:50:21AM -0400, Dennis New wrote: > > > > > Sometimes, when trying to save a document with long > > > > > filenames, the truncated default save-as filename will start > > > > > with a dot. (Ie. a hidden file.) This behaviour should > > > > > change. Perhaps truncate the end of the filename instead (and > > > > > preserve the file extension)? > > > > > > > > Do you have an example where this happens? I see that it can > > > > happen with URLs like http://dillo.org/bla/.blub > > > > Is this the case where you are seeing the issue or do you get it > > > > with other types of URLs as well? > > > > > > I was to ask the same question days ago (yes I reviewed the > > > code to make a quick patch and it cuts starting from the end). An > > > example would be clarifying. > > > > If we don't get any more feedback, I'd just replace dots with > > underscores as well. What do you think? > > That was one of the first things I considered, but thought that > when saving a ".config" file it was good to keep the name. I'd like > to know the real problem the user had. The problem is with very long filenames, such as: http://dennisn.dyndns.org/guest/pubstuff/dillo.long.file.name-0.69_r1337.fi… Dillo seems to truncate with just the last 64 chars. So, in this example, the save-as filename would be saved as a hidden file ".file.name-....txt". Perhaps a better solution would be to truncate the *middle* of the filename, thus preserving the beginning and file extension?

June 15, 2013

Image Scaling

by sgeerken＠dillo.org

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

June 14, 2013

shortcuts to open links in new tab and new window

by dennisn＠dennisn.dyndns.org

Currently it seems like you can only have it one way, via the "middle_click_opens_new_tab" dillorc option. (And to do it the other way, you have to right click and navigate the menus. A lengthy process :). I think it would be quite useful if both were available via a shortcut... perhaps have this option toggle the meaning of ShiftMiddleClick and MiddleClick... whereby one will open the link in a new window, and the other in a new tab?

June 14, 2013