(Yet Another) question about resamplers

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

 



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



_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux