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