Krita Lime PPA: always fresh versions for Ubuntu users!

A great piece of news for Ubuntu Krita users is coming today! We have just opened a repository with regular builds of Krita git master!

Link: https://launchpad.net/~dimula73/+archive/krita

The main purpose of this PPA is to provide everyone with an always fresh version of Krita, without the need to update the whole system. Now one can get all the latest Krita features without a delay.

At the moment git master version has at least three features, which are absent in Krita 2.7 Beta1 (and cannot be merged there due to code freeze):

• New "New Image From Clipboard" dialog with a nice preview widget implemented by our new contributor Matjaž Rous
• New "pseudo-infinite" canvas feature (read here) for dynamical image resizing
• New "Overview Docker" which lets you see the whole image at a glance

To install the newest Krita you need to do a few steps:

1. Check that you don't have any original calligra or krita packages provided by your distribution or project-neon (we don't check that automatically currently)
2. Add the PPA to repositories list:
   

   sudo add-apt-repository ppa:dimula73/krita

3. Update the cache: 

   sudo apt-get update 

4. Install Krita: 

   sudo sudo apt-get install krita-testing krita-testing-dbg 

Update:
After installing this package you should restart X-server to get environment variables updated!


Of course, being based on git-master may sometimes result in a bit of instability, so make sure you report any problems so we can fix them! :)

Krita 2.8 (prealpha): New "pseudo-infinite" canvas feature

— "Darn it! Again no space on my canvas for the feet! What now?"

Does this sound familiar to you? Does going to the canvas resize dialog break your workflow? Don't be frustrated anymore! Now you can just scroll down, click and... Presto! Add those happy feet to your drawing!

Now if you scroll the image behind the edge a wide button appears which you can use to expand your image up to the size of your screen!

A short example:

Upcoming Krita 2.7: Updated Drag & Drop and Clipboard functionality

Recently we spent some time on polishing the Drag & Drop and Copy & Paste functionality in Krita. It turned out that these simple things are very important for users, since they allow integrate Krita into user's workflow better. It's a pity we were not able to pay much attention to them for some time, so as time passed they became a bit buggy. Now the bugs are gone and I can say for sure that there is no bugs in these systems! (at least bugzilla and me don't know any :)

Here is a short list of capabilities you can use to integrate Krita into your workflow (will be publicly available starting from Krita 2.7 Beta 2):

1. Clipboard. Now the pasted image always gets centered right. And thank to the patch by our new contributor Sahil Nagpal the Custom Image dialog doesn't go insane when finds something in the Clipboard :)
2. Drag-and-Drop of Image-objects. You can drop any image (from Gimp or Chromium) to Krita canvas and it will be centered in the image. If you want it to be centered around the mouse position, just press Shift key while dragging. You can also drop an image directly into the Layers docker, which will allow you to choose the position of a newly created layer in the stack.
3. Drag-and-Drop of a URL. If you drop an image from Firefox (yes, Firefox doesn't wrap images into image objects) or from Dolphin, it will also be added to your image as a layer.
4. Drag-and-Drop of many images at once. Not many people know about this feature, but Krita will also handle this case =)
5. And of course, Drag-and-Drop of layers between different instances of Krita app. This feature was a tough one because of some bug in Qt's QTreeView implementation of D&D. It was always generating some spurious MouseMove events which were canceling the incoming drop. But now this finally works.

Enrico Guarnieri's beautiful 

splash screen for Krita 2.7

 

New User Interface for Krita Color To Alpha filter

Hi, all!

The comments of the artists about my previous change to the Color To Alpha filter showed that many of them really need it in their daily work! But most of them agreed that the user interface of the filter was still "not good enough" for many of the use cases: you simply couldn't select the exact color which should be made transparent! So now the problem is gone and you have various ways of doing this:

Firstly, when you apply a filter directly to the layer with the Filters->Colors->Color To Alpha... menu item, you can just pick the desired color from the image below the dialog! You should also note that while doing this, you can change the options of the color picking tool in the Tool Options docker, like select the Radius used for calculating the average value or to choose whether to pick from the original layer pixels or from the resulting composed image.

Secondly, you can use the standard KDE Color Dialog where you can select the precise RGB values of the color to remove.

And lastly, you can use the Color Picking Tool provided by the KDE Color Dialog. The advantage of this tool is that you can pick a pixel not from Krita only, but from the entire monitor screen!

Just to show you what is now possible with the filter I took a picture that was filmed for some action film... and made it a bit more peaceful :)

