On Thu, Jun 3, 2010 at 3:43 PM, Sven Neumann <sven@xxxxxxxx> wrote: > On Wed, 2010-06-02 at 22:11 -0400, Nicolas Robidoux wrote: > >> Of course I am preaching for my church, but I don't really see why one >> would want to use bicubic or lanczos (or even bilinear) instead of >> this new trio upsize, upsharp and upsmooth. (snip) > > Wow, we should really change the GIMP code to use the GEGL operations > for scaling or at least allow the user to pick the GEGL ops so that we > can drop the legacy scaling code in GIMP as soon as the performance > issues are resolved. > > Are there any performance issues at all? I guess we'd have to try what I > suggested above to find out... > > > Sven >>If<< current "performance issues" are significant, my team (Adam Turcotte + Chantal Racette + me + of course anybody else who volunteers) would be willing to reprogram upsize, upsharp and/or upsmooth specifically for GIMP. For one thing, 8-bit channels allow many operations to be performed with integer arithmetic, which all three methods are friendly to. A minor issue is that upsmooth (the one which is almost as fast as bilinear but which upsamples and downsamples better) requires (an approximation of) the local Jacobian matrix (or its inverse) of the transformation being applied. If all you are using it for is affine (this includes scaling and rotations) and perspective transformations, computing the exact Jacobian matrix is trivial. (Upsharp and upsize do not require anything unusual.) Nicolas Robidoux _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
