<br><br><div class="gmail_quote">On Tue, Sep 25, 2012 at 8:36 PM, Sven Langkamp <span dir="ltr"><<a href="mailto:sven.langkamp@gmail.com" target="_blank">sven.langkamp@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So what do you think of it?</blockquote><div>
<br></div></div></div><div>If we make a few assumptions that:</div><div>-source and destination colorspace are the same colorspace, except that the destination doesn't have the alpha channel</div><div>-source alpha is the last channel so RGBA</div>
</div></blockquote><div><br></div></div>The question is, how are we going to tell paint ops to use a different (RGBA) colorspace instead of a value returned by KisPaintDevice::colorSpace() that will return RGB in this very case? That is the point where Boud doesn't agree. I have already got a small draft of a composite op you described and it works quite well. But we need some way for the paint ops to prepare data with that alpha channel for it. That is the problem.<br>
<br clear="all"><br>-- <br>Dmitry Kazakov<br>