Grayscale Selections

[Sven Langkamp]

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

>
>
> On Sat, Jun 25, 2011 at 6:01 PM, Sven Langkamp <sven.langkamp at gmail.com>wrote:
>
>> 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?
>>
>
> No, the difference is in the representation of the colorspace when
> composing it to the RGB or other traditional colorspace.
>
>
>> Could give problems with painting I think.
>>
> If the composition is defined well at the colorspace level, then not.
>

I have now tried the alpha()==grayChannel() by overwriting opacityU8 as

quint8 KoGrayColorSpace::opacityU8(const quint8* U8_pixel) const
{
    return *U8_pixel;
}

Interesting is that gradients works correctly, but paint doesn't respect the
transparent areas of the brush.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110626/0c0a9694/attachment.htm