[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: New Grayscale Selections and Masks in 'krita-testing-kazakov'
From: Sven Langkamp <sven.langkamp () gmail ! com>
Date: 2013-03-29 2:26:20
Message-ID: CAAmsBfk6GCgsW+96vidExSvp5PVXGmOKvKQfi70CRSAVSwEXDA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Not sure if that was this branch, but I now get some unconnected \
errors:<div><br></div><div><div>Object::connect: No such signal \
KisImage::sigColorSpaceChanged(KoColorSpace*) in \
/home/sven/kde/src/calligra/krita/ui/kis_view2.cpp:850</div> <div>Object::connect: \
(sender name: 'unnamed')</div><div>Object::connect: No such signal \
KisImage::sigProfileChanged(KoColorProfile*) in \
/home/sven/kde/src/calligra/krita/ui/kis_view2.cpp:851</div><div>Object::connect: \
(sender name: 'unnamed')</div> <div>Object::connect: No such signal \
KisImage::sigColorSpaceChanged(KoColorSpace*) in \
/home/sven/kde/src/calligra/krita/ui/kis_view2.cpp:879</div><div>Object::connect: \
(sender name: 'unnamed')</div><div>Object::connect: (receiver name: \
'paintopbox')</div> </div><div><br></div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 26, 2013 at 12:51 \
PM, Dmitry Kazakov <span dir="ltr"><<a href="mailto:dimula73@gmail.com" \
target="_blank">dimula73@gmail.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">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/" \
target="_blank">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.<span \
class="HOEnZb"><font color="#888888"><br>
<br>-- <br>Dmitry Kazakov
</font></span><br>_______________________________________________<br>
Krita mailing list<br>
<a href="mailto:kimageshop@kde.org">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" \
target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br> \
<br></blockquote></div><br></div>
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic