From kde-devel  Fri May 28 23:55:07 1999
From: weis () stud ! uni-frankfurt ! de
Date: Fri, 28 May 1999 23:55:07 +0000
To: kde-devel
Subject: Re: devel-announce: ImageMagick and KDE to join forces
X-MARC-Message: https://marc.info/?l=kde-devel&m=92799474504129

Hi,

congratulations!

I cant wait to see that in Koffice's kimage :-)

Bye
Torben


On Fri, 28 May 1999, Mosfet wrote:

> After some correspondence with the ImageMagick team I have gotten the go-ahead
> to port the ImageMagick graphic manipulation library to KDE classes and
> announce a collaboration between KDE and ImageMagick. This brings a large code
> base of advanced graphical effects and conversions to the KDE project that can
> be used in order to design image manipulation applications.
> 
> The code for the ImageMagick based classes will be a stock artistic license
> similiar to that of X11 and FreeBSD.
> 
> Contacts: 	mosfet@kde.org - KDE developer specializing in X11 gfx.
> 		magick@wizards.dupont.com - The ImageMagick team
> 
> Devel Notes:
> 1) ImageMagick comes with a C library, C++ library, and several utilities for
> conversion, editing, and image display. The most useful thing to the KDE
> project is the C and C++ libraries. While the C++ library is certainly well
> designed, the fact that most effects use scanlines make a direct QImage derived
> child possible. This is preferred since there will be no extra overhead or
> duplication between Qt and the new classes. Thus we will most likely end up
> with a KMagickImage class that is derived from QImage and can be used by any app
> interested in utilizing the effects (KPaint II, KImageShop, etc..).
> 
> 2) If you are intrested in helping, start by looking at effects.c in
> ImageMagick. These contain the core effects available within the ImageMagick
> library. While these do make use of ImageMagick library specific structs, the
> core of the effects use scanlines. Thus most of the work is simply making them
> use QImage scanlines instead of the ImageMagick struct items. You may want to
> send me an email so no work is duplicated.
> 
> 3) There will probably be a plugin mechanism built into KMagickImage itself,
> thus allowing custom plugins to be used by any application based on the class.
> Since I am not sure which effects will be included in the base class and what
> will be inside plugins I suggest not adding methods to a QImage derived class
> just yet. Instead make them stand alone routines like:
> 
> QImage mySpecialEffect(const QImage &, int someParam, int anotherParam);
> 
> This will make it easy to place the method in a plugin or add it to the class
> itself later. 
> 
> Anyways, this is very good news for the KDE project and brings us much closer
> to having advanced KDE graphic processing and editing applications.
> 
> --
> Daniel M. Duley - Unix developer & sys admin.
> mosfet@kde.org
> mosfet@jorsm.com
> 
>