First Krita Preview Release

Monday, 27 September 2004  |  Brempt

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:

  • Boudewijn Rempt (maintainer, stuff that doesn't work)
  • Sven Langkamp (GUI, especially the dockers & the color wheel)
  • Cyrille Berger (Filters, tools, core stuff)
  • Adrian Page (Painting, tablet support, gradients, core stuff, fixes all over the place)
  • Clarence Dang (zoom, shape tools)
  • Dirk Schoenberger (code cleanups, tool shortcuts)
  • Bart Coppens (Fills, previews, text tool)
  • Michael Thaler (Scaling, rotating)
  • Camilla Boemann (core stuff)
  • Daniel Molkentin (Packaging this release)

We really hope to keep up the pace, and make Krita part of KOffice 1.4, to be released near the end of the first quarter of 2005.

Comments:

more features - anon - 2004-09-27

Don't know what happened but the original announcement had more features listed: * Loading and saving of many image formats * Painting with Gimp brushes, generated brushes or text. * color picker, pencil, brush, airbrush, eraser, duplicate, filter-brush, lines, rectangles, ellipses and text tools. * Filling with solid colors, patterns or gradients * Selecting, copying (and pasting into Kolourpaint) * Scaling with one of five cool scaling algorithms * Image/layer rotating. * Adjusting brightness, contrast, gamma, color, saturation. * Working with layers (adding, moving, rotating) * Blur, sharpen, mean removal, emboss, edge detection, invert filters * Tablet support. * scan/screenshot image input * tool icon, crosshair or arrow cursors * grayscale and RGB color models (and a buggy CMYK model)

Re: more features - Anonymous - 2004-09-27

> Don't know what happened but the original announcement had more features listed: What original announcement? http://tinyurl.com/7xr28 doesn't have traces of above.

Re: more features - Boudewijn Rempt - 2004-09-27

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.

Small problem - Thorsten Schnebeck - 2004-09-27

Krita _is_ very promising. But using KOffice-CVS I have since some time a problem: I can not load bitmap files :-/ bash-2.05b$ krita /home/schnebeck/EOS/Test/IMG_0236.JPG kio (KSycoca): Trying to open ksycoca from /var/tmp/kdecache-schnebeck/ksycoca koffice (lib kofficecore): kritapart.desktop found. kio (KTrader): KServiceTypeProfile::offers( KOfficePart, ) kio (KTrader): Returning 11 offers kio (KTrader): KServiceTypeProfile::offers( Krita/CoreModule, ) kio (KTrader): Returning 0 offers koffice (lib kofficecore): KoDocument::openURL url=file:/home/schnebeck/EOS/Test/IMG_0236.JPG koffice (lib kofficecore): kritapart.desktop found. koffice (lib kofficecore): KoDocument::openFile /home/schnebeck/EOS/Test/IMG_0236.JPG type:image/jpeg kio (KTrader): KServiceTypeProfile::offers( KOfficePart, ) kio (KTrader): Returning 11 offers koffice (filter manager): KoFilterEntry::query( ) kio (KTrader): KServiceTypeProfile::offers( KOfficeFilter, ) kio (KTrader): Returning 64 offers koffice (filter manager): Filter: KOffice-Export für XSLT doesn't apply. krita: No decode delegate for this image format (/home/schnebeck/EOS/Test/IMG_0236.JPG). koffice (lib kofficecore): KoMainWindow::addRecentURL url=file:/home/schnebeck/EOS/Test/IMG_0236.JPG koffice (lib kofficecore): [KoMainWindow pointer (0x8234ca8) to widget krita-mainwindow#1, geometry=1222x726+50+207] Saving recent files list into config. instance()=0xbfffef88 kparts: Part::~Part 0x822b478 kdecore (KLibLoader): The KLibLoader contains the library libmagickimport (0x8290d10) kdecore (KLibLoader): The KLibLoader contains the library libxsltexport (0x82bd360) kdecore (KLibLoader): The KLibLoader contains the library libkritapart (0x81e0bc0) 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 :-) Bye Thorsten

Re: Small problem - Boudewijn Rempt - 2004-09-27

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.

Re: Small problem - Thorsten Schnebeck - 2004-09-27

... works after recompiling ImageMagick and KOffice :-) (A little bit slow with a 3000x2000 pixel bitmap on a 1GHz Athlon) Bye Thorsten

