Selections on the Adjustment layers

[enki]

Boudewijn Rempt wrote:
> On Wednesday 02 September 2009, enki wrote:
>   
>> - But we can also see things the others way around: Paint layers and
>> Shape layers have built-in transparency too. So maybe it's is more
>> logical to put a built-in transparency mask in other layer types.
>>     
>
> Well, that's a different sort of transparency, or rather, two: the alpha 
> channel of a layer and the layer's opacity. Although here implementation 
> details might peep out into the user interface, which is generally a bad 
> thing. So, right now, the opacity of a pixel in a paint layer is determined by 
> three things:
>
> * the alpha channel of the pixel (which is set during painting)
> * the opacity value of the layer (a layer-wide property)
> * the opacity value of the 0 or more transparency masks associated with that 
> layer (possibly created from the alpha channel, or from a global or local 
> selection).
>   
Ah thanks for the explanation it's clearer for me now.
I was speaking about the alpha channel. I understand that technically 
it's different, but from an user point of view it's always "show a pixel 
depending of the value of a pixel". To me a selection, a mask or a 
channel is always a kind of greyscale pixmap...but I guess that view of 
thing won't work anymore with transformation masks.
>   
>> - Any layers can have a mask and it always works the same way.
>> - Adjustement layer are created by default with a child mask.
>> - A mask is a channel of the current layer:
>>     
>
> I have never been able to understand that part of Gimp or Photoshop -- it 
> always seemed to me as if masks in those applications were a kind of 
> historical outgrowth of the alpha channel instead of something in their own 
> right.
>
>   
Yes, I have the same feeling. Gimp's channel/mask handling especially 
brings bad memories.
>> Now to resume my thinking :
>> - All masks must behave the same way, even if built-in a special layer
>>  type. - The current filter layer built-in mask is almost unusable :/.
>>     
>
> I think that's mostly an implementation issue, really.
>
>   
Good to hear :)