The difficult choice of removing features

Adding a new feature is usually considered easy in the open source world, and then it is taken for granted. Removing a feature, on the other hand, it is a different story. It is not about making Krita less useful, au contraire, it is about making the best for our vision. But why remove a feature, they don’t disturb, or take too much space. They still come in the way and clutter, and what is the point of a menu entry, if you are never going to use it ?

Krita is now focused on being a painting application

We have mentioned in our blogs entry (by me in Krita meeting 2010 – day 1 and by Boudewijn Rempt’s blog) on last week-end Krita meeting, that we had now decided for a vision oriented toward painting.

Where does that leave photography ? Well clearly, it is out. And honestly, between Gimp (especially with their work on 2.8) and Digikam, there is not really much room for an other linux photography application to prosper. Since Krita was always more oriented toward drawing and painting, and photographic features were available mostly because “we can”, and there is no high-end application for drawing and painting on linux, the logical conclusion, for us, was to focus on where we can be the best, and the most useful.

Removing photographic-specific features

The logical conclusion is to remove the features that are not useful for painting. This include many of the photographic plug-ins, like tonemapping, bracketingto-hdr, lens correction, noise reduction filters. As well as a set of artistic filters, but that are mostly useful to transform a picture in something that looks like a painting.

And anyway there are better tool for that job, like the excellent Qtpfsgui, in action below on Deventer’s mill:

I started a discussion on the subject on Krita’s mailing list, which triggered a bit of a uproar. Especially from people who have used Krita for photographic editing. Live with it, use Gimp or Digikam, or install the removed plugins from the future extension website, write your own, just do not count on us for that, we are going to be focused on other features.

An extension website

Since it would sadden me to kill forever some of those plug-ins, and also while we do not want to support photographic features, or features that are of no interest for painting, we also do not want to prevent people to have or use those features, they will simply not be part of the default distribution. We are going to setup a new website where those extensions will be hosted, hopefully with “nightly” build (more like regular build) to keep them buildable, and synchronized with git/hg, where a tag would trigger a new release automatically. In essence a revival of the krita-plugins project.

This entry was posted in KDE, Open Source and tagged , , , . Bookmark the permalink.

