[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: My Todo List ;-) (long)
From:       Mosfet <mosfet () mandrakesoft ! com>
Date:       1999-12-30 14:19:08
[Download RAW message or body]

Matthias Elter wrote:
> 
> Mosfet wrote:
> >
> (...)
> > ImageMagick and Image Viewing
> >
> > As some of you may recall a long time ago I wanted to use ImageMagick as
> > a base KDE library. This got stalled because it's really hard to do
> > efficently. We have QImage->XImage->Image Magick Images that all need to
> > be converted. Not what I was looking for. We can skip some of the
> > overhead by using just QPixmap and XImage, but it would still be
> > inefficent when used in things like KImageShop's canvas. Even with
> > XImage you still need to convert back and forth to ImageMagick's
> > internal format.
> >
> > The approach I am taking to this is I also want to do a new image
> > viewer, so I will implement it with that first and if it works well it
> > can also be integrated with KImageShop. I want a new image viewer
> > anyways because nothing so far for either DE matches the power of xv. I
> > can hear you all now - "xv???". Yep, nothing so far compares to xv for
> > speed, basic color editing, and other cool features. Note that I am
> > referring to image viewing, not manipulation. Kview is supposed to be
> > lightweight and for things like viewing images in Konq so I figured I
> > would do a new one and we would have two: a lightweight and efficent
> > viewer (kview), and a heavyweight viewer with a lot of features. It
> > would have a algorithms menu like xv, and we can use that to test
> > ImageMagick stuff. This would be a new project so if your interested in
> > co-authoring it please feel free to email me.
> (...)
> 
> I had some time to study the ImageMagick code some time ago and I see
> _no_ efficient way to use it directly...neither to manipulate QImages or
> KisImages. The algorithms work on scanlines and it should be pretty
> simple to rewrite them to work on QImages. Simple but lots of work :).
> The approach I'd suggest is to write a new image manipulation lib based
> on the IM algorithms that works directly on QImages and which can be
> used as a base for apps like your advanced image viewer. For KImageShop
> we will have to implement the algorithms again to work directly on
> KisImages. Converting QImages<->KisImages is not efficient enough.
> 

That's the impression I got as well, although it can work with just one
conversion back and forth when dealing with XImages. For an image viewer
I would probably add a convertToXImage routine for QPixmap's X11 Pixmap
handle and use that when doing the algorithms - avoiding QImage entirely
when doing ImageMagick effects. That should be good enough to start out
with at least, and while it would be nicer to be able to work directly
off of XImages or QImages we won't be any more inefficent than
ImageMagick's own code which has to do the same thing.

For KImageShop I think you are right, everything would need to be
converted to work directly off the canvas instead of the Image RLE
scanlines in order to get decent performance. It's not difficult to do
but does entail quite a bit of tedious work. 

> Greetings, Matthias
> 
> --
> Matthias Elter
> elter@kde.org / m_elter@t-online.de
> KDE - http://www.kde.org

-- 
Daniel M. Duley - Unix developer & sys admin.
mosfet@mandrakesoft.com
mosfet@kde.org
mosfet@jorsm.com

[prev in list] [next in list] [prev in thread] [next in thread]