Krita, formerly known as Krayon,
formerly known as KImageShop, never known as nor intended to be the Kimp, is
available for your testing pleasure.

For the first time since development started in 1999, Krita is complete
enough to be packaged as the first preview release. Building on the great foundation
laid by the original team, the enthusiastic work by John Califf and the thorough
architecture designed by Patrick Julien, the Krita developers have been working
real hard during the last year to bring you a firework of interesting
features.

Those include (but are of course not limited to):

painting with Gimp brushes or image filters

gradients & patterns

excellent tablet support

world-class image scaling

Note: This is not even an alpha release. Stuff is broken, not implemented
at all or even not even intended to be implemented. We've been making
really great progress, but there's plenty left to do -- a challenge to someone
wanting to get their hands dirty with a paint app that's still small enough to
understand.

Installing Krita might interfere with your existing KOffice installation,
as it depends on KOffice CVS. But if you're curious or anxious to
know how far we've come in the past year (or five), download the packages Daniel
Molkentin has prepared and made available.
Because Krita is very actively developed, with several CVS commits per day, we
also provide Krita nightly
snapshots. SUSE packages will be available soon.

If you don't feel up to compiling, but still want to gaze at the look & feel
(described by as "very clean, very easy to find your way around" by an expert
Photoshop user) you can go to the screenshots and sate
your curiosity.

For now, all I want to do is to thank all the people who have worked on
Krita: Michael Koch, Matthias Elter, Andrew Richards, Carsten Pfeiffer and
Toshitaka Fujioka for starting this amazing project, John Califf for impelling
the project,
Patrik Julien for designing Krita's current architecture and finally the current
crew:

I think anon means the README.PREVIEW file I send round to ask for comments. That one is in the packages. I did a different announcement for the Dot, shorter, snappier and more upbeat. Not that there hasn't been some fierce editing going on with what I wrote... Mostly quite good, so I haven't got a problem with it, but if you want to read what I wrote, read the kde-announce mail.

Using krita I would like to encourage the krita team to focus on features gimp has not established yet especially a working 16bit/channel framework.

I hope there will be a generic painting API für krita and collaboration with kipimodules and digikams imageplugins. If there is a nice scripting host for krita I would like to port my gimp scriptFu to krita as soon as possible :-)

I think the image import problem is caused by a problem with your image magick libraries. Perhaps you've got the wrong version installed, or maybe two versions, and the header files of one version are used, but Krita is linked with another version.

We're designing for 16bit/channel images, but haven't added those yet. However, doing so means that we cannot use the kipi plugins, since those are based on QImages which are passed between app and plugin. If we were to use those, we'd need to convert the current layer to a QImage (losing data), filtering and then converting back. It could be done of course, but I guess it would be best to put a kipi connector in a plugin. Could be a nice job for someone interested in getting involved.

Finally, Cyrille Berger has started work on ksjembed plugin, but it's not advanced enough to actually do anything.

Yes... And it would get worse when adding more layers. We have two problems here: we need to load all of the image into memory before work can begin. Ideally, we'd support deferring loading until parts of the image are touched, initially showing a preview. It's on the todo. The second problem is that we have cool tile manager for the data that's already loaded, but we don't support swapping in and out yet. And currently nobody has been brave enough to try and implement that part of Patrick Julien's design.

There are also some inefficiencies in the accessing of image data. We're working on those, though. I'm currently writing performance/stress tests so we can make informed performance improvements.

I wonder why Boudewijn is always stressing that it's
not meant to be a KIMP (i.e. a concurrence to GIMP).
I know that he likes to build a real paint tool
(like Fractal Painter) for KDE. But I'm quite
sure the majority of people will see it as GIMP replacement
and everyone should be honest enough to admit that.
One day ago he posted here that he'd do a fork once
the code is matured enough. I sincerely hope that he will
change his mind and won't let this happen. The high
configurability of the KDE desktop has shown that it can
adapt to various different needs (novice and professionals,
Windows users and Windows haters, etc). Why shouldn't it
be possible to create an application which is good for painting
AND can be used for image editing, too? This would be a
big advantage for people who need both and shouldn't be that
difficult to realize (i mean in contrast to 2 different apps).
All the dulicated effort should rather go into higher
configurability. So IMHO a fork would be completely unneccesary.
But perhaps I got him wrong on that issue. Ignore my post
if that is the case...

He he, the German K-menu says: Bildbearbeitung (krita), so this means image manipulation.

I think must users in a world of digital imaging (scanners, photos) need a good IMP and GIMP2 is really good. I like it but I miss stuff like dcop, KDE UI and a more powerful scripting language, something like kommander. But functions like a channel mixer (LAB color code) and (for me as a photographer) Canon RAW-file support are there. I deeply miss stuff like 16bit/channel or grouping layers. That is not much and I know the Gimper are working on this and they still try to separate functions from GUI. So if krita steps in an wants to have early adopters, it should offer IMHO functions GIMP as not - like attaching a filter to a brush, thats cool stuff! If the aim of krita is (only) building a strict painting tool you will provoke many wishlist reports for krita ;-)

