Painting on selections and selection masks

[Boudewijn Rempt]

On Saturday 29 October 2011 Oct, Cyrille Berger Skott wrote:
> On Friday 28 October 2011, Boudewijn Rempt 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?
> 
> To complement Silvio's answer, it is not possible with the current design, 
> however, I think it is a desiberable feature. I think the current composite 
> ops would simply declare them as having the same colorspace for source and 
> destination and would keep working as usual.
> 
> > 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.
> > 
> > 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.
> 
> There is no problem for Krita to handle pre-multiplied colorspaces,  since a 
> premultiplied RGBA, is actually defined as (a*R, a*G, a*B, a). And if there is 
> such an assumption, it is a bug ;) It would mean that somewhere Krita makes 
> assumption about the color data.

It's either a bug, or a design decision that permeates all our code. Either way, it's not feasible to refactor, redesign or fix for 2.4.

> 
> > This is, I think, a
> > limitation that permeates Krita everywhere.
> > 
> > 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.

> It makes sense for "user-visible" color spaces. I can't count the number of 
> PS/Gimp tutorials that I have seen that start by saying: "right-click on the 
> canvas, and then select 'add opacity channel'" (or something like that). In 
> 2011, there is no point in trying to save a few bits of memory.

Well, we're talking about megabytes of memory, in a 5000 x 5000 image, it's 25.000.000 bytes... But it's moot anyway: Krita cannot work with colorspaces without alpha or premultiplied alpha. I

> 
> However, for internal color spaces, that is a totally different story.
> 

The big thing missing from this discussion is this:

* we are talking about a 2 year old critical bug
* we are one month away from the final release
* we have tried the following solutions:
	* fix the gray colorspace
	* fix he alpha colorspace
	* special case dab creation
	* patch over the difference in design assumptions inside KisSelection
* everything failed except the last attempt, which has its disadvantages
* we cannot do a big refactoring of pigment or all of Krita in time for the release.

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