[Gegl-developer] Passing parameter to sampler from XML file

[Geert Jordaens]

On 11-07-09 03:47, Nicolas Robidoux wrote:
> Let me try to explain the motivation for having different methods for
> transformations which are tuned for upsampling on the one hand, and
> downsampling on the other, and why a "one size fits all stylishly"
> scheme is neither easy to put together nor likely to be fast.
>
> Practical explanation:
>
> If one wants a "cheap upsize," bilinear is acceptable, and
> bicubic/lanczos are better. However, when used to downsample, these
> schemes behave almost like nearest neighbour, which sucks for
> producing thumbnails, for which variants of box filtering are way
> better. On the other hand, box filtering behaves like nearest
> neighbour when upsampling. This suggests that getting a single scheme
> which is great in both situations is not so easy.
>
> One can actually implement a more refined box filtering which is less
> nearest neighbour-like when upsampling. An example of such a scheme is
> nohalobox (see bugzilla) = downsharp/smooth. It's a good all around
> scheme, and it's reasonably cheap, but when upsampling it can't
> compete quality and speed wise with, say, Lanczos or upsharp.
>
> Bit more math:
>
> Locally, one can characterize transformations pretty well by
> considering the singular values of its Jacobian matrix (think of them
> as the absolute values of eigenvalues of the affine transformation
> which is the best approximation to the transformation at the point
> under consideration).
>
> Suppose now that one wanted to construct a scheme which does well in
> all circumstances. When both singular values are larger than 1: Use a
> good upsampling scheme. When both singular values are smaller than 1:
> Use a good downsampling scheme. What about all the other cases?
> Although it is possible to "blend" schemes, if the warp has a lot of
> variability accomodating both schemes will introduce artifacts and,
> more importantly, is likely to lead to a scheme which is slow in all
> circumstances.
>
> Hence, in my opinion, the need for a choice.
>
> ------
>
> Now:
>
> A GUI with the purpose of image resizing could keep this issue
> invisible to users:
>
> If enlarging in both directions ->  "upsharp" or "upsmooth" (a "smooth"
>                                                        toggle could do)
>
> If shrinking in both direction ->  "downsharp" or "downsmooth"
>
> If enlarging in one and shrinking in the other: Either make an
> educated guess based on which one is most representative, or use the
> "up" scheme first, and then the "down" scheme.
>
> However, the point of the samplers is that if and when perspective and
> complex warping are implemented in gegl, they won't skip a beat.
>
> Nicolas Robidoux
> _______________________________________________
> Gegl-developer mailing list
> Gegl-developer at lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
>
>
>    
I do get the point that choosing the right sampler for the task or 
situation is not that straightforward.
However I think that the samplers should be callable using there 
technical name from the gegl lib.
Making the names more gimp user friendly, or implementing a scheme is 
more for the end user tool.
This way each tool that would use GEGL could implement he scheme most 
suitable for the tool.

Geert