<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="font-family: 'DejaVu Sans'; font-size: 9pt; font-weight: 400; font-style: normal;">
<p style="margin: 0px; text-indent: 0px;"></p><div class="im">> There are two solutions for that.<br>><br>> 1) Most obvious way. Just use grayscale8 colorspace for KisSelection's<br>> paintDevice. The second problem will be solved in a natural way. But<br>
> this system has a huge drawback. Much code of Krita uses direct access<br>> to selection's transparency pixels (that is not so good in general).<br>> The calls are done like:<br>> selection()->pixel()->alpha()<br>
> ALL THIS CALLS will have to be changed to:<br>> selection()->pixel()->gray()<br>> That is possible, but quite difficult.<br></div>Any code example of that ?</div></blockquote><div><br>At this very moment KisAdjustmentLayer::createThumbnail uses it. But this is an extremely ancient hack and i've already fixed it in my patch. I've added selection parameter to KisPaintDevice::createTumbnail() and call this instead.<br>
<br>There are some more uses of alpha() reported by:<br>fgrep 'alpha()' -R ./ |grep -v doc |grep -v svn<br><br>maybe, they are not connected with it...<br><br>There is one more issue with gray8+alpha colorspace for selections. KisSelection uses<br>
<br>quint8 defPixel = *(m_d->pixelSelection->dataManager()->defaultPixel());<br><br>It assumes selection pixel to be single-byte. I think this construction is bad itself. And, alll the same, KisSelection should be changed a bit. (we have a bug connected with it somehow).<br>
<br>As KisSelection should be change to use pointers (or NOT USE defaultPixel() stuff at all), it's not a big deal to fix it.<br><br>The only thing i'm afraid of such assumptions can be present somewhere else in the code =(<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="font-family: 'DejaVu Sans'; font-size: 9pt; font-weight: 400; font-style: normal;">
Because, to me this sounds like a wrong construct, everywhere we should access selectiveness through iterators, and then the only requirement for the color space of the mask/selection is to be single channel unsigned interger 8bit. Was it what you meant ?<br>
</div></blockquote><div><br>Yes, i'm just afraid of the code with strange assumptions. =) <br><br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="font-family: 'DejaVu Sans'; font-size: 9pt; font-weight: 400; font-style: normal;"><div class="im"><p style="margin: 0px; text-indent: 0px;"></p><p style="margin: 0px; text-indent: 0px;">> 2) The second way is not so obvious and needs some help from<br>
> Cyrille. This solution leaves KisSelection's paintDevice in alpha8()<br>> colorspace. BUT all the painting and bitBlt'ing into this device will<br>> be done through a special type of a grayscale colorspace, let's call<br>
> it transparencyColorspace(TCS). This TCS will have two channels: gray<br>> and alpha. Gray-channel accumulates rgb-values of the brush and alpha<br>> channel controls the shape of the brush. The only difference of TCS<br>
> from usual grayscale CS is the way it is converted into alpha8() CS.<br>><br>> Usual grayscale CS:<br>> GCS alpha8()<br>> Gray -> [/dev/null]<br>> Alpha -> alpha<br>><br>> Our TCS:<br>
> TCS alpha8()<br>> Gray -> alpha<br>> Alpha -> [used by compositeOp's]<br>><br>> The question is: which way to choose?<br></p><p style="margin: 0px; text-indent: 0px;"><br><br></p></div><p style="margin: 0px; text-indent: 0px;">
I don't like 2). It sounds like a hack.</p></div></blockquote><div><br>I don't like either! =) I simply don't know how to make paintOp's to think that a selection always has transparency channel set to 0 and to pay any attention to it's own transparency.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="font-family: 'DejaVu Sans'; font-size: 9pt; font-weight: 400; font-style: normal;">
<p style="margin: 0px; text-indent: 0px;"> And we will pay a high price for it, I fear. Lets go and think about a clean solution :) I think my proposal is close to what you mention in 1), except that I am unsure which grayscale color space you were thinking about, and for me it's clear that we have to keep mask/selection as single 8 bit uint channel. Since, for the reason you gave, alpha isn't the good colorspace, the only other colorspace that would qualify is "Grayscale 8bit without alpha".<br>
Using that colorspace, drawing a gradient will work nicely. What doesn't work, and anyway need to be fixed, is painting. The problem is that composite op are assuming that the source color space and the destination colorspace are the same, and when we ask for compositing pixels with two different colorspaces, then pigment silently convert the source to the destination colorspaces, and then call the composite op. What I propose is to change that behaviour, and allow to write composite op that work with two different colorspaces. We also have to change paintops to use Gray8Alpha for the dab when painting on a Gray8 colorspace.<br>
</p></div></blockquote><div><br>Yes, that's exectly what we need. But i don't know paintOp well enough to change them.<br><br><br>Let's define our task:<br><br>We need two (say, "new") colorspaces. First will work for KisSelection to store transparency data (let's call it TransparencyColorspace (TCS)). Second - for paintOps those are going to paint on the first colorspace (let's call it TransparencyPaintOpColorspace (PCS)).<br>
<br>What features do we need from them:<br><br>First cs (TCS):<br>- one channel (transparency), 8-bit<br>- during any paintOp painting, it should always be assumed that TCS has alpha() set to 0. BUT alpha() of the paintOp should be taken into account.<br>
<br>Second cs (PCS):<br>- two channels (transparency + alpha mask) (8+8)-bit<br>- ANY usual colorspace (like rgb, lab, etc) should be converted to this colorspace like to grayscale colorspace:<br>rgb -> transparency channel<br>
a -> alpha channel<br><br><br>It means that PCS colorspace can be represented by a usual grayscale8+alpha colorspace, but TCS should have some special rules...<br><br>Btw, is it possible to construct a one-byte colorspace, that has two channels, both are two bytes size, with alpha() ALWAYS returning 0-value?<br>
<br><br> </div></div>-- <br>Dmitry Kazakov<br>