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

List:       kde-devel
Subject:    Re: KImageShop project started
From:       Bavo De Ridder <bavo () ace ! ulyssis ! student ! kuleuven ! ac ! be>
Date:       1999-06-01 11:25:13
[Download RAW message or body]

On Tue, 01 Jun 1999, weis@stud.uni-frankfurt.de wrote:
>Hi,
>
>On Tue, 1 Jun 1999, Mosfet wrote:
>
>> The effects are part of a class that will for now convert directly from a
>> KPixmap and QImage, and when the canvas is done work directly on that. There is
>> no need for Corba or anything.
>
>Sorry, it is late this night, buttthhh: How do you
>implement plugins then ?
>
>They must communicate with the master application which
>holds the image data somehow.
>

Indead, if you allow for filters to reside on a different computer than the
master application, you somehow have to transfer the data to the
filterlocation. This sounds like the same fragmentation and location problems
you have in distributed databases.

If seperating filters and kimageshop should prove interesting you have to
transfer potentially large datachunks (several megabytes for large images).

So transfering data should be out of the question unless computations take
considerably longer than transfers. 

My knowledge concerning image manipulation is not so big. However, I can see no
good solution to this problem. I would make some kind of non-gui imageserver.
This server would hold the image-data, plugins, ... a separate gui-client could
then communicate with this non-gui server. Off course, this is something you
already have with the X windowing system. 

My first idea: don't physically separate kimageshop from the plugins. Use corba
only for dynamic loading of plugins and for abstraction of the interface.
Doesn't mico has something like in-process activation (shared lib), in which it
uses local function calls?


BDR


 >bye
>Torben
>
>> On Mon, 31 May 1999, weis@stud.uni-frankfurt.de wrote:
>> > Hi,
>> > 
>> > How do effect filters work on the image data ?
>> > 
>> > You can not do that via CORBA because of speed reasons.
>> > Use shared memory?
>> > 
>> > Bye
>> > Torben
>> > 
>> > 
>> > On Mon, 31 May 1999, Matthias Elter wrote:
>> > 
>> > > Hello
>> > > 
>> > > You perhaps remember the KIMP/KImageShop discussion that recently took place on
>> > > this mailinglist. I'm happy to announce that Michael Koch (KImage), and myself
>> > > (Matthias Elter, KHelpCenter) have started an image manipulation application
>> > > called KImageShop.
>> > > 
>> > > We spent the last weekend working on a basic concept/design:
>> > > 
>> > > Similar to KodeKnight, KImageShop will be based on KOM.
>> > > All interfaces like import/export filters will be implemented as KOM
>> > > components. The KImageShop core application will be designed to be
>> > > light-weight and fast. The core application will "only" handle the image data,
>> > > layers and basic tools, like the move tool or the selection tools. Everything
>> > > else will be implemented as KOM components and loaded as needed. There will
>> > > be well defined KOM interfaces for:
>> > > 
>> > > - import filters,
>> > > - export filters,
>> > > - image manipulation filters,
>> > > - and tools.
>> > > 
>> > > Additional tools like a gradient editor or a screen shot utility
>> > > will be implemented as KOM components, too.
>> > > 
>> > > KImageShop comes with it's own XML based file format.
>> > > We decided to use an XML DTD because it greatly simplifies the
>> > > implementation of import/export filters.
>> > > To be compatible with GIMP KImageShop will have import- and export-filters for
>> > > the GIMP-fileformat.
>> > > 
>> > > KImageShop will provide several types of color representation. This will include
>> > > RGB- and CMYK-color representation.
>> > > 
>> > > With the vast amount of high quality image modification plugins available
>> > > using the GIMP plugin interface we decided to implement a compatibility layer
>> > > for using GIMP plugins with KImageShop. We decided against using the GIMP plugin
>> > > interface as native plugin interface for KImageShop because we feel that a
>> > > CORBA/KOM based plugin interface is much more powerful and simplifies the
>> > > implementation of plugins.
>> > > 
>> > > Similar to KSpread, KImageShop will be scriptable using python.
>> > > 
>> > > KImageShop will make use of the advanced canvas widget based on the upcomign
>> > > KImageMagick lib we would like to develop together with Mosfet.
>> > > 
>> > > We already have been contacted by a few interested people but for a project of
>> > > this size additional developers are needed. If you are interested in this
>> > > project please subscribe to the KImageShop mailinglist (kimageshop@kde.org).
>> > > Send a mail with the subject line "subscribe" to kimageshop-request@kde.org.
>> > > 
>> > > Greetings,
>> > > Matthias
>> > > 
>> > >
>> --
>> Daniel M. Duley - Unix developer & sys admin.
>> mosfet@kde.org
>> mosfet@jorsm.com
>> 
>>
--
-------------------------------------------------------------
Bavo De Ridder <bavodr@poboxes.com>

PGP Public Key: http://www.poboxes.com/bavodr/public.key.pgp
-------------------------------------------------------------

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

Configure | About | News | Add a list | Sponsored by KoreLogic