RSS/Atom feed Twitter
Site is read-only, email is disabled

possible lanczos replacement

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.

possible lanczos replacement Nicolas Robidoux 21 Aug 16:15
  possible lanczos replacement Hal V. Engel 21 Aug 18:24
Nicolas Robidoux
2008-08-21 16:15:28 UTC (over 16 years ago)

possible lanczos replacement

Hello David:

I notice the 'Gamma' versions of these enlargers introduce haloing around some edges, while the non-gamma versions do not (or it's too little to see). A naive conversion may be the cause of this difference. If you could utilize the profile attached to the image, and generate or load a linear one, you could use LittleCMS to do the conversion in an assuredly correct way.

The main weaknesses of "our" methods are:

--haloing (but they have less haloing than Lanczos)

--aliasing (but IBFNBQH shows less, although still more than Lanczos, which is more blurry)

--memory usage (an temporary int16 "copy" of the input image has to be created)

Although I have hunches, I still do not understand perfectly how icc profiles affect enlargement artifacts. (This being said, a monotone method, like nearest neighbour, bilinear or non-interpolatory B-splines, should not be affected much by gamma obliviousness; bicubic, Lanczos, EANBQH and IBFNBQH are NOT monotone.)

This is something I'll have to experiment with.

Thank you for your comments,

Nicolas Robidoux

Hal V. Engel
2008-08-21 18:24:56 UTC (over 16 years ago)

possible lanczos replacement

On Thursday 21 August 2008 07:15:28 am Nicolas Robidoux wrote:

Hello David:

I notice the 'Gamma' versions of these enlargers introduce haloing around some edges, while the non-gamma versions do not (or it's too little to see). A naive conversion may be the cause of this difference. If you could utilize the profile attached to the image, and generate or load a linear one, you could use LittleCMS to do the conversion in an assuredly correct way.

The main weaknesses of "our" methods are:

--haloing (but they have less haloing than Lanczos)

--aliasing (but IBFNBQH shows less, although still more than Lanczos, which is more blurry)

--memory usage (an temporary int16 "copy" of the input image has to be created)

Although I have hunches, I still do not understand perfectly how icc profiles affect enlargement artifacts.

I think the main point is that if you are working with an image that has been color managed (IE. has an embedded profile) that the correctess of the conversions to and back from linear can be done in a provably correct way using library calls that are designed specifically for this. For many devices the actual gamma of each channel can be, and in many cases is, slightly different. For images from such a device which has a custom device profile embedded the profile will correctly reflect this channel to channel variation in gamma. Using a CMS like LCMS to do these conversions will handle these images correctly which would not be the case for any other approach.

(This being said, a monotone method, like nearest neighbour, bilinear or non-interpolatory B-splines, should not be affected much by gamma obliviousness; bicubic, Lanczos, EANBQH and IBFNBQH are NOT monotone.)

This is something I'll have to experiment with.

Thank you for your comments,

Nicolas Robidoux