Archive for the ‘Krita’ Category

How to fix Krita on Ubuntu

March 16, 2013

We recently had a lot of problems with Krita running on Ubuntu. So here is the up-to-date of list of things that you can do to fix your Krita experience on Ubuntu.

  1. Use proprietary graphics drivers. As I pointed out before there are some problems with LLVM and the drivers, which haven’t been fixed so far.
  2. Remove the qt-at-spi package The something broken with the package that causes crashes in the save dialog in some applications (bug here).
  3. Change the theme. The default theme Ubuntu uses for Qt applications is broken. Plastique and Oxygen themes are working better.

Calligra Sprint 2013

March 16, 2013

Last weekend I have been taking part in this years Calligra sprint, which once again was at the Linuxhotel in Essen. This year we had something special as the sprint was actually happening in two places at the same time. While one part of the team was in Essen, the other part of the team meet in Bangalore. This was simply due to the problem that we could only fly a limited number of people around the globe. Both meetings were connected via Google Hangout which worked reasonably well, except for some microphone problems. Another nice additions was that we also had a kitchen, where Thorsten and Arjen cooked lots of pasta and sauces.

Calligra track

Most of the time in the general Calligra track was spent on discussing upcoming changes and technologies. With many new upcoming Qt 5 mobile plattforms the mobile Calligra version are getting more and more important. For Calligra as a whole we have to change the way how we integrate the UI with the rest of the applications and which libraries we want to use or not use.

One of the big technologies that that KOffice 1.x was build around is KParts. It was used to embed documents into other documents, to embed the application in Konqueror and much more. Over time many of these usecases have been solved differently or are becoming far less common than they used to be while at the same time it has been making more and more trouble. So our long is to replace KParts in the future. As a one possibility to a new framework Friedrich presented his Kasten framwork. Altogether this will need a lot of time to complete, but will result in a much better architecture.

Beside these big topic there are were many smaller discussion around topics like QML user interface, more focus on testing and an a development process where we created stable snapshots of the master branch. There are also some interesting developments on things annotation and docx export.

A bit sad was the discussion around unmaintained applications. After some maintainers got busy with life recently some application are unmaintained and see no further development at the moment. This is not a very surprising development as we have been working with a bus factor of 1 for years on these applications. Affected by this are Karbon, Plan and Braindump. We decided that for now the applications will get a splashscreen that informs about the unmaintained state, but still stay as part of the official release. Unless new maintainers step up, these application look towards an uncertain future.

Krita BOF

Beside the Calligra discussion we also had a BOF with the Krita developers, which actually took place over all three days. Krita development is running really well and we are more and more popular in areas outside the usual open source community. Boud reported about presenting Krita Sketch at Mobile World Congress and some news from the VFX world. I did already know that Krita was used in visual effects, but so far didn’t know on which movies Krita was used. So it was exciting to hear that Krita was used in production on the upcoming G.I. Joe movie.

On Friday we discussed the main areas which we want to improve in the coming time. The included a better support for Windows and Mac OS, a new OpenGL ES canvas to replace the current OpenGL canvas and lots of smaller improvements. We want to port to Qt 5 as soon as possible as it offers solutions for many these issues. Unfortunately KDE Frameworks is still in the works, so it will take some time.

Beside that I designed the new operation system with Dmitry and Lukáš. The main purposed of that is to separate the UI and operation code in Krita. Instead of connecting everything the old way, we let the application figure out which UI to show and which operation to execute. Instead of signals/slots we use use settings objects to communicate between UI and application. This approach has several advantages: The code becomes more modular, different UIs can be added easily by plugins e.g. for QML interfaces and it can be recorded for macros.

On Sunday I and Boud went through the Krita crashes in Bugzilla and did some cleanup there. Having two different systems and people check at the same time was really productive, as sometimes I could produce other problems on Kubuntu than Boud on OpenSuse and the other way around. For example we found a crash with the Ubuntu jpeg library which didn’t happen on OpenSuse. Altogether we were able to resolve 14 crash reports.

Finally I want to thank KDE e.V and Friedrich for making this sprint possible. Many thanks also go to the cooking team.

More Krita 2.7 features

January 4, 2013

Recently Boudwijn presented his vacation work on the flipbook and smoothing feature. He wasn’t the only one having fun hacking new Krita features. I’m presenting you some of the new features that I developed in the last few days.

Freehand path tool

First feature I worked on was the “Freehand path tool” (Not the best name, I might rename that if I find a better one). Krita users might already know the old Pencil tool that came from Karbon and could also be used in Krita for vector graphics. One of the shortcoming of that tool was that it so far couldn’t use Krita brushes, which confused some users.

