Solution for the grayscale selections
Dmitry Kazakov
dimula73 at gmail.com
Tue Sep 25 09:28:27 UTC 2012
> That does not require to use premultiplied alpha. In that case it is just
> assumed that alpha = 255.
>
> Right now, composite op assumes that source colour space == destination
> colour space. But there is no reason why we can't change that specific
> behaviour. I would do the following:
>
> * in KoCompositeOp, add an optional parameter for a destination colour
> space
> * in KoColorSpace::bitBlt, if source colour space != destination, check if
> there is a composite op that can work across those two colour spaces
> * implement a "gray" only colour space, and a GRAYA on GRAY composite op,
> that assumes that GRAY's alpha channel is set to 255 all the time.
>
That is almost exactly what I am going to do. The question is (more
exactly, what Boud doesn't like) how do we tell the tools to use that GRAYA
colorspace when painting on GRAY paint devices. I suggest using a method
KisPaintDevice::paintingColorSpace(). What we need to do in this case is
just to change all the device()->colorSpace() to
device()->paintingColorSpace() in the code of creation dabs in the paint
ops. This solution is quite logical and consistent given that no code in
the paint ops will access device()->colorSpace(). And Boud objects this.
--
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120925/6cad202e/attachment.html>
More information about the kimageshop
mailing list