releasing inplications

[Boudewijn Rempt]

On Sunday 13 March 2005 20:39, Michael Thaler wrote:

> I would also really like to see Krita released. I showed Krita at our LUG
> info event and some people seemed really interested. But unfortunately the
> only thing I could tell them was, that there are currently no packages for
> any distribution and that the only way to install it is from CVS.

That's not completely correct: there's a pre-autolayers binary at 
http://www.xs4all.nl/~bsarempt/krita-cvs-current.tar.bz2. I've been waiting 
with making an updated version until image export was working again.

> But I cannot even recommend Krita to users experienced enough to install it
> from CVS. When I tried to make some paintings for my talk last weak, I
> realized how many things are currently broken. You cannot even save
> pictures in jpg or png.

Really broken, too, are:

* Convolution filters (calling a convolution filter twice leads to a really 
bad memory corruption, verified with valgrind).
* Painting on moved layers (Bart's patch fixes this, but it may be the wrong 
fix)
* CMYK (but I'm fine with excluding that from the first release -- I managed 
to improve it a whole lot, but it's still not showing the right colours)
* Selection brush & eraser are broken again -- @#$%*! Other selection tools 
need to be fixed, too.

I'm going to spend the rest of the evening on image export/import; but this 
will likely prove to be a tough nut to crack, since it requires investigation 
of ImageMagick.

<...>

> Releasing Krita with KOffice 1.4 would at least force us to fix all the
> bugs introduced with the new tilemanager. I think this really would be a
> good thing. I would rather like to see a relativlely bug-free and feature
> complete version of Krita with only RGBA8 support then wait another couple
> of years everything is implented.

Hopefully, once we get in a release-often-keep-HEAD-working swing it won't be 
so long before we've got the rest.

> I still think Krita should ultimatively support different color-models and
> channel-depths, but if this cannot be done until KOffice 1.4 is released, I
> think we should concentrate on the things that can be done.

Yes, that's why I just introduced a new keyword to #define out stuff we are 
not going to get working for the 1.4 release. I'm really glad you've begun 
work on the tools -- those need some loving care, too. Clarence Dang did some 
work on them, but that was a long time ago. And 

> One thing Krita is really missing is an easy way to write plugins. We need
> functions like getRGBdata, setRGBdata, getCMYKdata, setCMYKdata and so on.
> Maybe it would also be nice to be able to access tiles directly to speed up
> prlugins. In the case the tiles store the data in RGB this would not be any
> problem. In case the data is stored in another colormodel, there should be
> functions to convert to and from RGB.

There is a really easy way to port all plugins for other applications that 
demand RGBA8: every layer can be converted to a QImage. The easiest way to 
port plugins is to use that -- convert the layer to a QImage, filter it, and 
convert it back. Possibly even in big chunks if the layer is bigger than, 
say, 1000 * 1000 pixels. That should give us an easy way to have lots of 
filters very quickly, we might even be able to reuse most of the digikam 
image plugins directly.

> I think most fitlers cannot really be written in a color-independent way or
> even if one could in prinicple, it is propbably much harder then just write
> an RGB one. This is especially true for porting filters from other
> applications like gimp to Krita, e.g. the GIMP fitlers asume RGBA8.

The goal is to make writing colorspace independent filters as easy as possible 
-- but we're not there, so we should take the QImage route.

> If I find some time, I will try to implement the polyline tool and the
> polygon tool. That should not be to hard.

Great!

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050313/7a63448f/attachment.pgp