Problems with "embedded" transparency masks onto adj. layers

[Cyrille Berger]

Hi Dmitry,




On Friday 04 September 2009, Dmitry Kazakov wrote:
> 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 ? 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 ?




> 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. 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.




-- 
Cyrille Berger
















































-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090908/8cc89fe5/attachment.htm