[Kde-graphics-devel] Descriptions of new stuff

[Mosfet]

I assume your talking about all the ImageMagick scaling methods in resize.c? 
Yes, those are better quality but are much more expensive depending on which 
algorithm is chosen. Lots of floating point math in there. I haven't looked 
at your code but I've looked at ImageMagick's. Definitely not the fastest 
code on the block ;-)

The Imlib2 and Qt algorithms produce around the same quality, and are 
optimized more for speed, so if your not happy with Qt's you probably won't 
want to use Imlib's either. I assume you don't like the jaggies when scaling 
up. I wouldn't be against having two separate methods: The imlib2 port as a 
replacement for Qt::smoothScale for quick, reasonable quality smoothscaling 
and ImageMagick stuff when you need better results. 

As for code, I talked about that in my first email. If you want me to post the 
MImage stuff I can do that, or I can send it in separate emails. The scale 
code is in it's own C++ and asm file so is pretty small.

 
On Wednesday 15 December 2004 08:58 am, Lubos Lunak wrote:
> On Wednesday 15 of December 2004 15:30, Mosfet wrote:
> > ***Smoothscaling:
> > Since this is done a lot it is what everyone tries to optimize. Qt uses a
> > method based on NetPBM and is mostly integer. It's pretty good. The first
>
>  Qt's QImage::smoothScale() is pretty good only if you find it acceptable
> that something called "smoothscale" doesn't actually bother to smooth while
> scaling. Enlarge some image in basically any Qt/KDE image viewer (Gwenview
> being probably the only exception) and enjoy the Lego building blocks.
>
> > thing I did was add some MMX and 3dnow inline asm. I was able to use
> > doubleword operations to handle two pixel components at once and
> > reciprocal 3dnow multiplication for the division. It was about twice as
> > fast as the original NetPBM/Qt version.
> >
> > Then I got a look at Imlib2's scale. It replaces most of the integer
> > multiplication and division with fast bit shifts. Fairly complicated
> > code, but the normal C version runs as fast as my MMX optimized one,
> > (twice as fast as Qt/NetPBM). The MMX optimized Imlib2 scale runs twice
> > as fast as my MMX optimized one and 4x as fast as Qt. Definitely a good
> > one here.
> >
> > I've finished porting both the C and asm Imlib2 scales to QImage. It was
> > a pretty straightforward port of Imlib's scale.c. Mostly I just stuck
> > everything in a namespace, moved things around to work off of Qt BGRA
> > scanlines, and removed the unneeded border code, (as well as fixed the
> > formatting ;-). Seems to run fine. The asm routines did not need to be
> > modified at all.
>
>  I might have missed this in one of the previous mails, but is there some
> URL pointing to the sources? I'd be interested in this, because I've ported
> ImageMagick's scaling code for Gwenview
> (http://webcvs.kde.org/kdeextragear-1/gwenview/gvimageutils/scale.cpp)
> after realizing the shortcomings of Qt's smoothScale() (well, and scale()
> actually as well - interesting how one doesn't mind until the problems show
> in an image viewer). It produces very good results, and is about as fast as
> the Qt functions, but I wouldn't mind dumping it for something that's just
> as good and faster :).