To solve that I created a the new tool which internally reuses the pencil tool and uses the painting capability of the path tool. With the result that the new tool can be used on pixel and vector layer. When painting on pixel-based layers Krita will paint with the current brush, on a vector layer it will insert a shape.

One might wonder why this is a big deal compared to the already existing freehand tool. The interesting feature of this tool is that the complete stroke stays a path until it’s finished. This allows some nice post-processing steps e.g. it possible to smooth the stroke much more than the freehand tool can while painting. Small downside with the is that it doesn’t use brush dynamics.

The screenshots below show an example with my mouse path and the resulting smooth stroke painted with a Krita brush (I cranked up the smoothing, so it a far more aggressive smoothing than one would usually use).

smooth3

smooth4

Painting any shape with Krita brushes

Almost immediately after I had done the Freehand path tool, I got the next request. If we can stroke any path path shape with Krita, why not add the functionality to do it with all shapes? I thought that would be pretty easy to do, turned out it needed some tricky coordinate transformation. But I finally got it working an the result is quite fun.

In the screenshot below you can see a flower shape that I let it paint with the pixel brush:

flower

Also interesting is that you can open SVG files in Krita and then trace all the paths inside it.

QML Export

The last feature that I added was the ability to export to QML. This feature is especially interesting for everybody designing special QML interfaces. It exports a all the top-level layers in the Krita image as image and creates a QML file where all the images are inserted as image objects, so the QML UI looks exactly like in Krita (if you you the default composite op). Other attributes that are exported are layer name and opacity, which are mapped to the id and opacity of the object.

A very simple example:

qml

Currently it only exports QML 1.1, but that should be easy to change when I use Qt 5.

More coming in 2013…

2013 will be a very interesting year for Krita with 2.6 to be released this month, 2.7 in summer with the features above and then 2.8 in fall/winter. I also think that Krita Sketch will gain more attraction. We have a lots of things coming up in terms of fixes and performance improvements.

Personally the one thing I’m looking most forward to in 2013 is KDE Frameworks 5. I think it will really be a game changer for Krita, allowing us to cut a number of dependencies which will make Krita much more interesting for many non-KDE users. A Krita version based on it will most likely take till 2014.

Don’t forget the Create Konqui with Krita contest. You still have till end of the month to submit your entry.

Workaround for recent Krita crashes on some systems

October 6, 2012

Recently we have been getting lots of crash reports about Krita crashing on certain systems. So I’m putting up some information about the crashes and how to work around them.

Affected by the crashes are some distributions in combination with open source graphics drivers. In openSUSE 12.2 Krita will crash on startup (bug report) and in the upcoming Ubuntu 12.10 (bug report) it crashes on opening the preferences. The problems are some build issues, where the LLVM usage of OpenGTL which used by Krita and the LLVM usage of the graphics driver conflict.

As a workaround Krita users should use the proprietary graphics driver until these issues are fixed. Users of openSUSE can also have a look on the openSUSE bug report, where some new OpenGTL builds are made available over OBS.

Krita compositions docker

May 9, 2012

After Krita 2.4 is released the development for Krita 2.5 is progressing. The first feature that I added for 2.5 is a the new composition docker. It’s based on a request by David Revoy, who also did the storyboards for Mango (they are shooting currently, with a very cool behind the scenes livestream) in Krita.

The idea behind the compositions docker is very simply. It saves the visibility of all layers and can restore them. Composition are also stored to file if you use Krita’s native fileformat.

This is very useful e.g. for  cartoons were characters are in different situations over the same background or movie storyboards. Beside that it can also be used with different combinations of filters e.g. to simulate different color moods.

Last but not least David did a demo video of the new feature:

Krita bug statistics

December 21, 2011

A few days ago  Martin Gräßlin posted some statistics about bugs in KWin. That got me interested in doing some statistics about Krita.

The first thing I wanted to find out was how long bugs need to get fixed. To do that I wrote a script that extracted the data from the Bugzilla csv export, which is quite limited. There is some data available like the creation date of a bug or the date of the last change, but most details are not available directly. So to get the the data to calculate the lifetime of a bug, I approximated the closing date of a bug with the last change.

From the bug data I generated the following picture that shows all Krita bugs from 2004 till now. Each row shows one line whose length represents the time from report creation to it’s closing. Closed bugs are shown as black, new open bugs are green and unconfirmed bugs red. In the background you can see the length of the years and the blue vertical lines show major releases.

Although the diagramm is very simple, there are lots of things that can be discovered. First thing you might notice, is that it looks like there are some blue lines missing in the middle. That not a mistake, but the big gap were we were porting to KDE 4 (Surprised me a bit, as I thought that it was much longer than it looks).

