[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Solution for the grayscale selections
From: Sven Langkamp <sven.langkamp () gmail ! com>
Date: 2012-09-25 15:41:07
Message-ID: CAAmsBfkZibrzzYFwS-ioatVfm=ft2gXV_Jtr4ZX-84406=ZMZQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Sep 25, 2012 at 2:30 PM, Boudewijn Rempt <boud@valdyas.org> wrote:
> I think you need to take a step back from the proposal you came up with a
> year ago and take a look at the big picture, because since then we have
> learned a number of things.
>
> The problem itself should be redefined as "we need to be able to handle
> colorspaces without an alpha channel", not we need to figure out a trick
> to make painting on selections work.
>
> There are two other points:
>
> * Selections should not be an alpha mask, but a grayscale mask without an
> alpha channel.
> * We want to be able to apply vectorization to the composite ops, and for
> that to work we need to take the alpha mask out of band.
>
I wouldn't be so sure that taking just the alpha out of band is good for
vectorization. I think either completely planar or completely interleave
could be best.
We composite rgb as 32-bit integer. SSE2 takes can do four 32-bit integer
numbers at once, which nicely matches rgba. If you take alpha out you end
up with three values, but you still need to load four.
You could do the same operation on the alpha values too and then use the
channel locking to solve that (shuffle new and old values together).
Not sure if Vc provides everything necessary for that. So we might need to
extend it or fall back to use intrinsics. With AVX could be used too, you
would have to load more than one pixel at the same time.
> * Limiting the brush mask to 8 bits integer precision makes painting on
> higher bit depth colorspace paint devices lose precision.
>
The vectorized computation in the Vc branch already uses float. Since the
old one is almost completely using double or float, I don't think it's a
big problem to change that.
> If we take the alpha channel out of band, then pass the brush mask as an
> alpha channel as a separate parameter to KoColorSpace::bitBlt, we'll
> actually have solved the problem in a generic way, without adding hacks to
> KisPaintDevice.
>
> If we make sure the alpha mask is the size of the active colorspace, then
> HDR painting will be much improved.
>
> I think that that's the way forward.
>
>
> On Tue, 25 Sep 2012, Dmitry Kazakov wrote:
>
>
>> On Tue, Sep 25, 2012 at 12:58 PM, Boudewijn Rempt <boud@valdyas.org>
>> wrote:
>>
>> As discussed before, there are a number of places where we need to
>> check whether we get into trouble:
>>
>> * brush mask generation without alpha channel
>>
>>
>> Currently, the paint ops generate the mask exactly into the alpha
>> channel. So the data about the current color is simply lost. You will have
>> to rewrite
>> the paintops to mix this value to the resulting singlebyte pixel. More
>> than that, the resulting composite op will never work like COMPOSITE_OVER.
>> It'll
>> only be able to work like COMPOSITE_ADD, which is quite different.
>>
>> * (possibly) the conversion between colorspaces with and without
>> alpha channel in KoColorSpace::bitBlt
>>
>>
>> To make this conversion you need to have two colorspaces first. And to
>> have two colorspaces you need to tell the paint ops to use some other
>> colorspace.
>>
>>
>> * specific composite ops for the gray without alpha channel
>> colorspace
>>
>>
>> They will never work like usual COMPOSITE_OVER. And to generate a dab in
>> such colorspace we need to make changes in all the paint ops.
>>
>>
>>
>>
>>
>>
>> --
>> Dmitry Kazakov
>>
>>
> _______________________________________________
> kimageshop mailing list
> kimageshop@kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>
[Attachment #5 (text/html)]
<div class="gmail_quote">On Tue, Sep 25, 2012 at 2:30 PM, Boudewijn Rempt <span \
dir="ltr"><<a href="mailto:boud@valdyas.org" \
target="_blank">boud@valdyas.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> I think you need to take a step back from the proposal you \
came up with a year ago and take a look at the big picture, because since then we \
have learned a number of things.<br> <br>
The problem itself should be redefined as "we need to be able to handle<br>
colorspaces without an alpha channel", not we need to figure out a trick to make \
painting on selections work.<br> <br>
There are two other points:<br>
<br>
* Selections should not be an alpha mask, but a grayscale mask without an alpha \
channel.<br>
* We want to be able to apply vectorization to the composite ops, and for that to \
work we need to take the alpha mask out of \
band.<br></blockquote><div><br></div><div>I wouldn't be so sure that taking just \
the alpha out of band is good for vectorization. I think either completely planar or \
completely interleave could be best.</div> <div><br></div><div>We composite rgb as \
32-bit integer. SSE2 takes can do four 32-bit integer numbers at once, which nicely \
matches rgba. If you take alpha out you end up with three values, but you still need \
to load four.</div> <div><br></div><div>You could do the same operation on the alpha \
values too and then use the channel locking to solve that (shuffle new and old values \
together).</div><div><br></div><div>Not sure if Vc provides everything necessary for \
that. So we might need to extend it or fall back to use intrinsics. With AVX could be \
used too, you would have to load more than one pixel at the same time.</div> \
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
* Limiting the brush mask to 8 bits integer precision makes painting on higher bit \
depth colorspace paint devices lose \
precision.<br></blockquote><div><br></div><div>The vectorized computation in the Vc \
branch already uses float. Since the old one is almost completely using double or \
float, I don't think it's a big problem to change that.</div> <div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> If we take the alpha channel out of band, then pass the \
brush mask as an alpha channel as a separate parameter to KoColorSpace::bitBlt, \
we'll actually have solved the problem in a generic way, without adding hacks to \
KisPaintDevice.<br>
<br>
If we make sure the alpha mask is the size of the active colorspace, then HDR \
painting will be much improved.<br> <br>
I think that that's the way forward.<div class="im HOEnZb"><br>
<br>
On Tue, 25 Sep 2012, Dmitry Kazakov wrote:<br>
<br>
</div><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
On Tue, Sep 25, 2012 at 12:58 PM, Boudewijn Rempt <<a \
href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>> wrote:<br> \
<br>
As discussed before, there are a number of places where we need to check \
whether we get into trouble:<br> <br>
* brush mask generation without alpha channel<br>
<br>
<br>
Currently, the paint ops generate the mask exactly into the alpha channel. So the \
data about the current color is simply lost. You will have to rewrite<br> the \
paintops to mix this value to the resulting singlebyte pixel. More than that, the \
resulting composite op will never work like COMPOSITE_OVER. It'll<br> only be \
able to work like COMPOSITE_ADD, which is quite different.<br> <br>
* (possibly) the conversion between colorspaces with and without alpha channel \
in KoColorSpace::bitBlt<br> <br>
<br>
To make this conversion you need to have two colorspaces first. And to have two \
colorspaces you need to tell the paint ops to use some other colorspace.<br> <br>
<br>
* specific composite ops for the gray without alpha channel colorspace<br>
<br>
<br>
They will never work like usual COMPOSITE_OVER. And to generate a dab in such \
colorspace we need to make changes in all the paint ops.<br> <br>
<br>
<br>
<br>
<br>
<br>
--<br>
Dmitry Kazakov<br>
<br>
</blockquote>
</div></div><br>_______________________________________________<br>
kimageshop mailing list<br>
<a href="mailto:kimageshop@kde.org">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" \
target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br> \
<br></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