Any suggestions RE: the intelligent way of implementing samplers with multiple quality levels?

(Note that Adam and Eric may be able to figure this out without your or my guidance, but in the interest of faster progress I am asking "planning" questions here.)

My question will make more sense if I explain things a bit:

The nohalo family of resamplers has "levels," which are most easily understood as "quality levels."

Currently, an outdated nohalo level 1 is in the gegl library as gegl/gegl/buffer/gegl-sampler-sharp.c. (It is correct, but it is much slower than it has to be.)

Nohalo level 2 is near ready (for VIPS), and by the end of the Summer we hope to have levels 3 and 4 implemented in GEGL.

Now, these could be associated with quality requests (say, if quality < .25, use nohalo level 1, if quality < .5 use level 2, etc).

Note, for example, that the footprint (stencil) gets larger as the quality increases (think of Lanczos methods, for example).

How would you like this to be set up? Are there examples we could follow?

A related issue:

The upcoming snohalo (snohalo level 1 is ready in VIPS, no progress on snohalo level 2) also has quality levels (analogous to the nohalo quality levels). The key aspect is that snohalo has a blur parameter which, when set to 0, reduces the method to the same level nohalo, which runs considerably faster (because, among other things, it has a much smaller footprint). Any suggestion on how to implement this in GEGL so that a call to snohalo actually return nohalo when blur

Thanks (for your patience),

Nicolas Robidoux Universite Laurentienne

RE: implementing multiple quality levels.

At this point, it would appear to me that the simplest way would be to put all the nohalo levels and snohalo levels in one single file, and toggle between them based on requested quality level (determines the level used) and blur level (if blur 0, use snohalo).

What I don't see right now is this:

1) Although this has the advantage of "putting all the nohalo/snohalo stuff in one place," I wonder if toggling between methods at the sampler level will have a large speed hit. Keeping things separate, although it would force the calling operation to specifically request a particular version of the scheme, may lead to faster operation.

2) The current gegl implementation of nohalo level 1 (gegl/gegl/buffer/gegl-sampler-sharp.c) contains the following code:

static void gegl_sampler_sharp_init (GeglSamplerSharp *self) {
/*
* context_rect is a five-by-five stencil centered around the * nearest input pixel center. See comment below about using a * "non-centered" stencil (one based at the corner) instead. */
GEGL_SAMPLER (self)->context_rect.x = -2; GEGL_SAMPLER (self)->context_rect.y = -2; GEGL_SAMPLER (self)->context_rect.width = 5; GEGL_SAMPLER (self)->context_rect.height = 5; GEGL_SAMPLER (self)->interpolate_format = babl_format ("RaGaBaA float"); }

Basically, this code specifies the "footprint" (stencil) of the input image data needed by the resampler.

The issue is this:

snohalo level 1, for example, has a different footprint than nohalo level 1, and both are different from the footprints of snohalo level 2.

I've given Eric the job of figuring out how to intelligently switch between methods/footprints based on requested quality and blur levels. However, if you have any idea/suggestion, please let us know.

Nicolas Robidoux Universite Laurentienne