Solution for the grayscale selections

[Boudewijn Rempt]

On Tue, 25 Sep 2012, Dmitry Kazakov wrote:
> 
> On Tue, Sep 25, 2012 at 4: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.
> 
> 
> Wait, as far as I remember we were talking exactly about "how to make grayscale selections work".

I have mentioned a couple of times already in this discussion that I want 
a good solution, not a special-casing hack. The problem we have is not 
that we need a different colorspace from the one that defines the paint 
device defines, but that we need an alpha channel.

And the option to take the alpha channel seperately is something I've 
pointed out explicitly from the very first in this thread.

> If we want to mix this work with optimization, then we should call it a bit differently: "we need to be able to handle
> colorspaces with a *separate* alpha channel".
> 
> On Sunday I thought about an idea of passing the separate alpha to bitBlt as well. Here are the conclusions which I came to:
> 
> 1) It will give us *some* opportunities for structural optimizations. We will be able to handle the case of uniform coloring (the most common case) much more
> efficiently. I can't tell how much speed it will give.
> 2) It will *not* give us much opportunities to use vectorization, because the pixels in the layer will be laid out in a standard way. Only scaling of the whole mask
> will be optimized here.

For most if not all composite ops, the formula to calculate the result is 
the same for all color channels, so we can vectorize that easily. We do 
not have to completely change to a planar pixel representation.

> 3) We will still have to use something like KisPaintDevice::paintingColorSpace() or KoColorSpace::paintingColorSpace() to get a colorspace for the other components of
> the pixel *or* store the alpha mask twice: both in pixels and in a separate mask.

Please get rid of the idea of something called paintingColorSpace. There 
is no such thing. There are color models with and without alpha.

> 4) The KisToolFill and KisToolGradient will need changes as well.
> 
> I dropped this idea then because I though it would demand too much changes and take too much time.
> 
>  
>       * Limiting the brush mask to 8 bits integer precision makes painting on higher bit depth colorspace paint devices lose precision.
>
> This is a completely different problem and can be solved separately after we implement any of the suggested ideas.

Of course, but it's much easier if we keep the alpha mask separate.

>       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.
>
> Well, it is not too generic actually, because it either adds paintingColorSpace() method to the color space or a paint device, or it duplicates the alpha value in both:
> in pixels and in a mask for regular RGBA devices. Despite that fact, I don't object implementing this idea, because of the opportunities, that we can get with the
> structural optimizations mentioned in 1).

That depends on how you implement it. If done thoroughly we wouldn't have 
an RGBA device anymore: we would have an RGB + A device.

> 
> Ok, if you want I can think about this idea. But its implementation will take quite much time.
>

Yes, of course, but that's what we are sponsoring you for.