Hello gegl developers:

I am just about ready to put in a bugzilla with the next iteration of the YAFR resamplers (the alternatives to nearest neighbour, bilinear, bucibic and lanczos).

The current gegl-yafr (which I'll call yafr-smooth from now on, the name used within the image processing package vips/nip2), is basically Catmull-Rom + an edge straightening/sharpening correction. Like Catmull-Rom, it often introduces a fair amount of halo (more so with "text like" images than uncompressed photographs in which all features are well resolved).

As an alternative, I designed a co-monotone and co-convex resampling method (which I'll call yafr-nohalo). Although a little simpler---and faster---than yafr-smooth, it does not introduce any halo ("guaranteed"), at the expense of more aliasing (compared to yafr-smooth not, for example, bilinear).

Although the two methods are quite different, many of their components are identical, which means that lots of what is computed for one can be used to compute the other.

Now, there are two ways that these two methods could be integrated into gegl.

OPTION 1:

Keep yafr-smooth and yafr-nohalo. The bugzilla would get rid of the current yafr and replace them with two new methods: smooth---which is like the current yafr, just about 5% faster---and nohalo, which is even faster. (I'm keeping the "yafr" out of it because it means nothing to users.)

OPTION 2:

Merging the two into a single yafr.

Then, I need to know how to let the user pass a parameter---most intuitively called "halo"---to the method when it is called (a bit like one passes an angle to the rotate utility).

Then, the behavior of the sampler will be as follows:

halo plain yafr-nohalo

0 < halo < 1 -> halo * yafr-nohalo + (1-halo) * yafr-smooth

halo = 1 -> plain yafr-smooth

1 < halo -> (plain) yafr-smooth + (halo - 1) * slope (nonlinear) part of yafr-nohalo

The first three correspond to arithmetic blending of the two schemes, which I'm sure can be done under OPTION 1, although THE NONLINEAR SLOPES WOULD NOT BE NEEDLESSLY COMPUTED TWICE if someone decides that, really, they like the blending parameter set to, say, 3/5. So, the first three cases do not add much functionality, just speed, a unified point of entry into the two yafr schemes (and a little bit of precision).

The last:

1 < halo -> plain smooth + (halo - 1) * just the slope (nonlinear) part of nohalo

is the intelligent way of doing "over sharpening," which may be a good thing in some situations (highly (jpeg) compressed photographs being one). It can't be done with plain blending because it only involves the nonlinear part of nohalo, and so this actually does add something "new."

----------------------------------------------------------------------

I have two questions:

Q1: Any preference between the two options?

Q2: If Option 2 is preferred, can someone direct me toward what I need to know to be able to get the halo parameter from the user (not at compile time, in "real" time)?

nicolas

Hello developers:

(Nicolas Robidoux here, developer of the YAFRs.)

Background:

I have rewritten the current YAFR code (gegl/gegl/buffer/gegl-sampler-yafr.c etc) so it runs much faster (and is cleaner). It now runs only about 10% slower or so than gegl-sampler-linear when performing large enlargements from xml.

(I've also rewritten gegl-sampler-linear so it runs about 1.5% faster, which is a pretty good improvement given the "gegl overhead," but this email does not have to do with this issue.)

Soon after finishing the above rewrite, I designed what should be the definitive family of resampling schemes, when the transformation is NOT primarily a downsample (sorry for boasting, but this is my honest assessment). (Downsampling has its own set of issues and requirements, as you all know.)

I've renamed this family "nohalo," for its distinguishing feature: it does not add haloing to images, ever (note: bilinear, nearest neighbour, exact area box filtering, B-Spline pseudo-interpolation and bicubic hermite with gradients set to zero also do not add haloing to images; just about everything else does). Although the kinship with the YAFRs is fairly clear when one looks at the code, the method is so different that I don't want to call it YAFR anymore.

This family is parameterized by an integer parameter, which can be understood as a quality level (hence, in the future, it will be tied to the gegl quality environment variable) but really has to do with the numbers of "binary zooming in" steps performed before falling back on bilinear. In particular, quality = 0 can naturally be understood to be bilinear.

I have programmed "nohalo quality level 1" for gegl, and it is fast (not as fast as YAFR, but almost), and give beautiful results when magnifications are not too large (what "large" is depends on the type of image, but basically the "best before" range goes up to about 4, unless the image is "smooth," in which case 8 is more like it).

I do not expect to have time to program higher quality levels for gegl for 6 to 9 months.

My question:

Given that some users may prefer YAFR for large enlargement scalings, should I keep it in gegl (and add nohalo and my improved bilinear through a bugzilla)?

Or should I just ditch YAFR, given that its days are numbered---nohalo with higher levels is that promising---and have nohalo replace it in gegl (and add my bilinear improvements)? (Note: I don't want to overwrite YAFR with nohalo because they really are different methods: either both YAFR and nohalo are in, or only nohalo.)

With my best wishes,

Nicolas Robidoux Universite Laurentienne

Hello all:

Two more things:

1) I could replace the current gegl-sampler-cubic.c with a fast implementation of Catmull-Rom, the bicubic which is generally considered "the best" (at least at high magnifications). Just let me know if you want that.

2) The new nohalo level 1 scheme gives, no question, better results, for small magnification or transformations which do not resize much, than anything else currently implemented in GEGL---including YAFR---with the possible exception of images which are "bichromatic" (for example, pure black and white images---no grey), in which case it does no worse than bilinear. (Higher level nohalo handles bichromatic images just fine.)

Nicolas Robidoux Laurentian University