<br><br><div class="gmail_quote">On Fri, Oct 28, 2011 at 9:51 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Friday 28 October 2011 Oct, Dmitry Kazakov wrote:<br>
> Cyrille, is it possible to have a composite op which has different source<br>
> and destination colorspaces?<br>
<br>
</div>colorspaces can convert the pixels from another colorspace to their own before doing composition, but for painting on masks that's not currently useful since we generate dabs in the target colorspace anyway.<br>
</blockquote><div><br>Well, the colorspace of a dab is really not a problem, i guess. A node can have both paintDevice() and dabColorSpace() methods. And tools can use the latter one to create a dab of a proper colorspace.<br>
 <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

The real issue is not the conversion, but that krita cannot handle colorspaces without an alpha channel -- or colorspaces with alpha pre-multiplied, which this would be, I guess. This is, I think, a limitation that permeates Krita everywhere.<br>
</blockquote><div><br>Well, if we decide to have different colorspaces for a dab and a paint device then we will avoid this limitation.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


For 2.4, it's certainly not something I see feasible to implement. Nor am I confident it would be a good idea: it was a conscious design decision back then. It's why we always have cmyka, never just cmyk.</blockquote>
<div><br>I'm sure we shouldn't hurry with such decisions. Especially, after we have released several betas.<br></div></div><br><br clear="all"><br>-- <br>Dmitry Kazakov<br>