sven.langkamp at gmail.com
Sat Jun 25 16:01:09 CEST 2011
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.
> + 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
> - in case we try to merge two selections it doesn't change the default
> Well yes, we can add a separate method like
> rectThatDoesntChangeWhenYouChangeTheDefaultPixel() (and we actually do
> already have such a method ), 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...
More information about the kimageshop