Solution for the grayscale selections

[Sven Langkamp]

On Tue, Sep 25, 2012 at 10:07 AM, Dmitry Kazakov <dimula73 at gmail.com> 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.
> 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. 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.
>
> 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.
>
> So what do you think of it?


If we make a few assumptions that:
-source and destination colorspace are the same colorspace, except that the
destination doesn't have the alpha channel
-source alpha is the last channel so RGBA

it could be done in the composite op. We add another method like
"compositeWithAlphaToNoAlpha" that would work like the current one, just
pretend that it read full opacity from the destination. Then it would
simply composite the color channels in the colorspace that doesn't have
alpha with passing the alpha it calculated. With the alpha at the end it's
sure the the no-alpha colorspace will never read into the alpha while
compositing. Then it just needs to advance source by color + alpha size and
destination with color size and start again.

As most composite ops are based on KoCompositeOpAlphaBase anyway only very
few composite ops (for the default ops it't alpha darken, copy, and erase)
need some additinal code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120925/75fd6978/attachment.html>