Grayscale Selections

[Sven Langkamp]

On Sat, Jun 25, 2011 at 12:18 PM, Dmitry Kazakov <dimula73 at gmail.com> wrote:

>
> 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.
>

When alpha()==grayChannel() that would practically mean we have an alpha
colorspace again, right? Could give problems with painting I think.


> 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
>

We could do that as well. There is just a change in selectedRect() and
selectedExactRect() needed.


> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110625/db20534e/attachment.htm