<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well, you know what I think of this idea already, since we discussed it before<br>
<br>
For this problem I think there are two decent solutions:<br>
<br>
1) make Krita work with premultiplied alpha colorspaces (i.e., colorspaces with no separate alpha channel). This is a lot of work, but it is the proper solution.<br></blockquote><div><br>Well, "premultipled alpha" usually means not "colorspaces with no separate alpha channel", but colorspaces stored in a form of (ra,ga,ba,a). If you have no alpha channel at all, you will simply not be able to do COMPOSITE_OVER, because it uses the source alpha even in premultiplied case. Just mathematically. So the premultiplication will give us no help.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

2) Finish what I started earlier and make the selection have graya colorspace that renders to a gray colorspace projection similar to the way we render a vector selection, that then is used as the selection</blockquote><div>
<br>Aren't we fighting against the memory footprint of Krita and trying to optimize our paint-ops which does already copy quite much memory that slows it down?<br></div></div><br>If all the paint ops use paintingColorSpace() and *not* use colorSpace() anywhere, then it will be consistent. And there are really few usecases of applying color filters to the selections. If the filter cannot be even theoretically applied to the selection, it's better to disable or fix it than allow it to work through some additional devices and get illogical results.<br>
<br>-- <br>Dmitry Kazakov<br>