Solution for the grayscale selections

[Sven Langkamp]

On Tue, Sep 25, 2012 at 2:30 PM, Boudewijn Rempt <boud at 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 at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120925/216330d0/attachment.html>