In my on-going research to reduce the filter artifacts noted in http://bugzilla.gnome.org/show_bug.cgi?id=166130 , I found many references to a promising improvement on the cubic convolution kernel approach I have been using.

As noted in the bug report using a convolution kernel entirely removes the somewhat obvious staircasing produced by the current interpolation at the expence of a slight softening of the image.

In all the research I have done I have come up constantly to references to work done by R.G. Keys where he uses 6 point spline fitting instead of the usual four, but despite extensive efforts I have not been able to find any reference to the actual piecewise polynomials he derives.

Since the way this technique fits into the code is virtually identical to the lanczos implementation a six-point approach would envolve exactly the same calculation effort as lanczos and the larger window and the increased order of convergence would almost certainly improve the quality and precision of the filter.

It would seem reasonable to assume this would bring us close to a best of both worlds situation, a clean interpolaton without the softening.

http://64.233.183.104/search?q=cache:pcUIULp7cboJ:ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19870013008_1987013008.pdf+fourth-order+convergence+catmull-rom&hl=en&ct=clnk&cd=3&client=opera

Keys’ cubic is a local, six-point inter- polant whose interpolation function is again given by piecewise cubic polynomials. However, in contrast to PCC, there are no free parameters. The algorithm is fourth order convergent (ref.
8) which is the highest
order which can be achieved with cubic polynomials;

All references to Keys' work seem to lead to papers published by IEEE and available on a per article subscription. I assume the charge for one or two articles would be fairly nominal. Would this be a good use of some of the gimp projects donations fund?

If the idea is acceptable I'll look into the details.

/gg.

Many thanks for the offer. Finally Simon was able to come up with a copy of Keys' paper for me but I will keep your offer in mind since I came accross several references to pdfs on IEEE that may also be useful.

Thanks to all for the many positive and helpful replies, and especially to Simon for coming up with the goods.

Now to see what effect it will have in practice.

regards, gg.

On Thu, 25 Jan 2007 18:13:57 +0100, Mukund wrote:

Hi Sven and gg,

Sven Neumann wrote:

Hi,

On Mon, 2007-01-22 at 10:13 +0100, gg@catking.net wrote:

All references to Keys' work seem to lead to papers published by IEEE and
available on a per article subscription. I assume the charge for one or two articles would be fairly nominal. Would this be a good use of some of
the gimp projects donations fund?

That sounds like very reasonable use of the money. Please try to find out which papers would be important for your work and how much is being charged for them.

I am a member of IEEE Computer Society and will be glad to get and share the full text PDF of these articles for GIMP development use. Same with ACM papers.

Kind regards,

Mukund

On Sun, 28 Jan 2007 21:05:28 +0100, Sven Neumann wrote:

Hi,

before you start attacking the bicubic interpolation routines, could you please have a look at the outstanding bug report for Lanczos:

http://bugzilla.gnome.org/show_bug.cgi?id=167956

Would be nice to get this one closed finally. And we can't release 2.4 as long as it is still open.

Sven

In fact that's exactly what I am working on.

If you look at my last post to the bug you linked above you will see I started a new bug since this one was getting too long, confused and mixing a number of issues.
http://bugzilla.gnome.org/show_bug.cgi?id=363775

my last comment in the new bug was that there remains a number of small drifts on linear cubic and lanczos. I see this as all part of the same problem which I am currently trying to track.

Even NONE is bahaving badly if you take a close look at it. NONE is the only one not to have -0.5 and it seems to have the largest drift. This has probably gone largely unnoticed since using NONE usually looks crap and no-one took a closer look.

I am particularly intrigued by the need for -0.5 fiddle factors on lanczos. My only justifications were:

a) it was needed to prevent drift b) it appeared in linear and cubic already , so the problem was not in the lanczos code
c) it seemed better to have a fudge factor than an offset in the image until someone can explain why they are there.

I am currently climbing the tree trying to see what is happening.

There seems to be a number of points to review here and some inconsistencies in the code. Probably mostly very old, well established, small scale errors. Accumulative rounding errors, different origins, and I suspect some small bug that is affecting all these methods.

Any comments on the following points from those close to the code may save some time.

1) gimp_item_scale_by_factors() uses new_offset_x = ROUND ... , gimp_item_scale_by_origin() uses straight integer arithmatic ie truncates the offsets. Any reason not to use ROUND all round ?

2) scale_region_no_resample() calculates offset tables effectively using (x + 0.5) . This would seem to be aimed at using the midpoint to scale down but has no meaning to scaling up. It's a nop. Using guint instead of gint for this data would also be more efficient.

3) maybe NONE needs the same mysterious -0.5 as the others until the reason becomes clear.

I agree the cubic spline vs cubic kernel issue can take second place to tidying up this lot.

gg