40 Responses to The difficult choice of removing features

  1. aa says:

    I think it is a wise choice.

  2. AdeBe says:

    Wow, could You please post a link to this photo? It’s amazing.

  3. Mark Purcell says:

    Why not support the kipi-plugins in krita, which are already supported by digikam, kphotoalbum and gwenview.

    You could then move any photographic features which are not core into the kipi-plugins, where they can be used by many photo-apps and those that wish photo extensions for krita can access them..

  4. tidbeck says:

    Must say, a very brave and correct choice.

  5. You should check out the concept of “task sets” ( Optimally the users should be able to construct and share them via some web service. I think that would be a nice step beyond just a standard plugin system and perhaps something worth pursuing especially considering the communal aspect of open source projects.

  6. Yuriy says:

    Are most of these features not KIPI plugins that can already be used in Digikam/Gwenview? If not, could they be ported? Does Krita currently support the KIPI plugins used in Digikam and Gwenview? (Haven’t tried it in a while) If the photography specific plugins are simply disabled so they don’t show up in the menu, could there be an easy way to enable them?

  7. blueget says:

    That’s very sad – Krita’s interface is so much better than GIMP’s IMO…

    I would have loved to use all the nice brushes and stuff for better photo editing, but I have no use for a painting-only application, and I don’t see the point in going through a tiresome orgy of installing plugins.

    Just that YOU aren’t using some menu entries doesn’t mean that nobody uses them, but if you are keen on upsetting and/or losing users, testers and developers removing them is the way to go.

  8. Tommi.S says:

    Small edit ;). The name is digiKam and not Digikam. And digiKam has the Qtpfsgui in it. So you do not need to use external application for that if you use digiKam itself.

    I think you are doing great choice. Let the Krita be #1 in painting/drawing. And digiKam in photographing area. While Gimp being a manipulation program (while digiKam is just for photographers for edits, not for manipulations).

    And if you keep plugins possibility available, mayby there would grow a new sub-project to support new features for photographers as well.

  9. Victor says:

    I do not agree that this is ok.

    Krita is part of KOffice – being a tool that helps in every work day in an office or home.
    That means that if Krita is now focused on only drawing it shouldn’t be part of KOffice (not default, maybe additional), and there should be started another project for photo editing which will replace Krita in KOffice.


  10. anon says:

    Perhaps a satisfying solution for both sides would be to have another frontend to Krita respectively its backend which focuses on editing and photography related features. This way those who are interested could work on a different program with a different vision, interface and name, but still you could be sharing most of the code needed to make both kind of programs run.
    Could be as simple as another gui with a different kind of toolbox. This way cutting features in Krita wouldn’t be that bad, you could point users to this other interface and wouldn’t need to constantly argue against readding certain features to Krita itself.

  11. maninalift says:

    If supporting these features would distract developers from their other work then it seems like a good decision.

    However, if the developer work is not great (e.g. though using kipi plug-ins) I don’t think that from a UI point of view the features should be dropped. They can be placed in a single menu entry.

    There is no reason these sorts of filters shouldn’t be useful in digital painting (surely that is part of the reason for not doing conventional painting).

    Featureful need not have confusing menus, just look at KDevelop (winner of my “best menu structure” award).

    The other reason I see for not including kipi plug-ins is the time they take to load, but perhaps (?) they could be loaded on first use rather than start-up or loading plug-ins could be a non-default option.

  12. René says:

    I must say I’m disapointed and I don’t see the point of such a limitation.

    I understand that you don’t want to implement features that digikam have – which isn’t necessary because of the kipi-plugins. But limiting Krita to painting while it has already many features of an image editor doesn’t make sense to me. Espacially because Krita has the UI of an image editor and not of a good painting application.

    If you say Krita focus on features to create art I would be very happy with that. Art could be painting, collage, distortion and many other things. Some artworks are made with brushes, others not. And limiting the artist to a specific tool set might make the artist use another tool to create art.

    If somebody starts another KDE application for image editing it might look like Krita looks now while Krita will look like Painter then?

    As I said, I don’t see the point.

  13. Michael Thaler says:

    Being the one who started the uproar on the mailing list I want to say that I just misunderstood your announcement: I thought you wanted to remove artistic features because they are not useful for photographers. I totally agree that Krita should focus on being a paint application. There is no point in creating a gimp clone and I think a paint application is much more exciting anyway. Thanks for clarifying.

  14. Victor says:

    >I do not agree that this is ok.
    >Krita is part of KOffice – being a tool that helps in every work day in an office or home.
    >That means that if Krita is now focused on only drawing it shouldn’t be part of KOffice (not default, maybe additional), and there should be started another project for photo editing which will replace Krita in KOffice.

    I take my words back. I also misunderstood you. I thought you are removing features related to editing photos. But you are removing things for photographers.

  15. Cyrille Berger says:

    Yes this is the important point, we remove features that are not useful to painters. There is a lot of overlap, like blur, color adjustments, etc… which we are going to keep.

  16. goom says:

    I disagree since i was expecting so much of Krita to get rid of Gimp for image manipulation, i consider KDE libs and qt4 much better than gtk (i really hate the window to open a file in gtk apps) and also i would have loved to try to get a KDE desktop as complete as possible

  17. nicodev says:

    While I support the idea of having a top-notch paint application, I’m a bit uncomfortable with the move. Let me explain why.
    While I love digikam and use it as my primary image editor and collection browser, it has a clear limitation : there is no concept of masks and layers, which you need as soon as you want to go further than basic, whole-image editing. That’s where I was expecting krita to fill the gap with its extensive infrastructure.
    Sure, there is always the gimp as alternative, but for some reason I feel sad that krita is moving away from that; I had the feeling it was so close to allowing high-end photo retouching, and a all-in-one koffice solution would definitely have my preference. I actually remember a post stating that a couple of Photoshop tutorials could be done with krita: why give up on that? Even though nobody can nor will force developers to do something they have little or no interest in, saying so loud that photographic retouching is no longer the focus and dropping stuff that serves it is not really encouraging for a photography-community to thrive around krita in the future, possibly with new contributors.

  18. blueget says:

    But Painting and Photographing are often not that seperate: for example many people take pictures and then convert them to a painting or something similar. These People (at least the ones I know) like to have ONE application for first doing things like distortion/vignetting correction or denoising and then doing the painting, partial correction etc. Photoshop does this, not perfect but good enough for most, GIMP tries to but is still way too limited. Digikam/KIPI-Plugins can’t do layers, partial correction etc. and generally lacks painting features. Krita looked like being on a good way, but I guess this is history now… Very, very sad.

  19. Luca says:

    Just leave the user the choice of what is useful and what is not.
    KDE does NOT have a good tool to edit photos, we hoped Krita would finally allow us to get rid of GIMP and use a native KDE version. There is no reason to remove this kind of features, just put them in their own menu if you want (for some unknown reason) distinguish between the two uses of Krita.

    Frankly, one of the reasons why i avoid Gnome, is that their developers want to know what’s best for their users, removing functionalities that in their opinion are “too hard” for their users. I understand that this is not the reason here, but the underlying effect is the same. You want Krita to be used only be painters and so you decided to remove useful features that could make Krita good even to others… this does not make sense. Let’s take a look at Photoshop… many painters use it, but also many other persons who are only interested in photographic effects. If Krita can be useful for both categories why not making it useful for both? Why consciously decide to make it less useful and limit its own userbase?

    Why do you think that there is no reason to incorporate functions used in GIMP? I tell you, if i could uninstall GIMP in favor of Krita I WOULD, and so would many other persons. Not only to have the same look and feel of KDE applications, but also because, frankly, it has an ugly interface. Now you have the chance not only to “make a clone of GIMP”, but even to make a BETTER software than GIMP is… but you want to renounce to this because you decided that Krita must be useful only for painter.

    It really makes no sense at all.

  20. Andreas_P says:


    Hey everybody. Yes it could be true that there’s no real good photo-edting application
    for KDE SC…(4). But think again: Do you’ve ever heard of a tool what’s called: FilmGIMP???
    If not, I can assist you: It is a tool from Hollywood “after-effects” animation and revision what has been transformed into the CINEPAINT project for
    everybody who wanted to use 32bit color depth natively… (meanwhile GIMP is improving a lot, but for the time when GIMP hat that version number, nothing of that stuff could be seen around the corner!… Think about FilmGIMP (CINEPAINT) and what you could do with KRITA (as a codebase fork!) Don’t complain; rediscover and innovate! over and out. andreas_p

  21. Congrats for this brave (and hard) decision!
    I think you’re doing the right thing here.

  22. Hanna says:

    I think you are doing the right thing. If one does not focus an application it ends up like Microsoft Word. There is at least one good open source tool for photo editing already and there is a lot to be gained from having a good painting application.

  23. John says:

    Good choice. I’d rather have two excellent specialized applications than two mediocre and overloaded ones doing the same things.

  24. Jonathan says:


    I’m very sad about your decision.
    KOffice is great because it does not try to be like MS Office (that is why OpenOffice is bad) and Krita is great because it does not try to be like Gimp.
    I know that Gimp is more powerful for phtographic work, but Krita provides a great interface, great layer-management and a great plugin-structure at the cost of a couple of filters which are not implemented. You tell the people they should use digiKam which provides a nice interface for Qtpfsgui, but on the other hand you tell them they should use Gimp because it is most powerful. Compare it to a (im)possible Kate scenario: The Kate-developers want to focus on features related to writing books. They do some interface improvements for that and after a few months they say: “Hey, we will remove the useless syntax-highlighting, but of course you can still use Okteta (the hex-exitor) with its great interface or the powerful vim!”. That does not make sense. Developers want to use Kate as a Text-editor and Photo-artists want to use Krita as their tool of choice.
    Well, most features can be used by painting- and by photo-artists. So I beleive that there will be still a lot of photo-artists using Krita. There are always features somebody does not need, but they do not make the UI complicated. So they should be kept, because they are useful.

    The User

  25. Melchior FRANZ says:

    I had also hoped that krita would become KDE’s answer to GIMP (not a “clone”), something that’s as good or even better, and doesn’t rely on annoying Gtk but on superior KDE libs. But with the loss of non-painter stuff it looks as if krita is about to become an application for painters only. And lets face it, that means: for people owning a graphics tablet. Better rename it to ktablet then, and remove it from koffice. There isn’t much painting going on in offices. Sigh. Back to GIMP, then.

  26. n-pigeon says:

    I think it will help in faster Krita development. Good decision.

  27. Sinok says:

    Reminds me of the following reading.
    Some here should be reading a bit better Cyrille blog entry, and have an eye on the link I give instead of ranting for the sake of ranting.

  28. Kevin Kofler says:

    IMHO this really makes no sense. Digikam is not an adequate replacement because it doesn’t offer the painting part. You can’t even hand-edit a few broken pixels in it. People wanting to edit photos would end up having to use BOTH Digikam and Krita, switching back and forth, a really unpleasant experience.

  29. damian says:

    I Think “make one thing and do it right” is the best choice BUT Koffice should be a basic office suite with: document, spreadsheet,presentation (also database and extras) and image manipulation, under the last category there are lots of different use cases that require different approaches:
    Vector images : karbon14
    Raster images : maybe in this place there could be 3 apps closely related and maybe even redirected from each other (having an edit button in krita for when your paint/sketch is over and want to give some extra touch)
    These 3 apps should be:
    krita: proffesional sketching and painting.
    App 2 : proffesional editing (maybe this could be digikam but it would be nice if there was a koffice image editor program so digikam could concentrate on being a good tool for managing collections and photographs specific tools.Also if digikam was to become App 2 it should have layers which would criple the gui).
    App 3 : Simple netbook-fitting painting,sketching, and editing app.I think this third app is necessary because koffice in general should not be meant for professionals only.

    And maybe koffice in kde distros from default should only come with App 3 and maybe karbon14

  30. Cyrille Berger says:

    Good reading, on an other graphic application that have the problem of trying to be the jack-of-all-trade:–wanna_see.html

  31. Pingback: Links 3/3/2010: CrossOver 9.0, Android 2.1 | Boycott Novell

  32. nidi says:

    Good decision – makes perfect sense. As long as the program is still easily extendable which I read it will be, it’s possible to allow the krita-as-photo-editor-community to maintain the extension plugin.

  33. The more I read, the more I believe you guys are really starting to get it.

    The ‘old guard’ will likely cause you much grief, but you folks stand to make a huge dent in how to accomplish things in Free Software.

    Everything I read, from Peter’s ability to get you to making hard decisions, to the even more difficult ‘removal of features’ just speaks to the team’s ability to seriously engage design thinking.

    Keep the up the fight. Now you only have the even more difficult task of executing things.

  34. Pingback: Krita Hackfest 2010 « Sven’s Blog

  35. Pingback: Why GIMP is Inadequate :: Librescope

  36. aveilleux says:

    “Do one thing and do it well.” -The UNIX philosophy

    I am emboldened by your decision, and I hope that other developers follow suit. Keep it up.

  37. Danas says:


    While I like GIMP it doens;t support 16bit color.
    Is there any way there could be Krita Photo Pro fork?
    I wish I was able to do the programming stuff and so on, unfortunately I can only edit photos and be a designer. I wish to use Linux and Linux tools. While GIMP is amazing and has many good features and 2.8 version is heading the good road, it still is far away from having as good interface as Krita. Could someone consider making a fork for professional photo editing of Krita? It will not hurt to have more tools on Linux. The more options to choose from the better. It doens’t mean that it will interfere with GIMP, it will only make Linux be more attractive to the market. That are my thoughts. But congrats on having a concrete goal and good luck reaching it!
    Kind regards,

  38. Cyrille Berger says:

    Sure, the problem is to find developers to work on a Krita-For-Photography user interface and features.

  39. Alexis says:

    Focusing on a specific tast may defntively improve the software performance, but I absolutely disagree with your decision. I’ll start with a personal exemple, I’m using blender, and I get really excited by the development environment around this program. Doing 3D implies being able to manipulate and composite 2D images and the only thing that prevents me from switching to a fully linux based environment is the abscence of a serious image editing application. That is why I’m stuck with win7 and photoshop, sadly. I think that many people happen to be in my situation and especially professionals who can contribute economically and with their precious know how to a online community. I recently switched to Kubuntu hoping to port my 3D and photoediting workflows to linux. But seeing that an application which is able to handle 32-bit float data, which has adjustment layers, color management, blending modes, shape layers and a tonn of other features much smarter than phtoshop just gives up on opening towards a wider public makes me sad.

    Inspite of the sadnes I just want to bring up two exemples:
    Photoshop: It’s an old style application with all of the limits of a modal architecture, slow development and it’s commercial nature but for now it offers the possibilities for both a solid photographic, compositing AND drawing workflow. It’s just a matter of working space, if it can provide for an excellent image editing workflow why on earth should it prevent the users from using it for drawing. For krita it’s just the opposite.

    Blender: blender is building it’s way towards becoming the leading 3D graphics application, it has a fervid community, clever and generous sponsors. Blender today integrates features for which one must use at least 5 commercial softwares in a single well integrated workflow. What I would once be doing with Premiere, 3d studio, nuke, zbrush and PFtrack I can now be done with just a single software. I’ll soon be holding a worshop in my university on landscape video and I’m seriously considering to put blender as the main application for video editing. Blender at some point will integrate a complete set of features to allow for image editing workflow and eventually will overcome gimp and krita as he now integrates a complete compositing toolset needed to post process renderings and images in general. If those applications will not set up a friendly environment for those doing advanced image work like RAW developement, compositing, image manipulation and painting they will become redundant.

    I really tried to use gimp and was very positive about it’s interface arrangement but being unable to use high bit depth and having to duplicate an image layer to recreate the illusion of doing a non destructive editing just leaves me with the feeling that I’m constantly doing something wrong, something incorrect. That I’m posterizing gradients, that I’m loosing information that I’m producing redundant pixels. Maybe it’s just a personal opinion but gimp is not a photoshop substitute as for now. And probably it will remain such for at least few years considering that it has a comunity that isn’t oriented towards a blender-like development. Gimp development community lacks the midle-ground developers, people who sand in between uber leet programmers and common users or even advanced users who may want to give a try to python or GTK+. That is why it has so few developers and thus struggling to produce new releases. All the people who do not come from a programming background and may well be willing to contribute are excluded and demotivated.

    Sorry for the long response, I hope that my opinion is not offensive to anyone and analyzes facts rather than inventions.

  40. Michael O. says:

    Dear Developers:
    Could you put back all photographic features of Krita?
    Please listen to the End Users and Community and don’t be like the Gnome Devs, they don’t care about End Users and Community needs for that reason Gnome DE is useless.
    I always use Krita because it is simpler than GIMP, I like it a lot.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>