[Kde-graphics-devel] Descriptions of new stuff

[Lubos Lunak]

On Wednesday 15 of December 2004 16:21, Mosfet wrote:
> 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 ;-)

 Yes, they're those from resize.c .
 6461ms Qt
  275ms  none (sampling)
 4708ms fast (box) - quality roughly equals Qt
 7106ms normal (triangle) - this is pretty sufficient in most cases
12153ms best (mitchell)

 It needed only little help to get faster, and I actually don't think the 
algorithm can get faster than this :(.

> 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.

 Are you sure the imlib algorithm actually does smoothscale? Enlarged pictures 
in Kuickshow look just as blocky as with Qt. Since you called that section 
"smoothscaling" I thought it could be used instead of the ImageMagick stuff, 
but if only as good as Qt then I'm afraid it won't help in this specific 
case.

> 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.

 I don't really care how one gets the source, but if it's available somewhere, 
talking about it certainly becomes simpler.

 PS: Were you so long away from Linux that you forgot how to quote mails :) ?

>
> 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.
> >
...
> >  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 :).

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/