On Sun, 10 Jun 2007 13:12:02 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote:

> Hi,
> On Sun, 2007-06-10 at 05:53 +0200, [EMAIL PROTECTED] 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  

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.


Gimp-developer mailing list

Reply via email to