On Sun, 28 Jan 2007 21:05:28 +0100, Sven Neumann <sven@xxxxxxxx> 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 _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
