Handling of alpha channels when processing CLF

[doug_walker]

@Thomas_Mansencal

That is where I was getting at, you would need to at the very least take a stance/decide on how the data will be processed and what should be the input for that process.

The proposal was that Matrix and Exponent would process alpha and the other ProcessNodes would just pass it through (like OCIO). So it is not very much additional language that needs to be added to the spec.

@Thomas_Mansencal

I don’t understand why OCIO elected to process alpha for some transforms and not others, this seems surprising, unelegant and the potential source of many issues, this is not the topic here anyway.

Alpha support was added to OCIO before my involvement with that project, so I don’t have the full story behind why it was added, but I do think there are some good reasons for it (per the examples I provided earlier in the thread).

@Thomas_Mansencal

Certainly, but what are those maths? Are you dividing RGB by alpha before applying the Matrix and Exponent Nodes? RGB and Alpha are obviously extremely correlated, so CLF will have to specify what should be happening here.

The proposal was to use the same equations for alpha that are used for RGB. For apps that don’t process alpha, they would effectively use the same formulas but with alpha set to 0. (But obviously their processing code could be written to ignore alpha entirely.) If the RGB needs to be unpremultiplied, that would be an application-level consideration. (Same as OCIO.)

@Thomas_Mansencal

I will bring this one again to: why just those two nodes? Why not the Range Node after all and all the others? I’m sorry but because OCIO supports alpha in two transforms is not a satisfying answer. I think it is much easier to take the lowest common denominator and simply ignore alpha.

As I detailed earlier in the thread, there are concrete use-cases for Matrix and Exponent. I’m not opposed to adding alpha to Range or the other ProcessNodes, but that would be outside of what I was proposing. I made the proposal because, as someone who needs to implement support for both CLF and OCIO, it is easier if the basic processing operators behave exactly the same for both.

Nick quite rightly made the point in the meeting today about complexity. As with our other discussions around CLF, we need to find the right balance. If the group feels that the added complexity is not worth the benefit, then I agree we should not add it. However, I do worry that people are thinking it is more complex than it really is. So in summary, the proposal is this:

1. Adjust the formulas for Matrix and Exponent to include an “A”, using the same math as for “R”, “G”, and “B” and adjust the XML syntax to allow the optional alpha parameters to be supplied.
2. Add a note saying that the other ProcessNodes pass alpha through unchanged and that pre-multiplication is an application-level concern.
3. Add a note that says that apps that do not process alpha are free to ignore the alpha parameters (as if the “A” in the equations was zero).

Hopefully this post clarifies what the proposal is and the motivation for it.

thanks,

Doug