New Grayscale Selections and Masks in 'krita-testing-kazakov'

[Dmitry Kazakov]

Hi, all!

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!

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.

Features:
- you can now paint on Masks and Filter Layers
- you can also use Gradient and Fill Tool
- the white color corresponds to the selected (visible) area, black ---
unselected (invisible)
- 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.
- 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.

Things that need to be tested:
- painting with various tools and brushes on Transparency Masks, Filter
Masks, Selection Masks and Filter Layers.
- the important thing is to check whether most brush options work as
expected

Technical part:

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.

At this point I had the following:

1) Implemented KisPaintableSelection
2) [Very roughly] connected it to the KisSelection without i) proper
merging mechanism; ii) exposing new interface outside the KisSelection
class.

And I still had to implement the following:

I) Thread-safe merging of the selection into projection
II) Change the public interface of
KisSelection::getOrCreatePixelSelection() and
KisSelection::pixelSelection() which are currently used in 57+175 = 232
places.
III) Completely rewrite all the KisSelectionFilter-based classes, because
most of them were copied from Gimp and work with bytes directly.
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.

That would (very optimistically) take a week of work... and introduce
unknown number of crash-bugs. [2]


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.

So, now you can test and review it. I'm open to any constructive comments
about it.



[1] - http://paste.kde.org/709388/
[2] - btw, it would also make our selection system eat three times more
memory and work twice slower.

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20130326/6335a2b5/attachment.html>