[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