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 <= 0, but the codes are kept separate? Or should we simply put the two together with an if statement which steers internally things toward nohalo when they should? Thanks (for your patience), Nicolas Robidoux Universite Laurentienne _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