For the bugs themself it shows that many bugs are closed near their creation, but there are also many bugs with evil long lines. After the release of Version 2.0 the curve get much steeper, which shows that more bugs got reported. It might sound strange, but as the software got more stable more bug reports were submitted. I think it just shows that Krita is used much more now and users work more with it and by that find more bugs. It also shows once again that the raw number of bug reports doesn’t mean anything.

Next I plotted how many bugs get opened and closed every year. Both have increased quite a lot of the last few years. As you can see we usually fix slightly less bugs than are reported (slightly above 90%), so the total number of bugs is still growing. No idea if that is better or worse than other projects.

Last thing I wanted to find out was how the bugs are resolved e.g. if they are really fixed in the classical sense or are just duplicates etc. So I extract the resolution from the data and plotted the four resolutions that are by far the most common for Krita. Not surprising of course is that “fixed” and “duplicate” are the most common. Although I was under the impression that we got a lot more duplicates in the last time, the actual number of duplicates isn’t that big (I also did that for Plasma to compare and it really has a crazy amount of duplicates).


One last detail: I know developers are often criticized for closing many bugs as wontfix and it turns out that this at least doesn’t apply for Krita (yet), as only about one percent of all bugs are closed as wontfix.

“Adaptable” Krita

August 29, 2011

I recently found a very interesting project based on GIMP. AdaptableGIMP basically is a fork that replaced the usual toolbox with a task-oriented UI. It allows to create a “task set” that represents all actions and documentation needed to perform a certain task. Since Krita usually doesn’t use as many complex combinations as GIMP (e.g. we have a rectangle tool, so draw the rectangle is just one step in Krita), I wasn’t that interested at first. But after a closer look, I thought might also be useful e.g. as a fast way to access actions that either have not shortcut or the shortcut isn’t easy to remember.

So yesterday I started my own taskset UI that is inspired by the one from AdaptableGIMP. First I thought about how task sets are created, I skipped the wiki aspect completely as that would take too much time to implement and maintain. Both the wiki and the dialog based taskset creation didn’t completely convince me as they require to search a big list of actions (there are currently 284 actions in Krita) and then add them to the taskset. Whoever used the toolbar editor knows that it’s no so great.

I went for a different solution as can be seen in the following screenshot:

The new task set docker has a record mode that works like recording a macro. Once the record button is pressed it will record all actions the user does. So to create a task set for a certain task you simply record everything that you are doing while performing the task as usual. Thanks to kxmlgui this was very easy to do.

Next thing that was needed was a way to store, load and share task sets. Fortunately I could use the Calligra resource framework for that so I got lots of functionality for free e.g. task sets automatically have tagging integrated (which was a GSoC project this year). For sharing task sets in the future we could use GHNS which is already integrated and just needs a new category on the server. This would also have the advantage that we can reuse the existing facilities of OpenDesktop.

In the future there might be many other applications of this. The current code doesn’t depend directly on Krita and could also be used in other Calligra application. Another thing I noticed in AdaptableGIMP is that is often says that some value needs to be enter into e.g. the filter that pops up. Krita already can save filter configurations, so it could be interesting to restore the filter configuration that was used while recording and blur the differences between macros and task sets even more.

Krita Windows and Mac OS progress

July 25, 2011

Good news for all users that don’t use Linux but still want to run Krita. In the last week lots of progress has been made towards getting Krita to run on Windows and Mac OS X. The Windows work was work was done by stuartmd who is working for KO GmbH. The screenshot below shows current git master running on Windows. The native windows look is a bit ugly, but can of course be changed to Oxygen.

A Windows installer for Krita is expected for the next version later this year. I expect that we will have a quite long testing phase, as there are not many Windows developers and Windows users aren’t used to file bug reports.

Quite a suprise was that almost at the same time forum user pkouame managed to run Krita on the newest Mac OS version. Krita did run on Mac OS for some time, but after almost no Krita developer has an Apple computer anymore so practically nobody did run it.

In other news Anitims Krita DVD can now be preordered.

Krita Sprint 2011: Technology and art

June 4, 2011

Last but not least my report from this years Krita sprint. It was the third sprint just for Krita and it was even more amazing than last years sprint. After being at Boud’s house last year we went to the Blender Institute. The move was necessary as the team did grow quite a bit in that time. The second big change from last year was that this year also some artists attended the sprint. As far as I know it’s quite unique that developers and users meet at a sprint. Although they are not just users, but an important part of the development team and have a huge influence on the direction in which Krita is developing.

Artist demos

So why did we invite artists? Many (if not most) Krita developers, are not (professional) artists, so we depend on artists to show us the bugs and workflow problems that they encounter. It was planned that each of the artists would show us about 30 minutes of painting and we would analyse what we could improve.

