https://bugzilla.gnome.org/show_bug.cgi?id=619314

contains a patch and quick test xmls for much improved samplers gegl-sampler-upsize.c and gegl-sampler-upsharp.c.

To run the xmls:

gegl file.xml -o output.png

Upsize implements the Locally Bounded Bicubic (LBB) method. It is a good general purpose method for image transformations which don't downsample much (e.g., enlargement, rotation).

Upsharp implements Nohalo ("no halo") with LBB finishing scheme. Recommended for natural images, especially slightly blurry ones, Nohalo mildly straightens and sharpens edges. It is not as good as LBB for text-like images.

IMHO, these are the best gegl interpolatory resamplers currently programmed for GEGL. (For "classic video game" images---think vintage Mario Bros---a smoothing, non-interpolatory resampler, like B-Spline smoothing or the (future version of) gegl-sampler-upsmooth.c, may be preferable. For downsampling, for example thumbnail production, an exact area method is preferable.)

Nicolas Robidoux

The final version of the upsmooth sampler (which uses VSQBS = Vertex-Split subdivision with Quadratic B-Splines finish) has been added to

https://bugzilla.gnome.org/show_bug.cgi?id=619314

Except possibly for moving the computation of the singular values of the (inverse of) the Jacobian matrix of the transformation out of the upsmooth sampler---this may be a good idea because for affine transformations the singular values are constant, and consequently do not need to be computed for every pixel---job which I'll assign to Adam Turcotte, this (hopefully) completes the work on samplers tuned for upsampling me and my team are planning to do.

Note that upsmooth could be argued to be a good replacement for bilinear. It's barely slower, and it upsamples and mildly downsamples better.

Of course I am preaching for my church, but I don't really see why one would want to use bicubic or lanczos (or even bilinear) instead of this new trio upsize, upsharp and upsmooth.

------

Next on the to do list: first, resamplers tuned for downsampling, then, "universal" samplers, which use Jacobian information to automatically pick a method appropriate for the situation.

Nicolas Robidoux

On Thu, Jun 3, 2010 at 3:43 PM, Sven Neumann wrote:

On Wed, 2010-06-02 at 22:11 -0400, Nicolas Robidoux wrote:

Of course I am preaching for my church, but I don't really see why one would want to use bicubic or lanczos (or even bilinear) instead of this new trio upsize, upsharp and upsmooth.

(snip)

Wow, we should really change the GIMP code to use the GEGL operations for scaling or at least allow the user to pick the GEGL ops so that we can drop the legacy scaling code in GIMP as soon as the performance issues are resolved.

Are there any performance issues at all? I guess we'd have to try what I suggested above to find out...

Sven

If<< current "performance issues" are significant, my team (Adam

Turcotte + Chantal Racette + me + of course anybody else who volunteers) would be willing to reprogram upsize, upsharp and/or upsmooth specifically for GIMP. For one thing, 8-bit channels allow many operations to be performed with integer arithmetic, which all three methods are friendly to.

A minor issue is that upsmooth (the one which is almost as fast as bilinear but which upsamples and downsamples better) requires (an approximation of) the local Jacobian matrix (or its inverse) of the transformation being applied. If all you are using it for is affine (this includes scaling and rotations) and perspective transformations, computing the exact Jacobian matrix is trivial.

(Upsharp and upsize do not require anything unusual.)

Nicolas Robidoux