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
> 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
> Gimp-developer mailing list
Gimp-developer mailing list