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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
