Category: KDE


Krita’s Hackfest, meeting with the Blender guys

Filed Under: KDE, Krita, Open Source
Mar.05, 2010

During this week, Boudewijn is hosting Sven, Lukas and me for a Krita hackfest, dedicated to bug fixing, performance, UI improvement. Among the major improvements brought by that week are improvement in the memory consumption, thanks to a collaboration between Dmitry and me, where I did some tracking and experimentation, and he found the actual problem. This fixed has allowed us to go from 2 minutes of drawing to exhaust my 2GB of memory, to make it possible to paint for more than 30 minutes, there are still some issues that need to be found and fixed. In the area of performance, Lukas have improve the performance of the flood fill by 60%, and I have reduced the time needed for some gradients by six (the other types did not seem to have the problem), unfortunately those improvements are not really visible, for some reason Krita currently spend a lot of time recompositing the image. While Boudewijn and Sven have been working on a scratchpad, as a new way to test new brushes settings, and working on a widget to input value that should be simpler when used with tablets, after Boudewijn’s call for help someone else has offered to help us with that.

Yesterday we went to Amsterdam to meet the Blender’s guys. Since most of us has never been to Amsterdam before, Boudewijn took us for a long walk in Amsterdam’s street (or should I say canal), which started in the overcrowded area around the central station, that we left as soon as possible to walk in more quieter area:

Then at the end of the walk we arrived at the Blender institute:

Where Ton took us on a visit of the Studio, and then we assisted to their weekly update, where all the members of team show what they have been working on, their difficulties and how to solve them. After the meeting, we went to a restaurant, as an opportunity to know each other, and to learn more on how their work, and in hope that one day Krita can be useful for them.

Tomorrow, I will go back home in Göteborg.

Tags: , , ,
read more

The difficult choice of removing features

Filed Under: KDE, Open Source
Mar.02, 2010

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.

Tags: , , ,
read more

Krita Meeting 2010 – Day 2

Filed Under: KDE, Open Source
Mar.01, 2010

Yesterday was the second day of the krita meeting 2010. It was oriented toward technical discussions, and UI design discussions.

In the technical area, I and Dmitry had a long talk on how to improve the filter API, to make it both easier to write effect filters, retain performance and ensure that it is less buggy with respect to selections and masks. In meantime Lukas was teaching Vera how to implement new painting operation, so that she can work on a water color brush engine.

When it came to the UI, we talked about what to do with painting op presets preview, and it was decided that it would be more useful for the user to have a scratchpad where he can make his own testing of the current settings, rather than having a computer generated preview. Boudewijn is now working on implementing exactly that. We also discussed painting presets management, it is going to be very basic for 2.2, with just a list name and a preview (either computer generated or made with the scratchpad). And later we would like to have tags, search by tags.

And between two discussions, we were working on bug fixes, polishing features, etc… All the small details to make Krita an even better application. And now is the hack week, with Boudewijn, Lukas, Sven and me.

Tags: , ,
read more

How to find where an exception is emited with Qt ?

Filed Under: KDE, Open Source
Feb.24, 2010

When an exception is thrown and not catched in a Qt application, it get catched by Qt’s event loop, and the following message is displayed in the console:

Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

In other situations, std::bad_alloc is replaced by the name of the exception. The problem is that if you now want to know where it happens in your program, the backtrace points to where the exception is rethrown by Qt’s event loop, which is not where the error happens.

I first had this problem a few days ago when implementing multi-layers support in EXR, since the exception name was specific to OpenEXR, I just grepped the code and deduce where the error occurred. But this is not very convenient when the error is generic, like std::bad_alloc which can be thrown just anywhere. And as it turned out by Qt itself in ‘qBadAlloc()’. The solution suggested by Maelcum on IRC is simply to set a breakpoint in the function __cxa_throw, which is a function of the C++ standard library that is actually doing the job when the keyword throw is used (at least with the GNU stdlib++, no idea if it is valid with other standard library implementation). And then you get a backtrace that point to the problem.

