On Sun, 28 Jan 2007 21:05:28 +0100, Sven Neumann <[EMAIL PROTECTED]> 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.

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.

Gimp-developer mailing list

Reply via email to