[fpc-pascal] fpImage resample via interpolation

Michael Van Canneyt michael at freepascal.org
Fri Nov 28 20:12:51 CET 2008



On Fri, 28 Nov 2008, Mattias Gaertner wrote:

> On Fri, 28 Nov 2008 15:47:35 +0100 (CET)
> marcov at stack.nl (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.



More information about the fpc-pascal mailing list