On Sun, 28 Jan 2007 21:05:28 +0100, Sven Neumann <[EMAIL PROTECTED]> wrote:
> before you start attacking the bicubic interpolation routines, could you
> please have a look at the outstanding bug report for Lanczos:
> Would be nice to get this one closed finally. And we can't release 2.4
> as long as it is still open.
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
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
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