[Kde-graphics-devel] Descriptions of new stuff

[Mosfet]

On Thursday 16 December 2004 09:06 am, Lubos Lunak wrote:
...snip...
>
>  Well well ... maybe I should have been less scared of the Imlib2 code when
> I was looking for a place to steal the scaling from :(. Apologies for
> doubting :). After trying the code I see I can throw the ImageMagick code
> out from Gwenview. The Mitchell filter is still slightly better when it
> comes to quality, but probably only freaks would notice that anyway. I
> guess it'd be difficult to find something better than the Imlib2 code when
> it's almost as fast as just sampling and about as good as the Triangle
> filter.
>

Yeah, I've been testing it and it's a really cool algorithm. I don't upscale 
images much so I assumed the quality would be about the same as Qt, but after 
testing it's much, much better :) This algorithm really rocks. I'm suprised 
more people haven't commented on it. It really got me excited: I am 
disappointed I didn't look into Imlib earlier.

I not only strongly recommend the code go into KDE4.0, I suggest recommending 
all developers switch from QImage::smoothScale(). Great quality at what 
appears now to be around 1/6th the time since I removed Imlib's border 
calculation code.

I also ported the Imlib blur to QImage and it seems quite nice and fast. 
Sharpen I ported but it's results are not that good. The edges are not 
calculated properly and it generally looks bad. I wrote a new convolve 
version during lunch and will be sticking with that. Neither are as important 
as scaling, tho. There are a few other things like asm rotate and blend I 
would like to check out, but that's about it.

>  So I'd like to use your code in Gwenview as the default scaling code.
> However, I don't see anything like a license anywhere in your sources.
>

BSD, same with Imlib. All I ask is that you keep credit for stuff I did, and 
give credit to the people I derived from, (In this case Carsten Haitzler and 
Willem Monsuwe). Check out the Imlib2 COPYING file for their exact license, 
and mine is the same as KImageEffect. 

>  Also, I have a question about the MMX code - is it threadsafe? I seem to
> vaguely remember hearing about some problems with it, and e.g. the libpng
> docs say something similar. I cannot find anything relevant using Google
> though.
>

Yes. I don't recall ever hearing about thread issues with MMX but it uses the 
fp registers so if floating point works MMX will too. Maybe there was a 
problem with SSE at one point, I dunno, but if there was it should be fine 
now.

>  BTW: This code below changes the img argument:
> QImage MImageEffect::smoothScale(QImage &img, int dw, int dh)
> {
>     if(img.depth() < 32)
>         img = img.convertDepth(32);
>

Yes, the source image is promoted. Qt does the same AFAIK. Writing a version 
that doesn't do this for the Qt algorithm would be no problem for me. Doing a 
Imlib based version a little harder ;-) With lines and lines of bitshifts 
it's a little difficult to tell what's going on in places >:)

>  BTW #2: The ~600K tarball would be much smaller if you included only the
> sources + Makefile.am in the sources directory, Makefile.am.in and
> configure.in.in in the toplevel directory, and told everybody to add admin/
> there and run "make -f Makefile.cvs" .

Heh, yes that's true. This way it's simpler tho and they can just run 
configure. Hopefully Aaron will continue hosting tarballs and you won't get 
600K emails anymore ;-)