Solution for the grayscale selections

[Boudewijn Rempt]

On Tue, 25 Sep 2012, Dmitry Kazakov wrote:

>
>       Well, you know what I think of this idea already, since we discussed it before
>
>       For this problem I think there are two decent solutions:
>
>       1) make Krita work with premultiplied alpha colorspaces (i.e., colorspaces with no separate alpha channel). This is a lot of work, but it is the proper solution.
> 
> 
> Well, "premultipled alpha" usually means not "colorspaces with no separate alpha channel", but colorspaces stored in a form of (ra,ga,ba,a). If you have no alpha channel at all, you will simply not be able to do COMPOSITE_OVER,
> because it uses the source alpha even in premultiplied case. Just mathematically. So the premultiplication will give us no help.

Given that other applications can paint on rgb or gray paint devices 
without an alpha channel, using the "over" composite op, it should be 
possible for us to fix pigment to make that work as well. That is the 
real and proper solution. It's also the most difficult one, which is why I 
first investigated the projection solution.

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
* (possibly) the conversion between colorspaces with and without alpha 
channel in KoColorSpace::bitBlt
* specific composite ops for the gray without alpha channel colorspace

And, as we recently discussed, it is a good idea to investigate taking the 
alpha channel out of band altogether, because that makes it easier to 
optimize the composite ops.

So, please focus your work on this solution instead.

>  
>       2) Finish what I started earlier and make the selection have graya colorspace that renders to a gray colorspace projection similar to the way we render a vector selection, that then is used as the selection
> 
> 
> Aren't we fighting against the memory footprint of Krita and trying to optimize our paint-ops which does already copy quite much memory that slows it down?
> 
> If all the paint ops use paintingColorSpace() and *not* use colorSpace() anywhere, then it will be consistent. And there are really few usecases of applying color filters to the selections. If the filter cannot be even theoretically
> applied to the selection, it's better to disable or fix it than allow it to work through some additional devices and get illogical results.

No, it is not consistent. It's workaround -- and I don't like that. I 
don't want special-cased code just for painting on selections in all our 
painting code. Sorry, just like last time you brought up this idea, I 
still dislike it enough that I veto it. It's no-go.

Boudewijn