Hi, all!<br><br>Today I'm happy to announce that now Krita has finally got the implementation of the grayscale selections! It was awaited for so long! Now everyone can fetch the first version of it from 'krita-testing-kazakov' branch!<br>
<br>Well, I'm sure there will be some questions, so I would like to split this message into two parts: new-features-presentation and technical.<br><br>Features:<br>- you can now paint on Masks and Filter Layers<br>- you can also use Gradient and Fill Tool<br>
- the white color corresponds to the selected (visible) area, black --- unselected (invisible)<br>- painting on Selection Masks is a bit tricky currently, because it is a selection and a paint device at the same time. It means that your strokes are limited (selected) by the contents of the device you are paint on (yeah, I said it is tricky!). Probably, we should fix it somehow a bit later.<br>
- Color Smudge Brush and Experiment Brush are the only tools left which do not work with the selections properly. There are a few technical things yet to be solved.<br><br>Things that need to be tested:<br>- painting with various tools and brushes on Transparency Masks, Filter Masks, Selection Masks and Filter Layers.<br>
- the important thing is to check whether most brush options work as expected<br><br>Technical part:<br><br>Ok. I began implementing this thing on Saturday. I spend two days on doing the preparational work for the huge selections refactoring suggested by Boud, which assumed switching KisPixelSelection to a two byte color space. I did a 2k lines patch [1] which implemented the new "paintable selection" without connecting it to any external classes and did the unit tests for it. Then I started the work on preparing the color spaces for this "paintable selection". After some experiments (with the help of Cyrille) it turned out that the grayNoALpha colorspace will not work for the our selection's projection (exactBounds() mechanism wouldn't work) and we still had to stick to alpha8 color space. So (again, with the help of CyrilleB) I did a few refactorings to the pigment that did right conversion between apha8<->grayA colorspace.<br>
<br>At this point I had the following:<br><br>1) Implemented KisPaintableSelection<br>2) [Very roughly] connected it to the KisSelection without i) proper merging mechanism; ii) exposing new interface outside the KisSelection class.<br>
<br>And I still had to implement the following:<br><br>I) Thread-safe merging of the selection into projection<br>II) Change the public interface of KisSelection::getOrCreatePixelSelection() and KisSelection::pixelSelection() which are currently used in 57+175 = 232 places.<br>
III) Completely rewrite all the KisSelectionFilter-based classes, because most of them were copied from Gimp and work with bytes directly.<br>IV) Solve various problems arising from the fact that (even in flattened state) the pixelSelection() and projection() do not coincide, t.e. in the Transform Tool.<br>
<br>That would (very optimistically) take a week of work... and introduce unknown number of crash-bugs. [2]<br><br><br>Ok. But there was a piece of good news: implementing a proper color conversion to/from alpha8 gave me a chance to try the other option --- cross-colorspace painting. The patch for pigment would take about 150 lines of code. So yesterday evening I decided to give it a try... and turned out that this approach wouldn't demand any vast changes. The patch for Krita changes about 300 lines of code, which are, mostly, one-line changes: it tells the painting tools to use another color space.<br>
<br>So, now you can test and review it. I'm open to any constructive comments about it.<br><br><br><br clear="all">[1] - <a href="http://paste.kde.org/709388/">http://paste.kde.org/709388/</a><br>[2] - btw, it would also make our selection system eat three times more memory and work twice slower.<br>
<br>-- <br>Dmitry Kazakov