Someone kindly pointed out that the subject line of my last email made it likely to be caught by a filter.

In case you missed it:

http://web.cs.laurentian.ca/robidoux/misc/

contains the tarred and gzipped folder gimptests.tgz which contains code for four suggested plug-ins which implement possible replacements for Lanczos.

The README file gives details.

-----

Of the four, IBFNBQH (a brand new method analogous to global cubic splines, but with a slightly different variational principle and boundary conditions) is the most likely candidate to replace Lanczos.

If you look at the kingfisher enlargements, you will notice that Lanczos, as currently implemented in the Gimp, produces artifacts in the top row. None of the plug-ins have such artifacts. Actually, they have been tested inside and out, qualitatively and quantitatively, on a variety of images, and are almost certainly free of "bugs."

Because the top row is cropped out of the enlargement of the other image, this artifact is not visible.

In addition, although this is of course a matter of taste, I prefer the "crispness" of IBFNBQH (and EANBQH) to the slight blurriness of Lanczos.

------

At this point, the plug-ins only enlarge.

I imagine that in order for, say, IBFNBQH to replace Lanczos, it would have to be fixed so it can resize to arbitrary dimensions. I should be able to do this in a reasonable amount of time.

David Gowers has suggested using LittleCMS (or GeGL) to linearize colour profiles during the computation. In our experience, our plug-ins produce good results when used in a "gamma OBLIVIOUS way." This being said, back of the envelope computations suggest that "light" haloing is likely to decrease if the colour profile is properly taken into account (because sRGB has a linear component near black, "dark" haloing is probably not going to change much for such images; again, this is from a very rough back of the envelope reasoning). Given that GeGL will perform all the heavy lifting for the Gimp in the future, I am not sure that fixing the gamma correction at this point is really something I want to do. However, I will try to integrate profile information in the profile if it is felt that it is important.

The current "gamma" versions of the plug-ins use "naive" gamma correction (and do not take into account the linear piece of sRGB). David's plan is a much better one.

Let me know what you think.

Nicolas Robidoux Laurentian University/Universite Laurentienne nrobidoux@cs.laurentian.ca

Hello Sven and Oyvind:

Have you already added the plug-ins to the GIMP plug-in registry?

I will when I have rewritten the code to my satisfaction. The current versions are perfectly useable (and bug free), but I'd rather release the final versions right of the bat.

At this point we are concentrating on porting more and more of the GIMP core to GEGL.

It is unlikely that I will port EANBQH and IBFNBQH to GEGL, because programming them so that they can be used analogously to bilinear, bicubic and lanczos is a substancial programming project.

I have looked around the GEGL code, and it is very likely that I will program a novel "co-convex resampling scheme" following the lanczos model found there. This will take a while.

One good thing about the co-convex scheme is that the results are not overly affected by what I understand is the current GEGL "abyss" policy (set pixel values outside of the physical extent of the image to 0): only if the sampling point is outside of the rectangle defined by the boundary pixels will the value be negatively affected.

Quick comment:

If the default GEGL abyss policy was "smear," this would have the following general consequence:

Any linear method/filter (blur, resampling...) which is exact on constant intensity data will still be exact on constant intensity data without special handling within the filter. This does not mean that the results are the same as if the filter carefully handles the boundary, just that the dirty hack of using "ghost values" and then implementing the filter in a boundary independent way will not give absurd results.

This has two consequences:

Implementing filters can be done in two passes: first, ignore boundary issues; build in boundary handling into the filter, using the x, y, width and height information to determine the position relative to the boundary and perform appropriate branching.

If speed/more compact code is desired, ignore boundary branching, confident that the results are still reasonable.

This being said, changing to "smear" will not make the results with the co-monotone method any different, which is why I don't particularly care. The co-monotone method is not linear.

I suspect that for some filters it is impossible to define an abyss policy which is equivalent to careful handling of the boundary within the filter. The ImageMagick trick of masking and normalizing the coefficients is another way of getting reasonable results (and preserving the "exact on constants" property), but again it only approximates careful boundary handling for most schemes. If I was to choose, I'd rather (approximately) fix things with a smear abyss policy (even though, in the particular case of my next pet scheme, it makes no difference).

Thank you all for your comments,

Nicolas Robidoux Laurentian University/Universite Laurentienne