About KImageEffect

Mosfet dan.duley at verizon.net
Wed May 11 21:39:01 BST 2005


This is re: the KImageEffect thread since I am not on the list...

Yep, I've already ported most of my stuff to Qt4 and it should be ready by 
Friday if you just want the lib, by Monday if you want the demo/test app. 
It's much more than just Imlib ports: almost everything I've done for 
KImageEffect has been rewritten, is much faster, supports inline MMX, and has 
been tested quite well since I've been releasing demos for awhile >:)

I noticed you guys disabled the MMX stuff currently in KImageEffect. I didn't 
write that MMX code, (I assume it's a problem with blend), but mine seems to 
work fine. If one of you can tell me what the problem is I could try 
rewriting that as well. I did some work on KCPUInfo if that's the problem: I 
fixed an SSE detection bug and added 3dNow2! and Integer SSE checks.

I'm not currently using KDE SVN, just Qt4 beta2 and my own crappy autoconf, so 
it will probably just be a tarball with the kimageeffect2 library. My plan is 
to give it to Aaron, post here, and you guys can integrate it however you 
want, (be it in KDEFX or it's own image library).

I've attached a preliminary Changelog.

-------------- next part --------------
KCPUInfo:

* The CPU extensions IntelMMX, IntelSSE, and IntelSSE2 are now just
MMX, SSE, and SSE2.

* There is now both AMD3DNOW and a new AMD3DNOW2 check for both
versions of AMD 3DNow!

* There is a new IntegerSSE check for the MMX-SSE available in AMD
Athlons and above.

* SSE check bugfixes. It was being improperly reported on my Athlon.

* MMX packed data types are now in KCPUInfo instead of the KImageEffect
source. Instead of being prefixed by "KIE" they are now in the KMMX
namespace.

KImageEffect:

* Big ole rewrite here. A lot of the stuff in KImageEffect was
originally ported from C code and contained messy, buggy, nasty stuff
because I wanted to keep things as much like the C code as possible to
allow for easier updates. Bad idea. Unreadable and hellua buggy. 

This has now been rewritten from scratch, heavily optimized, algorithms
changed, and in some cases inline MMX added for drastic performance
increases, (especially w/ convolve based effects). I've been posting
demo tarballs for people to try the algorithms for some time now and
everything seems alright.

* The library is now broken up into several source files for easier
maintainence.

* The Imlib2 smoothscale method has been ported. It's
very good! It seems to produce results similiar in quality to the
Qt/NetPBM method but in 1/6th the time with MMX and still less than 1/2
without it >:) The C source is in scale.cpp and the asm version is in
asm_scale.S.

* Grayscale: MMX SIMD support for handling 2 pixels at once. 32bpp
images can optionally reduced to 8bpp palette. This is all you need
anyways since red = green = blue, but you may not want to reduce the
image if your going to be doing more effects or scaling.

The fast mode has been removed. It wasn't used by default and didn't properly
weigh pixels. The MMX grayscale is about the same speed but with
weighted pixels.

There is also a grayscaleBrightness() method that uses the max pixel 
component. This is equivalent to the "Value" in HSV.

* Invert: MMX SIMD for this, too.

* Convolve, Edge, Emboss, Charcoal and related methods: There are two
new convolve methods: an integer one and a floating point one. You can
choose which one you want to use when applying an effect. The integer 
one is MMX optimized and the floating point supports 3dNow!. Big speed 
increases with these. Obviously the floating point convolve gives the
best results because we can use a more sophisticated kernel, but the
integer one may be preferable if speed is essential and the machine
does not support 3dNow! This is very exciting to me since convolve is
so useful. An MMX one kicks butt >:) It's now way faster than either
ImageMagick or KImageEffect's old one.

The rewritten convolve method handles the area of the pixel neighborhood 
outside the image boundaries correctly. This means edges are now properly 
handled. These areas are now handled separately and the algorithm is 
generally much more efficent than before. No more checks to see if the pixel 
is valid when processing the middle of the image. You can also select if to 
use optimal pixel neighborhood sizes or larger, ImageMagick-compatible ones.

* Blur: There are two new blurs. The default one is based on Imlib2 and
is a good, fast blur. The second one is a Gaussian blur and is more
appropriate if you are dealing with photographs and need higher
quality. I originally ported the Gaussian blur from ImageMagick for
KDE, but it never worked like it should. It's been rewritten and fixed.
It also supports 3dNow! for a big performance increase if available.

* Despeckle: Rewritten and now takes 1/4th the memory it used to.

* Spiff/Dull: These are the high quality contrast enhancements and
equivalent to contrastHSV(). I fixed HSV calculation and it can
optionally be inlined. There are other small efficency improvements
and a bugfix where I was treating brightness as luminosity.

* Edge Detection: There are now two versions. One that uses the new
convolve and a new one written from scratch using the Sobel algorithm.
Supports MMX.

* Histogram based effects (Equalize, Normalize): This now uses faster
integer histograms and maps instead of floating point and no longer
has unneeded upscale/downscale code that did nothing. The code is now 
much more faster and readable. Not sure why I originally did this in
floating point other than that's how ImageMagick did it...

* Interpolation and HSV classes: I was playing around with ideas for
how to speed these operations up. MMX isn't really going to help much
here so instead I created two different classes KInlineHSV and
KInlineInterpolate. The idea here is that you create an instance of
these classes outside your main loop and it holds any data needed for
HSV or interpolating. Then you can call inline methods inside your
loop. At least it should be inlined ;-) Haven't tested that yet, other
than that the classes work.



More information about the kde-core-devel mailing list