rotating & shearing

[Michael Thaler]

On Tuesday 07 February 2006 22:57, Casper Boemann wrote:

> I would much rather have you help optimizing and bugfixing the transform
> code. At least come with input. I know you don't know the code, but it is
> not that different from the other one, so you should soon find yourself on
> familiar ground.

That is true, I don't know your code. Your old transform visitor did scaling & 
rotating/shearing with the same algorithm. But, if I remember correctly, this 
prevents the optimizations I made in the scaling code. I rather prefer to 
different algorithms for scaling, rotating/shearing then one algorithm that 
does everything & is hard to understand & hard to optimize. Is your algorithm 
still only one function that performs scaling and rotating/shearing or do you 
have different functions for that now?

> To an extent the colorspace independence is what makes it slow.

I personally use Krita to rescale my digital photos (2272 x 1704 to 
something). For this I need fast & good scaling. If your algorithm is 
considerably slower / the quality is not as good, I will probably start using 
gimp again. I think scaling images is so central, it should be really as fast 
as possible & and also very good quality.

I would volunteer to work on my old code. My idea is to use different code 
paths for 8 bit colormodels and the rest. That means, for 8bit RGB/CMYK the 
old algorithm would be used, but for other colorspaces a version that uses 
mixing functions from the colorspaces. This way scaling RGB/CMYK images would 
be as fast & good as before, but the scaling routine would still be 
colorspace independent.

But I don't want to work on something that gets replaced anyway. So please let 
me know if you intend to replace my scaling code anyway. And please let me 
know before you do any commits, so that I can keep a private copy of my code 
(don't really want to go back to using gimp for my digital photos, so I 
better keep a private copy in this case).

Greetings,
Michael