Re: Small problem - Boudewijn Rempt - 2004-09-27

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.

KIMP - Martin - 2004-09-27

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...

Re: KIMP - mikeTA - 2004-09-27

I'd second that, and include myself amongst those who hope that Krita will become a GIMP replacement, and I also think this is how it will be seen.

Re: KIMP - Birdy - 2004-09-27

KIMP was the name of the idea to make a KDE frontend for GIMP. But as Krita does not share code with GIMP, the name is not suitable. Krita is neither a port nor a frontend of GIMP.

Re: KIMP - Thorsten Schnebeck - 2004-09-27

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 ;-) Bye Thorsten (rebuilding KOffice with a new version of ImageMagick)

Re: KIMP - Boudewijn Rempt - 2004-09-27

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.

Re: KIMP - Thorsten Schnebeck - 2004-09-27

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. HTH Thorsten

Re: KIMP - Gerd - 2004-09-27

/* 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. A plugin bazaar, this is what we need.

Re: KIMP - oliv - 2004-09-28

>I like it but I miss stuff like [...] a more powerful scripting language Hey! Gimp supports Script-Fu, Perl and Python! Do you really mean Python and Perl are not powerful scripting languages?

Re: KIMP - testerus - 2004-09-27

Well, there is still room for an application based on GEGL, isn't it? http://www.gegl.org

Re: KIMP - Boudewijn Rempt - 2004-09-27

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.

GEGL - Leon Brooks - 2005-06-17

For your general information, GEGL development has been restarted as of about a month ago. They're about finished pulling off the cobwebs and blowing out the dust now.

Re: KIMP - Brandybuck - 2004-09-27

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...

compile problem - Stephan - 2004-09-27

krita: .. make[4]: Entering directory `/opt/krita/krita-preview1/krita/ui/dialogs' if /bin/sh ../../../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I./.. -I./../../core -I./../../core/tool -I.. -I -I/opt/kde3/include -I/usr/lib/qt3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -O2 -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL-DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT wdgmatrix.lo -MD -MP -MF ".deps/wdgmatrix.Tpo" \ -c -o wdgmatrix.lo `test -f 'wdgmatrix.cc' || echo './'`wdgmatrix.cc; \ then mv -f ".deps/wdgmatrix.Tpo" ".deps/wdgmatrix.Plo"; \ else rm -f ".deps/wdgmatrix.Tpo"; exit 1; \ fi wdgmatrix.cc:1:21: kdialog.h: No such file or directory wdgmatrix.cc:2:21: klocale.h: No such file or directory wdgmatrix.cc:17:23: knuminput.h: No such file or directory wdgmatrix.cc: In constructor `WdgMatrix::WdgMatrix(QWidget*, const char*, unsigned int)': ...

Re: compile problem - Boudewijn Rempt - 2004-09-27

Are you really sure you do have the kdelibs headers installed?

Re: compile problem - Stephan - 2004-09-27

yes. /opt/kde3/include/kdialog.h my config option: ./configure --prefix=/opt/kde3 hmh..

Re: compile problem - Boudewijn Rempt - 2004-09-27

Strange... Other KDE applications do compile?

Re: compile problem - Stephan - 2004-09-27

yup

Re: compile problem - Nicolas Goutte - 2004-09-27

Try to change koffice/krita/ui/dialogs/Makefile.am There is a line with libkisdialogs_la_METASOURCES = AUTO try to replace it with only: METASOURCES = AUTO (As far as I know, the library version of METASOURCES = AUTO is not supported anymore.) Have a nice day!

Re: compile problem - Stephan - 2004-09-28

the same problem.. :( The difference is in output: missing automake-1.7 but automake 1.8.x is installed! ln -s /usr/bin/automake /usr/bin/automake-1.7 fix this output but not the compile prob..

Re: compile problem - Nicolas Goutte - 2004-09-28

Ah, yes, sorry. I had not thought about the problem that you have to re-create the Makefiles. So if you have a different version of automake, it will not work. Have a nice day!

koffice? - Peter Robins - 2004-09-27

. . . make Krita part of KOffice 1.4 . . . why KOffice and not kdegraphics? isn't this graphics software?

Re: koffice? - Boudewijn Rempt - 2004-09-27

Because it's already a KOffice application, and has been one for five years.

goddamn cool video of Krita - KDE User - 2004-09-27

I don't know why this damn damn cool video isn't in the announcement but check this out: http://linuxreviews.org/news/2004/09/27_krita_kde_koffice_preview_available/ http://linuxreviews.org.nyud.net:8090/news/2004/09/27_krita_kde_koffice_preview_available/krita.mpeg

Re: goddamn cool video of Krita - Bart Coppens - 2004-09-27

Apparantly that site has been slashdotted, so here are the links to the originals: http://www.bartcoppens.be/krita.mpeg http://www.bartcoppens.be/krita2.mpeg

Re: goddamn cool video of Krita - KDE Fan - 2004-09-27

What video format, both xine and mplayer (recent versions) choke on the second (recommended) video.

Re: goddamn cool video of Krita - Boudewijn Rempt - 2004-09-27

I never knew about it... Nobody ever tells me anything. Pout. 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.

Re: goddamn cool video of Krita - Bart Coppens - 2004-09-27

This way of using the dockers gives me a bit more free space, so I have a better view of what I'm doing. And this way I could also resize krita somewhat in order to make the download not too big. The capture tool I used is xvidcap: http://xvidcap.sourceforge.net/

Re: goddamn cool video of Krita - Boudewijn Rempt - 2004-09-27

Cool -- with the next release we must do something like that again. Have you looked at Kivio's dockers?

Re: goddamn cool video of Krita - Bart Coppens - 2004-09-27

Not yet, but I'll have a look.

Re: goddamn cool video of Krita - Boudewijn Rempt - 2004-09-27

Make sure you give them a chance to disappear and appear automatically. The dockers are not entirely bugfree, so they may need a bit of nudging now and then.

Re: goddamn cool video of Krita - Michael Thaler - 2004-09-27

Can Krita not use KMDI? I really like the Ideal modes where the widgets hide automatically after you clicked on them. But KMDI also allows you other modes.

Re: goddamn cool video of Krita - Sven Langkamp - 2004-09-27

KMDI would be cool, but Krita is limited through the KOffice framework.

Re: goddamn cool video of Krita - Boudewijn Rempt - 2004-09-27

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.

Re: goddamn cool video of Krita - Bart Coppens - 2004-09-27

They look very nice, but I didn't see them appear or disappear? Is this maybe a feature that's only in CVS and not yet in 1.3?

Re: goddamn cool video of Krita - Boudewijn Rempt - 2004-09-27

I wouldn't know, it's been a year and a half since I ran a non-CVS KOffice. I'll ask Peter Simonssen.

Speed - Asdex - 2004-09-27

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) http://www.mplayerhq.hu/

Re: Speed - Boudewijn - 2004-09-27

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.

Re: Speed - Michael Thaler - 2004-09-27

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.

Re: Speed - Asdex - 2004-09-27

> 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.

Re: Speed - Boudewijn Rempt - 2004-09-28

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.

Re: Speed - joe lorem - 2005-03-06

Wait, you can't just copy and paste code between systems and have it work? But SCO said you can! They were lying? I'm selling my shares right now!