Painting on selections and selection masks

[Dmitry Kazakov]

Hi!

I've been doing quite a bit of work in this area, first building on Sven's
> branch, then doing some other experiments. Here are my provisional
> conclusions and a proposed (less than ideal) solution:
>
>
> * tools cannot handle colorspaces without an alpha channel. We cannot
> generate a dab, we can't do anything. It's a limitation in our design.
> * pigment cannot handle masks with more than one channel. Again, nothing we
> can do much about.
> * the actual problem when painting on a gray without alpha colorspace
> paintdevice isn't the color conversion code or the bitblt implementation but
> that we cannot generate the right dabs or interpret the canvas correctly for
> painting. Again, we need an alpha channel to be able to paint.
>
> Just fixing the gray-without-alpha colorspace, or adding a special
> composite op will not fix the problems...
>

Well, could you elaborate a bit on these problems. I see it to work as
follows (point me where I'm wrong):

1) Grayscale masks have single channel, that is treated by selections as
usual.
2) When a tool decides to paint on a mask, it creates a dab, that is
generated in a usual two-channel grayscale colorspace (the "bit'ness" of the
colorspace should coincide the same parameter of the mask, I guess,
currently, for selections we have 8 bit channels without any options).
3) When a tool paints on the device, it uses special composition(s):
grayscale_two_channel over grayscale_one_channel.
It may look like (it's disputable which formula to use):

C_output = C_2 * alpha_2 + C_1 * (1 - alpha_2),
where
*_2 indexes refer to "2-channel" colorspace of the dab
*_1 indexes refer to "1-channel" colorspace of the mask


What is the problem here? Tools can get a colorspace of the dab for the node
using an additional method of KisNode. We can add it if needed.




>
> I have tried to special case the painting code to generate a dab in graya
> and then convert to gray and then bitblt, but I disliked the fact that we
> then need to check all over the code for problems handling colorspaces
> without alpha.
>
> I took a look to see how hard it would be to make krita just work correctly
> with colorspaces without alpha but I gave up on that. Not feasible for 2.4,
> maybe just not feasible.
>
> I'm right now trying the following solution:
>
> * make KisPixelSelection have a gray + alpha colorspace and use this for
> creating selections
> * create a KisSelectionProjection class which is used for masking.
> KisSelection::projection returns an instance of this class
>
> This seems to be promising: I have a problem with the extent calculation of
> KisPixelSelection if it's graya, but apart from that nothing major. I think
> I can make this scheme work in time for 2.4.
>
> However, this means that a simple raster selection now takes not one, but
> _three_ bytes, and that there's always the step of generating the
> projection, which takes time.
>
> On the other hand, in the future it would make it much easier to make it
> possible to add, say, a blur filter mask to a transparency mask or apply
> filters to masks.
>
> On a sidenote: the outline generator needs to be rewritten so it doesn't
> need a copy of all the bytes in a selection as a buffer but to use a paint
> device. This is wasteful of memory.
>
> I've attached the current patchset, it doesn't work, but does give you a
> general idea.
> --
> Boudewijn Rempt
> http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
>
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20111028/593590f5/attachment.html>