Cyrille Berger already added painting with filters to Krita. It's not perfect yet, but yesterday, Cyrille and Bart Coppens have been working on making it better. When I mentioned the possibility of soon having a 'sharpen' filter brush in Krita to a photoshop user he started getting really impressed.

By the way, Thorsten, would it be possible for you to make a couple of 16-bit raw images available? I don't have a camera that can produce them, and if I want to take a look at working on 16bit/channel capabilities, I need a few test images.

In other news, the zooming bug that's still in the preview is now fixed in CVS. I really tried to get that done before the packaging, but only last night I figured out what to do about it. Oh well, it'll be in this night's nightly package.

Yes, I know that I can attach a filter to a brush. And this is really cool stuff :-)

The Canon EOS RAW format has 12bit per channel but the great dcraw tool can change RAW into 48-bpp PSD (Adobe Photoshop) or 48-bpp PPM files. I can use convert to make a 16Bit tiff from the PPM. I will put in on a website and mail the URL to the mailing list.

/* Cyrille Berger already added painting with filters to Krita. It's not perfect yet, but yesterday, Cyrille and Bart Coppens have been working on making it better. When I mentioned the possibility of soon having a 'sharpen' filter brush in Krita to a photoshop user he started getting really impressed. */

What is really important is a easy framework for filters/plugins. This has to be seen as splitted from Krita development. Image mainipulators are used in image viewers, digital camery tools ecc. as well.

It is always superiour when developers are able to control their own ressources, see kde-look.org ecc.

I took a serious, hard look a GEGL when I first began Krita. GEGL just isn't done enough to do anything with; it looks a lot like a semi-abandoned second-system effect demo. Anyway, in Krita's root dir there's file called IMAGE_LIBRARIES with our assessment of a lot of image libraries currently available, and pro's and cons about their use.

It is not the "KIMP" simply because KIMP was a distinct project. KIMP's goal was to create a KDE GUI for GIMP, replacing the GTK+. But there was too much coupling between the GIMP and GTK. After all, GTK originally stood for "GIMP Toolkit". The situation may have improved with GIMP 2.0, but the KIMP project long ago fell to the wayside. Here's hoping Krita has a bright future...

But, seriously, nicely done, Bart -- and it's quite interested to actually see people their workflow. Seeing the way you handle the docker overflow, I wonder whether moving towards Kivio's dockers wouldn't be a good thing, at least for the way you work.

How did you capture them? I wouldn't mind seeing a few other other people work with Krita in this way. It should help streamlining Krita's UI.

We've looked into that, but in the end, kmdi is not compatible with KOffice, and Kivio's dockers are. Plus, kivio's dockers look & feel more like palettes than kmdi tabs that are mostly the whole length or height of their dock area.

Actions like image scaling take really much time.
For example the scaling shown in video 2 takes several seconds.

Maybe one should have a look at MPlayer which contains highly optimized versions of the same scaling algorithms as the ones Krita is using.

The scaling algorithms from Video2 is a Mitchel algorithm and Krita needed several seconds. MPlayer can do the same scaling with the same algorithm in ~ 1/100 second. (MPlayer supports all the other scaling algorithms, too)

There are still some, ahem, unoptimized bits of code. Especially the bits to access pixels are not all that optimized. But Michael and Cyrille are working on, are working on it. And, mplayer uses mmx and stuff, and we're still working in plain C++. No doubt we'll be all right on the night, and I'm really happy that we have such good quality scaling already.

I think the scaling code is quite efficient. Unfortunately the scaling code acceses the pixel data in a very inefficient way. This is what makes to code so slow. I think the code would be a lot faster if it would use iterators to access the code. Unfortunately the code now iterates over columns and not rows and to use iterators efficiently, the code has to iterate over rows. In prinicple it is no problem to rewrite the code, so that it iterates over rows instead of columns and use iterators to access the pixel data then. I hope this will speed up the code a lot, but I am not sure when I have time to do that. So if you like to participate, this is probably not a task that is too hard to do.
MPlayer probably uses some hand-optimized assembler code and I will certainly not try to code the scaling code in assembler.

> I think the scaling code is quite efficient. Unfortunately the scaling code acceses the pixel data in a very inefficient way.

MPlayer has some nice examples how to acceses the pixel data in a very efficient way, too. They try to avoid cache thrashing and so on.

> MPlayer probably uses some hand-optimized assembler code

That's true but it not only holds hand-optimized assembler code but plain c, too.

> and I will certainly not try to code the scaling code in assembler.

My point was: Mplayer has optimized C and assembler (x86 + some altivec code) versions of all your scaling algorithms. So should not "try to code the scaling code in assembler". Copy & paste should be enough. MPlayer's scaling filters do understand not only YUV but RGB32, too.

I don't think you are adequately aware of the vagaries of copy & pasting. Perhaps Michael could take ideas and algorithms from mplayer, but it's highly unlikely that it would be a simple matter of copying and pasting. Programming is more complicated than that.