Hi,

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.

currently linear and cubic both execute the same code which just averages all source pixels, it is neither linear or cubic.

Also downscaling has different needs depending on whether the scaling is near to unity or not.

I think cubic (catmull-rom as per scale up) should give better results. It may be necessary to decide a policy for reductions greater than 4:1 to avoid ignoring some data points.

After that linear may benefit from a weighted mean rather than just lumping all the source pixels together. This may reduce the softening currently seen.

Currently pretending to do cubic and just averaging is not too good.

/gg

On Sun, 10 Jun 2007 05:53:57 +0200, wrote:

I think cubic (catmull-rom as per scale up) should give better results. It
may be necessary to decide a policy for reductions greater than 4:1 to avoid ignoring some data points.

As I suspected the catmull-rom spline works better than the existing code on small reductions (tested at 65%). At larger reductions it introduced some intrusive colour distortions so the existing pixel averaging code produced better results in this case.

I think "cubic" interpolation probably should be changed to actually do cubic and let the user find out where it is better or worse.

There is also a slight lack of clarity in calling what the code does now "linear". Averaging colours over 4.35 pixels , for example, cannot be described as linear interpolation!

Maybe the name "linear" should be changed to better reflect what the code does. Perhaps "pixel mean" or "average".

This would accurately reflect what the code does in both directions since linear scale up does not actually do a linear interpolation anyway (ie fit a first order polynomial), it does a mean which gives the same result.

It does not sound a good since we're all so used to linear but it is understandable to just about anyone and does accurately describe what the code does in both cases.

Any other suggestions?

gg

On Sun, 10 Jun 2007 13:12:02 +0200, Sven Neumann wrote:

Hi,

On Sun, 2007-06-10 at 05:53 +0200, g4@catking.net 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/

On Sun, 10 Jun 2007 14:24:20 +0200, Mark Lowry wrote:

Actually, I think the best naming method for the end user would be based on speed and quality (fastest, best, etc.)

thanks for the post.

I know what you mean but "fast and a bit grainy better on small reduction ratios" does not work and "fast" without any further comment is about as much help as "good" , "best" etc. It's too subjective to be able to say this sort of thing.

Sure it would good for the user if the life of DSP was that simple, sadly it ain't.

Also Gimp is not aiming at a click and "share" audience. Let's try to imagine that some of the user-base probably know a lot more about the subject than we do and treat them with a bit of respect.

Anyone who has no idea what linear means will, like you say, suck and see. Everyone else has the right to some indication as to what method they are selecting. Hell, they may even know what they are doing!

It seems there was some discussion in 2005 about decimation but it was rather inconclusive.

Clearly "linear"="cubic" is nonsense, both analitically and UI wise. The options should do something different. Looking a bit closer, reduction seems to require some top-down design before coding takes place.

1/ It seems that "linear" aka average should be wieghted rather than just the mean it seems to do now.
2/ Is cubic a valid reduction method. It seems to provide better results than decimation near to 1:1 , does decimation need a wider window or is cubic good here?
3/ Can the different needs of interpolation and decimation be represented by the same interface? (Same drop down list.) 4/ I leave lanczos out of this for the moment because I think Yuu's contribution will finally provide the missing link on L3 reduction. I expect it be the most consistant of the current options, working in both directions.

gg/

On Sun, 10 Jun 2007 23:41:01 +0200, Sven Neumann wrote:

Hi,

On Sun, 2007-06-10 at 14:42 +0200, g4@catking.net wrote:

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.

We are about to release GIMP 2.4 and as soon as that has happened we will start to port things to GEGL. So working on GEGL now is the best thing you can do. Patches for the GIMP scaling routines are most likely not going to be accepted before 2.4. And after 2.4 we are going to throw out this code anyway.

Sven

OK, thanks for saving me wasting my time. ;)

This discussion about decimation<>interpolation needs to be picked up again once 2.4 is out.

I'll still see if I can finalise the lanczos code for downscaling since that routine will need importing into GEGL and it should at least be theoretically valid.

gg/