The demos were really interesting and surprised me at many points. One thing that especially surprised me how good Krita performed during the demos. I usually see Krita from the other side where I known all the existing problems, but the demos did only show a few even when using the most recent development version. The next thing that really surprised me is that some features are more used than I ever imagined, e.g. presets are used a lot and I had not thought that when I added them.

Another interesting observation for me was that all the artists had totally different workflows. The way the build up their images as well as they used Krita was really interesting to see. For example Animtim works with a gamepad in one hand and the tablet in the other hand. Interesting was also that most artists used suprisingly few features and had had configured lots of shortcuts. The screencaps with are available here (with our discussion as audio).

Planning the next year

After the demos we discussed the plans for the next year. There are lots of things that will be coming with the next version, but most of the work goes into polishing with only some bigger changes coming. The only planned refactoring will be in the selection system, this includes also grayscale masks.

For many users interesting is a news that Boud had: There will soon someone who is paid working on the Windows version of Calligra, which will also includes single-application installers. The Windows version always was something we wanted to have, but since all developers are working on Linux nobody was interested in working on that (Mac situation is even worse as most developers don’t even have Apple hardware). I’m hopeful that it can be ready for the next version.

Hacking

After the official part closed we went to implement the things that where noted in the demos in the morning. First I changed the preset dockers as Bugsbane suggested that we should keep the aspect ration of presets and also use the space more efficently. So now the preset docker will keep the presets square while maximizing the usage of the available space.

Another change that I did was to move the opacity setting from the tool options to the toolbar. Now the opacity works globally for all the tools and Silvio is working on the paintop integration.

Finally I also modified a few shortcuts. The brush increase and decrease shortcuts, so now the adapt to the brush size and make bigger changes when the brush is bigger. That one was also quite funny as we had the direct feedback from the artists. We developers had a discussion if the functionally needed to be even better (like exactly following a exponential curve) when the artists said that it was already perfect for them.

This are only the changes I did. There are some many things going on in Krita development at the moment with about half a dozen different branch working on various features.

Many thanks go to Ton Roosendaal and the Blender Institute for the amazing location and of course KDE e.V. for making the sprint possible.

Krita 2.4 progress

February 8, 2011

Since we released Krita 2.3 last month, the development of Krita 2.4 has been running at an incredible pace. So I thought it might be a good idea to show what we have been doing in the new version.

Since we released we got a huge amount feature wishes, so I took some time to implemented some of them. Most of these changes we in the user interface, as can be seen in the following screenshot.

If you have used Krita 2.3 and earlier versions you probably notice that the tool- and statusbar now take a lot less space. The funny thing behind this I never really noticed it before (I guess as KDE user I was very used to bigger margins and due to my big screen it never bothered me much), but then I saw some Krita on Gnome screenshots (like here) and there is was very obvious.

One very surprising thing about the Krita is that many users are actually running Gnome. There are no exact numbers, but my impression is that there are at least as many Gnome users as there are KDE Plasma workspace users running Krita. After all the discussion in the recent time I think that the users are already much further than the distributions. KDE applications can work and look good under Gnome, but it still requires too much manual fine-tuning to get the best result.

I did a bit more cleanup in the toolbox, where I removed some of the tools that are no longer needed. For example the instead of having on path tool for vector graphics and for raster graphics, we now have just one tool that can switch between the the two based on the context.

In the toolbar the there are now two new functions. The first is that we now have the control for the horizontal and vertical mirror modes in the toolbar, so they work globally across different tools. The modes were added by Lukáš for 2.4 and allow to mirror the current brush painting around one or two axis. It turned out that this feature is quite popular and already produced some very cool results. The only missing part are some good icons for it.

The other new feature in the toolbar is the workspace chooser, which allows to create and switch between workspace. Since Krita has lots of different dockers, which can either be docked or floating, it can be hard to manage them. An artist might want to use different docker arrangements for painting, layer management or vector graphics, so the workspace chooser allows to save a docker configuration.

In the future it might also be possible to save other properties of the environment like the active tool, brush engine, pattern or gradient. It’s not completely clear which properties would be useful, so for now I only saved the docker state. We also thought about a possibility to save it to the current file so that it would be possible to always have the same workspace when working on a certain image, like it’s already done in Blender.

Finally we improved the dockers a bit. I have added a new channel docker that allows to switch on and of channels. Currently it still very simple and doesn’t have the full funtionality that other applications provide yet. Below the channel docker you can see the new preset docker that was added by Adam for 2.4 and provides the same functionality that 2.3 has in the preset popup now also in a docker. By the way: The presets in the docker are from the first user-made preset collection.


Follow

Get every new post delivered to your Inbox.