Problems with "embedded" transparency masks onto adj. layers

Cyrille Berger cberger at cberger.net
Tue Sep 8 23:39:57 CEST 2009


On Tuesday 08 September 2009, Dmitry Kazakov wrote:
> There are some more uses of alpha() reported by:
> fgrep 'alpha()' -R ./ |grep -v doc |grep -v svn
>
> maybe, they are not connected with it...
No they are not, what I see when greping is call to QColor::alpha()

> There is one more issue with gray8+alpha colorspace for selections.
> KisSelection uses
>
> quint8 defPixel = *(m_d->pixelSelection->dataManager()->defaultPixel());
>
> 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).

Yes selection pixel should be single-byte.

> Let's define our task:
>
> 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)).
>
> What features do we need from them:
>
> First cs (TCS):
> - one channel (transparency), 8-bit
> - 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.
Why should it assume that alpha is set to 0 ? Otherwise, we have it, it's 
"GRAYU8".

If we have alpha == 255, we could be able to draw directly on that colorspace.

> Second cs (PCS):
> - two channels (transparency + alpha mask) (8+8)-bit
> - ANY usual colorspace (like rgb, lab, etc) should be converted to this
> colorspace like to grayscale colorspace:
> rgb   ->   transparency channel
> a      ->   alpha channel
>
> It means that PCS colorspace can be represented by a usual grayscale8+alpha
> colorspace, 
yes.

> but TCS should have some special rules...
Which ones ?

> 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?
It's possible to have a colorspace whose alpha is always null. But why a 
second channel, then ?

-- 
Cyrille Berger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090908/f38c9ab9/attachment-0001.htm 


More information about the kimageshop mailing list