Legacy ImageMagick Discussions Archive

IM7 v8200.
Compare the code for SplineInterpolatePixel that starts at line 4432 of pixel.c with the code for CatromInterpolatePixel that starts at L4210 for example. Specifically, compare L4273 with L4475.
With Catrom, what we have decided is the right thing to do is done: The interpolated transparency is reciprocated and multiplied by the interpolated pre-multiplied colour.
With Spline, the transparency at "n" is unmultiplied, which means it's just canceled out (it's multiplied at L4463 and unmultiplied at L4475) and never interpolated. Spline does not implement the "transparency bug fix". (Spline is not hurt as much by the "non-fix" because it's monotone. This would be obvious with Catrom.)

-----

I'm just about to check in code (into IM7 through the ImageMagick-Windows svn) that fixes everything and unifies the treatment of Catrom and Spline. It runs more slowly than the current Spline, but it's because it interpolates alpha, which the current Spline code does not. It is also structured so that I could easily add Mitchell.

(I've tried using a coding style which is closer to what's usually found in IM. Let me know if I'm missing something. I've also untabified. Let me know if this is verboten.
I've also used the safe coding practice described here: http://stackoverflow.com/questions/1810 ... fixed-size)

The Spline results with the original code look very wrong for cubic B-spline smoothing, even if there is no transparency. They are super jaggy and they have serious boundary alignment artifacts.
"Mine" look like what they are supposed to.

Now fixing in IM6.
P.S. Done.

Nicolas, thanks for the patch. Don't forget to update IMv6 Changelog so users can see what changes are made to the source distribution.

I could collapse the code for Catrom and Spline in the "cases" using function pointers.
Should I?
It would make clear that they basically do the same thing. And if and when I add Mitchell, it would add very few lines: A function that computes the Mitchell coefficients, and then cases that only involve calls to the generic "evaluate a tensor method over a 4x4 stencil anchored at the second point from the left/top" applicable to the data type.
(Note that I don't want to add a "general" Keys cubic coefficient generator because I can reduce the flop count a lot by treating specific ones (like Catrom) individually. My Catrom coefficient generator requires only 10 flops for four coefficients. I can't achieve that with a general Keys coefficient generator.)

Go ahead. We can always revert if we find out later there are any problems such as efficiency or portability.