Painting on selections and selection masks

[Cyrille Berger Skott]

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.

> 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.

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

-- 
Cyrille Berger Skott