Question about resamplers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


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.)


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 <= 0 -> 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
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

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


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)?


Gegl-developer mailing list

[Video For Linux]     [Photo]     [Yosemite News]    [Yosemite Photos]    [gtk]     [GIMP Users]     [KDE]     [Scanner]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]     [Webcams]