<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-style:normal;">On Tuesday 08 September 2009, Dmitry Kazakov wrote:<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>
No they are not, what I see when greping is call to QColor::alpha()<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> There is one more issue with gray8+alpha colorspace for selections.<br>
> 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<br>
> bad itself. And, alll the same, KisSelection should be changed a bit. (we<br>
> have a bug connected with it somehow).<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Yes selection pixel should be single-byte.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> Let's define our task:<br>
><br>
> We need two (say, "new") colorspaces. First will work for KisSelection to<br>
> store transparency data (let's call it TransparencyColorspace (TCS)).<br>
> Second - for paintOps those are going to paint on the first colorspace<br>
> (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<br>
> alpha() set to 0. BUT alpha() of the paintOp should be taken into account.<br>
Why should it assume that alpha is set to 0 ? Otherwise, we have it, it's "GRAYU8".<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>If we have alpha == 255, we could be able to draw directly on that colorspace.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> 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<br>
> colorspace like to grayscale colorspace:<br>
> rgb -> transparency channel<br>
> a -> alpha channel<br>
><br>
> It means that PCS colorspace can be represented by a usual grayscale8+alpha<br>
> colorspace, <br>
yes.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> but TCS should have some special rules...<br>
Which ones ?<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> Btw, is it possible to construct a one-byte colorspace, that has two<br>
> channels, both are two bytes size, with alpha() ALWAYS returning 0-value?<br>
It's possible to have a colorspace whose alpha is always null. But why a second channel, then ?<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>-- <br>
Cyrille Berger</p></body></html>