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

[Sven Langkamp]

Not sure if that was this branch, but I now get some unconnected errors:

Object::connect: No such signal
KisImage::sigColorSpaceChanged(KoColorSpace*) in
/home/sven/kde/src/calligra/krita/ui/kis_view2.cpp:850
Object::connect:  (sender name:   'unnamed')
Object::connect: No such signal
KisImage::sigProfileChanged(KoColorProfile*) in
/home/sven/kde/src/calligra/krita/ui/kis_view2.cpp:851
Object::connect:  (sender name:   'unnamed')
Object::connect: No such signal
KisImage::sigColorSpaceChanged(KoColorSpace*) in
/home/sven/kde/src/calligra/krita/ui/kis_view2.cpp:879
Object::connect:  (sender name:   'unnamed')
Object::connect:  (receiver name: 'paintopbox')



On Tue, Mar 26, 2013 at 12:51 PM, Dmitry Kazakov <dimula73 at gmail.com> wrote:

> 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
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20130329/079a1360/attachment.html>