On Fri, 28 Nov 2008, Mattias Gaertner wrote:
> On Fri, 28 Nov 2008 15:47:35 +0100 (CET) > [EMAIL PROTECTED] (Marco van de Voort) wrote: > > > In our previous episode, Graeme Geldenhuys said: > > > > > > > > I'm curious: who needs more than 13 different image > > > > interpolations? > > > > > > Someone that writes image editing/manipulation software like Gimp, > > > Pixel32, Photoshop etc... ;-) > > Where do you see 13 different resample algorithms in these programs? > > > > > Someone must have though it's important, otherwise there wouldn't > > > exist that many interpolations around. > > lol :) > > > > And in general sb without any speed constraints :-) > > > > 64-bit per pixel. brrr. > > The nice thing about fpimage is that 64bit is only the processing size. > You are free to use any lower depth. > And this is the big problem of TFPBaseInterpolation. It creates a 64bit > temporary image. Imagine a 65mb 8bit grayscale image and try to > StretchDraw it. TFPBaseInterpolation first creates a temporary image of > 8-times the size - more than 500mb. > This is one of the reasons I wrote another TFPCustomInterpolation > without temporary image. And by precomputing the horizontal > and vertical interpolation factors it is faster too. Especially if > you use non linear interpolations. And it does not have the shrinking > bug that ignores pixels when shrinking more than factor 3. > And it does not have the enlarge bug that the last rows/columns > remain empty. > > Now there are three choices: > > a) replace TFPBaseInterpolation with my version Hm. I mistakenly supposed that your patch did this. Can you do the replacement and send a patch ? I'll apply it ASAP. Michael. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
