[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Problems with "embedded" transparency masks onto adj. layers
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2009-09-08 14:28:20
Message-ID: ae32c1ef0909080728x357e8756p3c9cf32f6d08b12d () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> > There are two solutions for that.
> >
> > 1) Most obvious way. Just use grayscale8 colorspace for KisSelection's
> > paintDevice. The second problem will be solved in a natural way. But
> > this system has a huge drawback. Much code of Krita uses direct access
> > to selection's transparency pixels (that is not so good in general).
> > The calls are done like:
> > selection()->pixel()->alpha()
> > ALL THIS CALLS will have to be changed to:
> > selection()->pixel()->gray()
> > That is possible, but quite difficult.
> Any code example of that ?
>
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.
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...
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).
As KisSelection should be change to use pointers (or NOT USE defaultPixel()
stuff at all), it's not a big deal to fix it.
The only thing i'm afraid of such assumptions can be present somewhere else
in the code =(
> 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 ?
>
Yes, i'm just afraid of the code with strange assumptions. =)
> > 2) The second way is not so obvious and needs some help from
> > Cyrille. This solution leaves KisSelection's paintDevice in alpha8()
> > colorspace. BUT all the painting and bitBlt'ing into this device will
> > be done through a special type of a grayscale colorspace, let's call
> > it transparencyColorspace(TCS). This TCS will have two channels: gray
> > and alpha. Gray-channel accumulates rgb-values of the brush and alpha
> > channel controls the shape of the brush. The only difference of TCS
> > from usual grayscale CS is the way it is converted into alpha8() CS.
> >
> > Usual grayscale CS:
> > GCS alpha8()
> > Gray -> [/dev/null]
> > Alpha -> alpha
> >
> > Our TCS:
> > TCS alpha8()
> > Gray -> alpha
> > Alpha -> [used by compositeOp's]
> >
> > The question is: which way to choose?
>
>
>
> I don't like 2). It sounds like a hack.
>
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.
> 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".
> 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.
>
Yes, that's exectly what we need. But i don't know paintOp well enough to
change them.
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.
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, but TCS should have some special rules...
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?
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<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>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic