As far as I can see, fpImage has for StretchDraw only the TMitchelInterpolation.

The current implementation has a few drawbacks:
- it creates a temporary image for resizing horizontally. If you have to resize big scanned images or gis data this makes trouble.
- it computes all factors each time for every pixel
- it seems to only support shrinking by up to a factor of two.

I have written an interpolation that does not require a temporary image (only a small buffer for a few lines), pre computes the factors and supports any shrink factor. It is about 250 loc just like the TMitchelInterpolation, needs less memory and is about twice as fast.
I will contribute it to fpImage.

At the moment it uses a linear distribution for enlarging. I'm not yet sure if I should use the Mitchel distribution or a Gauss distribution. Maybe someone can give me some advice.

Mattias

Mattias Gaertner wrote

As far as I can see, fpImage has for StretchDraw only the TMitchelInterpolation.

This is not correct. This is the standard interpolation used. But you can use other interpolations. The extinterpolation.pp unit contains other interpolations (6 or 7) that can be used with the StretchDraw implementation.

But additional interpolations are always welcome.

Michael.

fpGUI doesn't use fpImage yet, but I did borrow the StretchDraw() code from there. And yes, you can specify a whole bunch of other interpolations to use. If memory serves me well, fpGUI has a few more interpolations than fpImage. When I start implementing fpImage support in fpGUI, I will contribute those to FCL.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Zitat von Graeme Geldenhuys :

Thanks.
Impressive list.
But they have all the same problems. They create an unnecessary temporary image and have a fixed max support. Maybe I misunderstand the computation. I would expect a mapping of a linear distribution 0..1 to a mitchel, gauss, bilinear, ... distribution 0..1.
Something like diff:=Filter(diff*MaxSupport);

I will extend my function, so that you can use any of the other interpolations.

> But additional interpolations are always welcome.

Ok. I will extend it and you can add it to this unit.

I'm curious: who needs more than 13 different image interpolations?

Mattias

Mattias Gärtner wrote

I'm curious: who needs more than 13 different image interpolations?

Someone that writes image editing/manipulation software like Gimp, Pixel32, Photoshop etc... ;-)
Someone must have though it's important, otherwise there wouldn't exist that many interpolations around.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Von: "Mattias Gärtner" I'm curious: who needs more than 13 different image interpolations?

13 different users, of course. ;)

That was a rhetorical question, wasn't it?

Vinzent.

In our previous episode, Graeme Geldenhuys said:

And in general sb without any speed constraints :-)

64-bit per pixel. brrr.

Not completely. ;)

I don't doubt the need of 13 different interpolations. I know most of the interpolations from other graphical/mathematical applications. But I doubt the need for 13 different *image* interpolations. My question is if they exist in fpimage only, because they were easy to implement, or are they all that different that you need them?
Maybe someone can give me a link or give some advice where to start searching?

Mattias

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

b.1) keep TFPBaseInterpolation and add my version
(TFPBase2Interpolation). Add for each fpimage interpolation class a new one descending from TFPBase2Interpolation.

b.2) keep TFPBaseInterpolation and add my version (TFPBase2Interpolation) with a property Interpolation where another interpolation can be set and make Filter and MaxSupport of TFPBaseInterpolation public.

Mattias

Hm.

I mistakenly supposed that your patch did this.

Can you do the replacement and send a patch ? I'll apply it ASAP.

Michael.

I think speed vs. quality if you have multiple steps. While playing with aggpas, I found that the image1 example gives a nice idea about the differences:
http://aggpas.org/aggpas-demo.htm

Marc

when i search for the lazarus help system with html and the comming chm, i didn't find information about the creating this, for other languages.

It is not clear for me, how to handle this. The study of the structure of the svn and the search inside of the wiki and the docs didn't make it clear for me

1st Question:
Should this handled by extension of the xml-files like English: actnlist.xml
German: actnlist.de.xml
or creating a new 'docs-de' (beside the current 'docs')path ?

i found only, fpdoc should be able to handle some languages by using an comandlineoption.

2nd Question:
Are there more information about this theme available, or a designguide? (I know the source of the fcl/lcl documentaion)

It is interesting for me, because i will spend time in documentation (in german for germans) for the project. I see with the LazInfos (in German only) the people want documentation in their native language.

I think you can work on that even if there isn't yet a decision about your question. If it turns out to be different from what you made, just rename the files.

I would suggest a new directory. Too many files in the same directory make it hard to find things.

I know, that this this is not a theme yet. But for a lot of people it is interesting to have help in their foreign language.

When i have more knowledge about the process of generating and using the helpsystem in fpc way of working, i will use a seperate directory and changed nameschema.

THX for your help