Painting on selections and selection masks

[Boudewijn Rempt]

On Friday 28 October 2011 Oct, Dmitry Kazakov wrote:
> On Fri, Oct 28, 2011 at 9:51 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
> 
> > On Friday 28 October 2011 Oct, Dmitry Kazakov wrote:
> > > Cyrille, is it possible to have a composite op which has different source
> > > and destination colorspaces?
> >
> > colorspaces can convert the pixels from another colorspace to their own
> > before doing composition, but for painting on masks that's not currently
> > useful since we generate dabs in the target colorspace anyway.
> >
> 
> Well, the colorspace of a dab is really not a problem, i guess. A node can
> have both paintDevice() and dabColorSpace() methods. And tools can use the
> latter one to create a dab of a proper colorspace.

I'm not convinced that we're just having problems with dabs -- I think it's a more general problem, that shows up everywhere in krita where we manipulate paint devices.

And there's no need to actually solve it at the node level, that's too high up. And even on the paint device, there's no need to add a separate api to get a colorspace that's useful for dabs, if we only do something special-cased for dabs, then it needs to go into that specific part of the code.

Then we can check whether the colorspace of the device has an alpha channel, and if not, use one with an alpha channel, which then gets converted during bitBlt.

But as I said, I tried that, and it was messy and didn't solve the problem generally.

> > The real issue is not the conversion, but that krita cannot handle
> > colorspaces without an alpha channel -- or colorspaces with alpha
> > pre-multiplied, which this would be, I guess. This is, I think, a limitation
> > that permeates Krita everywhere.
> >
> 
> Well, if we decide to have different colorspaces for a dab and a paint
> device then we will avoid this limitation.

But only for painting, only for this case. I do not think it's a good idea to expand the api of KisPaintDevice with something special-cased for dab creation.

> > For 2.4, it's certainly not something I see feasible to implement. Nor am I
> > confident it would be a good idea: it was a conscious design decision back
> > then. It's why we always have cmyka, never just cmyk.
> 
> 
> I'm sure we shouldn't hurry with such decisions. Especially, after we have
> released several betas.

No -- but not being able to properly paint on selections and masks is a critical bug, which is why I have tried to find a minimally invasive way to make it possible, mostly contained in KisSelection. Unfortunately it means we triple memory usage for selections, so we have to think whether that's worth it.

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl