[Kde-graphics-devel] Descriptions of new stuff

[Mosfet]

Well, if we want to include a higher-quality expensive scale I'd be inclined 
to agree with Lubos and that using ImageMagick's algorithm is a good idea. It 
not only has a ton of different modes, but a lot of us are familiar with 
ImageMagick based code. I'm pretty good at optimizing that stuff by now.

That being said, I'm not really familiar with Krita and it's scale so if you 
port it and it produces good results that are faster, go for it >:)

We still need a quick smoothscale, tho. And for that I definitely vote for 
Imlib's. It's faster than anything else I've seen other than sampling, 
(including my own stuff), by a large margin. Think about things like 
previews, etc... Plus, image viewers may wish to use the quick scale for 
scaling down and a more expensive scale for scaling up. I've got huge images 
and I want to be able to view them as quick as possible with acceptable 
results. When your going through a sequence of large images scale speed is a 
big factor. Plus, I've already ported it to MImage and it would take a couple 
seconds to port to QImage :P

Really, we are getting into speed/quality tradeoff debates here. This is going 
to be an issue with pretty much every effect. I think there will probably end 
up being two variants for: scaling, bluring (gaussian and fast), and convolve 
(matrix size and integer vs. floating point). This is why I am toying with the 
idea of a global quality setting.

On Wednesday 15 December 2004 09:47 am, Michael Thaler wrote:
> Hi,
>
> > 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
> > replacement for Qt::smoothScale for quick, reasonable quality
> > smoothscaling and ImageMagick stuff when you need better results.
>
> There is also smooth-scale code in Krita which works quite well. It is
> based on a algorithm from Graphic Gems 3 available under public domain. The
> code is not very nice, it still uses malloc/free and it should be cleaned
> up and it is quite slow right now (but the reason is not the scaling
> algorithm, but the way pixels are accessed). If someone wants to improve
> it, speed it up, I would be very glad to see that. I hope I'll find some
> time to work on it during Christmas holidays.
>
> Michael
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel