Change image size & transform tool

[Casper Boemann]

On Thursday 23 June 2005 11:36, Michael Thaler wrote:
> On Thursday 23 June 2005 10:43, Casper Boemann wrote:
> > Well it doesn't do filtering yet, so you are kind of right.
> >
> > But I think mine does implement 2-pass scaling and yours does not.
> >
> > Mine takes (m+n)*x*y step (when filtering is done)
> > I think (have not checked 100% though) that yours take m*n*x*y
>
> Are you sure? I think the main reason why my old filter code is slow is,
> because it reads single pixels. I think it would be a lot faster if it
> would read whole lines and scale them.
> > I would like to know if you agree that that's the case, or if I'm just
> > misreading your code (havn't looked that carefully)
>
> I don't really know. The code is really not very clear and I did not look
> at it for a long time.
I have just taken a quick look and I think I was wrong. Yours indeed seem to 
take (m+n)*x*y steps as well.

> > Anyway mine is prepared for doing scale, shear, translate and rotate in
> > one go, making it a lot faster in those cases.
>
> But it also makes the code a lot more complicated, doesn't it?
Not really, no. It's basically just the scaling with an offset.

On the other hand. My code divides x and y as two distinct passes simplifying 
things a lot. Your code although also a two pass algorithm mixes them a bit 
closer.

It's actually my simplification that makes it possible to do shearing and 
scaling in one go.

So all in all I'd say they are equally complicated.

> I think it 
> is important to have high-quality zooming, shearing and rotating code. I
> don't say that you can write code that can do all this at once, but it is
> definitely beyond my understanding. Personally I would rather like to see
> seperate code for each of these actions that can then be optimised for
> quality and speed.
It's actually pretty seperate still.

> Would it not be better to use some e.g. scaling code with lower quality for
> the transform tool anyway and just apply a high-quality algorithm at the
> end?> I think you can never do a full Mitchell filter in real time on large 
> images and it is unecessary anyway. I remember that Mosfet once wrote
> something about a very fast, optimised scaling routine he wrote on
> kde-graphics. One can use a routine like this to rescale the image in real
> time and use a high quality scaling routine fopr the final result if you
> release the mouse button.
yes, but I don't think scaling can be done in realtime, with our tile 
structure. But I do intend to try and see.

> > Hower that means that no precalulation is possible
>
> I don't really know how much speed gain precalculations get you, this
> should betested-
>
> > Indeed yours looks better at the moment. As I said no filtering is done
> > in mine.
>
> I have a feeling that it looks even slightly better then the results from
> the GIMP, but I am not quite sure. Can someone scale pictures with GIMP and
> Krita and compare the results. Anyway, we should definitely aim to keep
> this quality.
I intend to use the filters from you code. In fact I've already copied them.

I also intend to use a filter for shearing making shearing (and thus 
rotations) look even better.

> > I would actually like it better if you would help implementing filtering
> > code in the transform visitor instead.
>
> As I said, I doubt that I understand enough about scaling, rotating and
> shearing to implement such a do everything at once algorithm.
A shame, but it's on my not so distant todo list. If you change your mind 
though...

-- 
best regards / venlig hilsen
Casper Boemann