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

List:       kde-devel
Subject:    devel-announce: ImageMagick and KDE to join forces
From:       Mosfet <mosfet () jorsm ! com>
Date:       1999-05-29 4:46:39
[Download RAW message or body]

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

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