Solution for the grayscale selections

[Boudewijn Rempt]

On Tue, 25 Sep 2012, Dmitry Kazakov wrote:

> Hi!
> 
> I started fixing the grayscale selections problem yesterday. We've discussed the details of it several times already, so I'll try not to write too much. So, the working solution is the following:
>
> 1) Every paint device has an additional method paintingColorSpace(). This method tells the painting tools which colorspace they should use for their dabs.

Well, as we discussed before, I think that this is not a good idea. I 
think it is a hack, in fact. The proper solution is to make krita work 
with pre-multiplied alpha colorspaces.

> 2) Some KoCompositeOp's have an ability to work cross-colorspace, that is with the source in one colorspace and the destination in the other.

That's the wrong level. The composite op api is hidden behind the 
KoColorSpace api. KoColorSpace::bitBlt already handles the case where you 
try to composite pixels in two different colorspaces.

> The alpha8 colorspace has such compositeOps. The methods are:
> 
>     /**
>      * Returns true if the composite op can write pixels into the parent
>      * colorspace from a colorspace \p srcSpace. If this function returns
>      * true, then a special method
>      * composite(const ParameterInfo&, const KoColorSpace*)
>      * becomes available to the user. Otherwise the CS should be
>      * converted before calling a usual composite() method
>      *
>      * \see composite(const ParameterInfo&, const KoColorSpace*)
>      */
>     virtual bool supportsCrossColorspaceComposition(const KoColorSpace* srcSpace) const;
> 
>     /**
>      * Composes pixels from any arbitrary colorspace \p srcSpace
>      * to the destination buffer. It is available only in case
>      * supportsCrossColorspaceComposition() returns true
>      */
>     virtual void composite(const ParameterInfo& params, const KoColorSpace* srcSpace) const;
> 
> 3) The selection nodes still keeps the alpha8 colorspace for their paint devices, but return a grayscale8 colorspace as their painting colorspace. In a result, the bitBlt operation for the dabs will convert the pixels right.

Well, I think selection nodes should have a gray8 colorspace instead.

> The only trouble I see here is that in all the paintOps I'll have to change device()->colorSpace() to device->paintingColorSpace(), which is quite doable.

We should also be able to apply filters to masks, and the filters need to 
have a color channel as well to work properly.

> So what do you think of it?

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.

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

Boudewijn