The changes are going to be merged into Krita-master (aka Krita-2.7pre-alpha) in a day or two, since it needs to go through a short review process. If you want to test it right now, you can get the updated version from 'krita-testing-kazakov' branch!

Updated Krita ColorToAlpha filter

Hey! We've just updated our Color to Alpha filter, so it can now be easily used for removing background from scanned sketches! Our algorithm differs from the one used in Gimp: we use CIE deltaE [0] function to calculate the difference between the image and the base color, so it is more flexible and configurable. You can choose to what extent you want to remove the background by changing threshold value.

(original painting by David Revoy)

The filter's algorithm is actually quite simple:

1) Firstly, we calculate the difference between the image pixel and the base color and decrease the pixel's opacity according this difference. The less the difference, the more opacity is decreased. As I already said we use deltaE function to calculate this difference.

2) Secondly, we apply an inverse "composite over" to every pixel. Due to that step, if we put a layer filled with a base color below the filtered image, we will get original image!




[0] - http://en.wikipedia.org/wiki/Color_difference

Krita: panning, race conditions and other bug fixes

Hi, All!

I haven't been blogging for about three weeks. They were quite tough. Like everyone in Krita team I was working on fixing bugs and making Krita user ready. And now I'm going to describe what I've done.

The first week was spent on making Panning and Color-picking gestures work for all the tools. I achieved this by moving gestures code to base classes KisTool and KisToolPaint. It was quite non-trivial task, because I had to fix classes of all the tools in Krita as there is no common strategy how to handle mouse events.

I think, we should elaborate some good system for gestures after 2.3 release, but I can't really imagine how. This new system must handle all the mouse and tablet events itself, and provide some callbacks(?) and interfaces for tools. The callbacks should look like: startStroke(), cancelStroke(), endStroke(). The problem is, our tools use different interaction types. I mean not all of them use "strokes" strategy. For example, Paint Bucket tool uses single clicks, Gradient tool uses dragging, Path tool has a very complicated system with various types of clicks and modifiers. I think, we need to incorporate "strategy" pattern here, but I really can't get it how.

The next week I was fixing various bugs. I fixed selections of masks and filters, so now they are applied to the entire layer, not just to a small rectangle in the bounds of the image. Then I fixed a race condition in KisUpdaterContext. It used to rely on KisSharedPtr in concurrent environment heavily. But the shared pointer do not have many guarantees for multithreading. So I created a very convenient environment for the shared pointer with only one producer and one consumer. It can easily handle it. After that I fixed a race between KisGroupLayer and KisAsyncMerger. Then Color Conversion Curves Filter was fixed. The problem was really tricky here. It was due to the use of temporarily copied QVector, returned form the function. When we performed data() call, Qt made a deep copy of the vector and deleted the temporary object very soon. So the code used to read free'd memory. The problem was solved by using constData() instead to avoid copying.

And the last week was spent on fixing race conditions inside the data manager. They were really difficult races to find. You can read very detailed report about them in my commit message [0].

[0] - http://websvn.kde.org/?view=revision&revision=1181593

Krita: Free Scrolling and Masks improvements

Hi, All!

Last week I was working on fixing one of the most reported bugs of Krita. Many users wanted to scroll the canvas in a way to see corners of the image in the center of the screen. Now it is easily possible. More than that, coupled with the ability to zoom and pan image with the wheel, Free Scrolling makes the workflow very smooth. I think people who ever used CAD systems would feel something like deja vu, when try it ;)

Another task of mine was to fix Masks updates, because they curiously broke after i activated multithreading. I've spent about 9 hours searching race conditions and all, but the problem appeared to be trivial. There was a legacy code that wasn't ported when move() feature of paint device appeared. It caused clear() operations clear wrong areas. Everything was fine in single-threaded environment, because those areas were overwritten immediately. But in multithreaded case, those operations broke usage-guarantees of the data manager (that is we must not access intersecting areas simultaneously, but must work with independent areas instead). Broken guarantees, in their turn, led to race conditions during update. You can see how trivial the fix was [1], but it was really tough to find :)

[1] - http://websvn.kde.org/?view=revision&revision=1174365