On Sun, 10 Jun 2007 13:12:02 +0200, Sven Neumann <sven@xxxxxxxx> wrote: > Hi, > > On Sun, 2007-06-10 at 05:53 +0200, g4@xxxxxxxxxxx wrote: > >> in result of some comments in #166130 I have been looking at image >> scaling >> in scale-funcs.c >> >> It seems the needs of scale down are quite different from the >> interpolation of scaling up so there are certain compromises in using >> the >> same lin/cubic/lanczos list of options. > > It would be very nice if you could work on this and prepare a detailed > analysis. But we will not look at this before the 2.4 release. Fiddling > with this bears too much risk of introducing more bugs. Or do you think > that there's need for immidiate action? Not "cubic": Well the scaling down is pretty sub-standard right now on all fronts. Pretending to have linear and cubic where in fact it does neither seems pretty poor, I would have thought that warranted a change before 2.4 . The spline code produces clearly better results from 1:1 down to 1:2 at least where averaging is weak and this must be a very common range for scaling. I do take your point about the danger of introducing bugs but it was pretty trivial to add catmull-rom. I did it in an almost identical fashion that scaling up does it. Much to my amazement it ran first time! I need to check out that borders handle overflow the same way before submitting but it seems to. Lanczos downscaling: I'm hoping to get some more detail from Yuu. As you know I've had some doubt about Lanczos on reduction since it went in. A nagging doubt that something theoretical is wrong. I think the cutoff frequency is wrong. Having said that it gives reasonably good results and IMO is stable for release. Again the base code has had a fair test period now and the required changes should not be fundamental change. I'm trying to avoid flooding bugzilla with the discussion but Yuu does not seem to want for get on this list just now. I'm not too convinced about the patch he's submitted yet but he seems to have a good degree on knowlege on sample theory so hopefully we will come together pretty quickly on this. > > For GIMP 2.6, we will need high-quality and optimised scaling algorithms > implemented as GEGL operators. Perhaps it would be a good idea to write > such operators now so that we can start to use them when we port the > core to GEGL. > Doubtful. I can find a bit of time to tweek in the existing code but 2.6 seems a very long way off just now and I really dont have the time to get deeply into geggling. A bit nearer the time maybe. gg/ _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
