[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-25 14:01:09
Message-ID: BANLkTikG8y+ddALx0GZ-0RZbXxQb6rcAkA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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? 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.
>
[Attachment #5 (text/html)]
<div class="gmail_quote">On Sat, Jun 25, 2011 at 12:18 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><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">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><br>When alpha()==grayChannel() that would practically \
mean we have an alpha colorspace again, right? Could give problems with painting I \
think.<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>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><br>We could do that as well. There is just a change in \
selectedRect() and selectedExactRect() needed.<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>Cons:<br>- in case we \
try to merge two selections it doesn't change the default pixel<br> <br>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>
<br>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.<br></div></div></blockquote></div><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