Solution for the grayscale selections

[Dmitry Kazakov]

On Tue, Sep 25, 2012 at 4:30 PM, Boudewijn Rempt <boud at valdyas.org> wrote:

> I think you need to take a step back from the proposal you came up with a
> year ago and take a look at the big picture, because since then we have
> learned a number of things.
>
> The problem itself should be redefined as "we need to be able to handle
> colorspaces without an alpha channel", not we need to figure out a trick
> to make painting on selections work.
>

Wait, as far as I remember we were talking exactly about "how to make
grayscale selections work".

If you want to change the topic of the project, please express this more
clearly, than just putting veto on the idea and suggesting
intermediate-projections-in-kis-selection solution.

If we want to mix this work with optimization, then we should call it a bit
differently: "we need to be able to handle
colorspaces with a *separate* alpha channel".

On Sunday I thought about an idea of passing the separate alpha to bitBlt
as well. Here are the conclusions which I came to:

1) It will give us *some* opportunities for structural optimizations. We
will be able to handle the case of uniform coloring (the most common case)
much more efficiently. I can't tell how much speed it will give.
2) It will *not* give us much opportunities to use vectorization, because
the pixels in the layer will be laid out in a standard way. Only scaling of
the whole mask will be optimized here.
3) We will still have to use something like
KisPaintDevice::paintingColorSpace() or KoColorSpace::paintingColorSpace()
to get a colorspace for the other components of the pixel *or* store the
alpha mask twice: both in pixels and in a separate mask.
4) The KisToolFill and KisToolGradient will need changes as well.

I dropped this idea then because I though it would demand too much changes
and take too much time.



> * Limiting the brush mask to 8 bits integer precision makes painting on
> higher bit depth colorspace paint devices lose precision.
>

This is a completely different problem and can be solved separately after
we implement any of the suggested ideas.


> If we take the alpha channel out of band, then pass the brush mask as an
> alpha channel as a separate parameter to KoColorSpace::bitBlt, we'll
> actually have solved the problem in a generic way, without adding hacks to
> KisPaintDevice.
>

Well, it is not too generic actually, because it either adds
paintingColorSpace() method to the color space or a paint device, or it
duplicates the alpha value in both: in pixels and in a mask for regular
RGBA devices. Despite that fact, I don't object implementing this idea,
because of the opportunities, that we can get with the structural
optimizations mentioned in 1).

Ok, if you want I can think about this idea. But its implementation will
take quite much time.



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