[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Grayscale Selections
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2011-06-25 14:55:57
Message-ID: BANLkTimSj_j7+-6kUCA161oOAxZZKarUnw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
>
>
>> 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.
>
No, no semantic changes to selected{,Exact}Rect(), please. They have a
completely different semantic. The method you want does a different thing
and must be used in a different way. The same name for both the methods will
confuse the users. So you should first define the usecases for it, how it
should be used and how the caller should deal with the default pixel of the
device.
Anyway, you do already have this method: it is region().
> 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?
>>
>
You haven't answered.
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Sat, Jun 25, 2011 at 6:01 PM, Sven Langkamp <span \
dir="ltr"><<a href="mailto:sven.langkamp@gmail.com">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 class="im">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><br>No, the difference is in the representation of the \
colorspace when composing it to the RGB or other traditional colorspace.<br> \
</div><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>If the \
composition is defined well at the colorspace level, then not.<br><br> \
</div><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> \
</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>Pros:<br>+ this approach fit the general idea filters use: \
we guarantee the image processed right inside image bounds only.<br>+ the callers \
should not bother about the default pixel of the selection<br>
</div></div></blockquote></div><div><br>We could do that as well. There is just a \
change in selectedRect() and selectedExactRect() \
needed.<br></div></div></blockquote><div><br>No, no semantic changes to \
selected{,Exact}Rect(), please. They have a completely different semantic. The method \
you want does a different thing and must be used in a different way. The same name \
for both the methods will confuse the users. So you should first define the usecases \
for it, how it should be used and how the caller should deal with the default pixel \
of the device.<br> <br>Anyway, you do already have this method: it is region().<br> \
</div><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 \
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>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?<br> \
</div></div></blockquote></div></div></blockquote></div><br>You haven't \
answered.<br><br clear="all"><br>-- <br>Dmitry Kazakov<br>
_______________________________________________
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