[Gegl-developer] (Yet Another) question about resamplers
Nicolas Robidoux
nrobidoux at cs.laurentian.ca
Sat Dec 20 06:16:10 PST 2008
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
More information about the Gegl-developer
mailing list