Grayscale Selections

[Dmitry Kazakov]

> as you may have seen I have started a new branch
> krita-selection-grayscale-langkamp with some experiments around grayscale
> masks. Dmitry wanted to have a mail to show what I'm doing.
>
> So for now I have changed pixel and vector selection to use a grayscale
> with no alpha channel instead of the current alpha colorspace. I have also
> fixed the marching ants to work with that.
>
> The biggest problem currently is that in most parts we assume the
> non-selected parts to be transparent. Now the default pixel of the selection
> isn't transparent anymore which means that extent() will fallback to use
> KisDefaultBounds and often return an pratically infinite rect. I'm think
> about adding a parameter to extent() and the other methods to optionally not
> use default bounds here.
>

KisDefaultBounds returns infinite rect, because it is not connected to any
image. So it has no source to read bounds from. The image pointer should be
given to the constructor of the paint device.
I don't think adding a parameter will make things better. I guess it'll make
the things even worse. Because in such a case you will not be able to
process any selection having defaultPixel() not completely black. An
example: after a select all call we can create a selection with default
pixel equal to white (opaque); the real extent() of such device will be
empty rect. But the extent for the processing -- image->bounds(). So as a
solution I think the best way is to tell the colorspace to return
alpha()==grayChannel(). In such a way the defaultBounds mechanism would be
activated and all non-transparent pixels would be processed.

Pros:
+ this approach fit the general idea filters use: we guarantee the image
processed right inside image bounds only.
+ the callers should not bother about the default pixel of the selection
Cons:
- in case we try to merge two selections it doesn't change the default pixel

Well yes, we can add a separate method like
rectThatDoesntChangeWhenYouChangeTheDefaultPixel() (and we actually do
already have such a method [1]), but in such a case, could you define all
the cases when we should use this method and when we should not?

Defining the usecases for it is quite important, because usage of such
method automatically makes the person to deal with the default pixel of the
device manually.


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110625/6d320946/attachment.htm