I thought I would share this tip in case, in some day, you find yourself with an uncaught exception in a Qt application.

Tags: , , ,
read more

Inserting shapes/images in KOffice

Filed Under: KDE, KOffice, Krita, Open Source
Oct.21, 2009

A while ago, in a praise of karbon 2.0 I wrote, someone commented on the “lack” of tools in karbon, as opposed to inkscape. And from forum posts, or identi.ca, it seems to cause some confusions. For instance, there is no rectangle or circle tool in karbon. And there will never be. The reason is that for KOffice 2, the tools are meant for user interraction, and for manipulating object in the canvas. Inserting shapes is done through the “Add shape” docker, which allow to manager your collection of customs shapes, as well as standard shapes, you can then just drag and drop the shape, or select a shape and then by clicking and dragging on the canvas you can select the size of the shape like with a tool. Once the shape is on the canvas you can go to the toolbox and start having fun with your shape.

video of karbon adding shapes

And of course, since the technology is shared, you add shapes to other KOffice application in the same way. To add a text in Krita ? Go to the add shape docker, drag and drop, and enjoy ! To add an image to your presentation in KPresenter ? Go to the add shape docker, drag and drop, and enjoy ! To add a smiley to KWord… you get it !

Tags: , , , ,
read more

OpenGTL 0.9.5 and Darkroom 1.3

Filed Under: KDE, Open Source, OpenGTL
Sep.02, 2008

Today I am making a joint release of OpenGTL and Darkroom, for the main reason that I have made quiet a lot of bug fixes in OpenGTL that are needed to get a fully working Darkroom.

OpenGTL 0.9.5

Among the bug fixes, there are two major changes in this release

  • Start using llvm optimization, there is one thing that OpenGTL does very poorly, it is emitting assembly code, for instance, if you need to access three time a value, it will load it three time from memory… So enabling optimization give a significant boost in execution speed, unfortunately, I haven’t had the time to do some benchmarking, but I have noticed a siginificant improvement in applications (Krita and Darkroom) that use OpenGTL.

  • The second change, which took me longer to do correctly, is that conversion are now handled by the parser and inserted in the AST tree, instead of being assumed to be possible in the parser and triggering asserts in the code generation (previously MyStruct a; int b = 2 + a; would have aborted the program instead of reporting an error to the user). The other benefit of that change is that it makes possible to automatically convert from Shiva’s pixel structure to a vector.

    Before that change, the Blur kernel was looking like this:

    kernel Blur
    {
    void evaluatePixel(image img, out pixel result)
    {
    pixel v1 = img.sampleNearest( result.coord );
    pixel v2 = img.sampleNearest( result.coord - 1.0 );
    pixel v3 = img.sampleNearest( result.coord + 1.0 );
    for(int i = 0; i < 3; ++i)
    {
    result[i] = (v1[i] + v2[i] + v3[i]) / 3;
    }
    }
    }

    And now it is down to:

    kernel Blur
    {
    void evaluatePixel(image img, out pixel result)
    {
    result = ( img.sampleNearest( result.coord ) + img.sampleNearest( result.coord - 1.0 ) + img.sampleNearest( result.coord + 1.0 ) ) / 3.0;
    }
    }

Darkroom 1.3

The two main changes (yes I like to limit myself to the number 2) of Darkroom are:

  • This release introduce a levels widget, if you wonder how it is useful, I suggest reading Unai Garro’s Levels adjust tutorial.

  • Darkroom can now export to jpeg, when I first started Darkroom I considered that the only interesting export format would be Png, only to realize later that if one wants to export to a web gallery, jpeg is better suited

  • Bookmarks (yes that’s a third change, but I only remember about it when I did the screenshots for the levels widget), it’s now possible to save bookmarks of your favorite processing settings

Tags: , , , , ,
read more
Powered by WordPress. Theme: MyMotion by Cyrille Berger as a modification of Motion by 85ideas.