[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Grayscale Selections
From: Sven Langkamp <sven.langkamp () gmail ! com>
Date: 2011-06-26 3:35:31
Message-ID: BANLkTimiFmrVcx-APBusR+HGJC3We7w=NA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sat, Jun 25, 2011 at 4:55 PM, Dmitry Kazakov <dimula73@gmail.com> wrote:
>
>
> On Sat, Jun 25, 2011 at 6:01 PM, Sven Langkamp <sven.langkamp@gmail.com>wrote:
>
>> On Sat, Jun 25, 2011 at 12:18 PM, Dmitry Kazakov <dimula73@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.
[Attachment #5 (text/html)]
<div class="gmail_quote">On Sat, Jun 25, 2011 at 4:55 PM, Dmitry Kazakov <span \
dir="ltr"><<a href="mailto:dimula73@gmail.com">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;"> <br><br><div class="gmail_quote"><div class="im">On \
Sat, Jun 25, 2011 at 6:01 PM, Sven Langkamp <span dir="ltr"><<a \
href="mailto:sven.langkamp@gmail.com" \
target="_blank">sven.langkamp@gmail.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, \
204, 204);padding-left:1ex"> <div class="gmail_quote"><div>On Sat, Jun 25, 2011 at \
12:18 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:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, \
204, 204);padding-left:1ex">
<br><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0pt \
0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">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.<br>
<br>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.<br> <br>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.<font color="#888888"></font><br clear="all">
</blockquote></div><div><br>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.<br>
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.<br>
</div></div></blockquote></div><div><br>When alpha()==grayChannel() that would \
practically mean we have an alpha colorspace again, right? \
</div></div></blockquote></div><div><br>No, the difference is in the representation \
of the colorspace when composing it to the RGB or other traditional colorspace.<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt \
0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div \
class="gmail_quote"><div>Could give problems with painting I think.<br> </div></div>
</blockquote></div><div>If the composition is defined well at the colorspace level, \
then not.<br></div></div></blockquote><div><br>I have now tried the \
alpha()==grayChannel() by overwriting opacityU8 as<br><br>quint8 \
KoGrayColorSpace::opacityU8(const quint8* U8_pixel) const<br> {<br> return \
*U8_pixel;<br>}<br><br>Interesting is that gradients works correctly, but paint \
doesn't respect the transparent areas of the brush.<br></div></div>
_______________________________________________
kimageshop 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