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