<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That does not require to use premultiplied alpha. In that case it is just<br>
assumed that alpha = 255.<br>
<br>
Right now, composite op assumes that source colour space == destination<br>
colour space. But there is no reason why we can't change that specific<br>
behaviour. I would do the following:<br>
<br>
* in KoCompositeOp, add an optional parameter for a destination colour<br>
space<br>
* in KoColorSpace::bitBlt, if source colour space != destination, check if<br>
there is a composite op that can work across those two colour spaces<br>
* implement a "gray" only colour space, and a GRAYA on GRAY composite op,<br>
that assumes that GRAY's alpha channel is set to 255 all the time.<br></blockquote><div><br>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.<br>
 </div></div>-- <br>Dmitry Kazakov<br>