Problems with "embedded" transparency masks onto adj. layers

[Dmitry Kazakov]

> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090908/491942b7/attachment.htm