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 <= 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
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
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
