This sparked some questions for me…
A) Is a CLF implementation supposed to process alpha channels? How? What is done for other nodes if alpha is present?
B) Is this the only node that has a sub-element with a channel attribute? This, the new Log node, and ASC_CDL are the only nodes that have Params elements. In SatNode element in ASC_CDL, we mention that if not present, the default is 1.0 for all channels, but say nothing about an ability to supply more than one value for different channels. Are we missing anything or have I just been looking at this thing for too long?
The rest of the suggestions have been addressed. Thanks.
That is a non-negligible detail, my assumption was that alpha and other channels would be passed as is and ignored. If allowing alpha, why not allowing depth, mattes, etc… you see where I’m going with that.
I agree. This was honestly the first time I’ve heard mention of alpha channels in any of the group’s conversations - so I definitely wanted to make sure that I wasn’t missing something. It may have been discussed during v1 and v2 of the spec, but not during the present work revisiting the spec.
I had never even considered it, but I rarely deal with alpha since I’m not doing VFX work. I guess my assumption was the same as yours - that non-RGB channels were passed through unaltered. Would it ever even make sense to manipulate the alpha channel in the same manner as the RGB channels?
The spec needs to address this one way or another - we cannot assume that the intended behavior will be inferred.
It is a giant can of worm and pandora box to open, e.g. associated un-associated alpha, multi-channels, etc… This is not really the realm of a LUT specification or maybe it could be but this would be significant.
My goal regarding alpha is to try and keep CLF in sync with OCIO. In OCIO, the Matrix and Exponent transforms process alpha. (Sorry for not mentioning it earlier, I forgot that CLF Matrix didn’t already handle alpha. Scott, please take another look at the CTF documentation for more a detailed description, including for Matrix.) Although the Log transform can take a similar params element, that should remain RGB-only, same for CDL.
Also, at the end of the “channel” section, please append to the last sentence: “except alpha.” In other words, by default alpha is not affected.
In what way it is processed? I don’t see any effect in Nuke when using the OCIOColorSpace node and applying a transformation represented by a matrix in the OCIO config on an image with alpha.
Why those transforms and not the others?
Thinking out loud here: it does not seem wise to impose alpha handling/processing to the whole industry because OCIO supports it for two transforms.
Thomas, it is possible to set alpha values for the Matrix and Exponent transforms in OCIO. (This is not a new v2 thing, it has been there from the start. It was used in the DisplayTransform, for example.) I know it works and there are unit tests for it. The default coefficients result in no change to alpha, so you will need a config or transform that specifically modifies alpha in order to see a change.
As for why those two transforms and not others, I suspect it was because those are the main two transforms one would typically want to apply to an alpha channel. For example, the Matrix could be used to invert an alpha or move alpha into the other channels for viewing. Likewise, the Exponent could be useful since sometimes people mistakenly apply a gamma to an alpha channel that then needs to be removed.
It’s clearly useful in OCIO since it allows an entire display pipeline to be built in OCIO. As to whether it should be in CLF, I think the VWG should discuss it. Perhaps the meeting time could be adjusted to facilitate Thomas’ participation from NZ.
For apps that don’t process alpha, it is simple enough to ignore it. So I don’t quite agree with the statement that it would be “imposing it on the whole industry”. But I agree it should be discussed. As I wrote in my previous post, when making my Exponent comments I had forgotten that CLF Matrix did not already process alpha.
I don’t deny that at all, I’m just saying that I could not get that to work in Nuke which is one of the largest OCIO app by user base. Does it work with Maya?
If it is optional behaviour, we are all good I guess, if not, this is an important problem. Given Scott and I reactions, it is not clear whether it is optional or required. My worry with handling extra channels is that if you were to process an image with two different applications, one processing the alpha and one passing it untouched, you would get two radically different images. It is a recipe for a ton of late nights debugging which we will surely agree is not a good thing, we are getting old
Sorry, I don’t know why it’s not working in Nuke. One option is to use the ociodisplay tool that comes with OCIO to see an example of alpha being processed.
I agree with you that it should not be optional if the app is processing alpha. What I meant was that for apps that don’t process alpha, they could ignore that aspect of the processing (which they already do anyway essentially). I agree that we don’t want to require RGB-only apps to add alpha support just to support CLF, it should only be something for apps that already process alpha. Topic for discussion …
@sdyer : I won’t make it to the today call (4am…) but here are some thoughts and an answer to previous Doug’s comment:
I still don’t like the fact that you might have two different results, e.g. what about the app that just pass the alpha untouched? You might also be reading a multi-channel EXR file in an application, modify RGB and pass everything else untouched, e.g Z, IDs, etc… or maybe not? If you modify the alpha, do you un-premultiply RGB before, wait, is it pre-multiplied to start with? How do you know? What does the alpha channel actually represent? So many questions that I would not dare touching that with a ten foot pole.
I suppose you could argue that with any LUT if you pass it the wrong data you get the wrong result. However with CLF we are trying to make the standard robust, so it is easier for an app / user to ensure that they do pass the LUT the expected data. So if you do include alpha handling, you then need to add a load more tags to describe how it should be applied. That would be too much in my opinion.
Regarding alpha, my proposal was intended to align CLF with what OCIO does. I would argue that the problems you raise are not an issue in OCIO and so they would also not be an issue for CLF.
For example, pre-multiplication is a higher level concept that is important at an application level but the color management system doesn’t need to care. For CLF/OCIO we don’t need to specify whether the alpha channel is pre-multiplied or not, just like we don’t need to specify whether the R channel is linear, log, or something else. CLF simply specifies the math that should happen.
Likewise, the issue about apps giving different results if they process RGB or RGBA would be the same for CLF and OCIO. If you have a config that does something with alpha and process RGB-only then you would get a different result in OCIO too. I don’t think this is a show-stopper for including alpha in CLF.
Likewise, how to process multi-channel EXRs is an application-level problem. It is not something that either CLF or OCIO need to consider.
Nick, what do you mean about needing to “add a load more tags”? OCIO does not allow operators other than Matrix and Exponent to affect alpha, so my proposal would not affect the LUT or other operators. Is that what you were referring to?
As I proposed before, it would be nice to be able to discuss live. I wonder if we could have a meeting that would be at a more friendly hour for NZ?
I was imagining that in the same way the inputColorSpace tag can tell an app how to transform the image data before the LUT, something similar might be needed to say “this expects premultiplied image data”.
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.
CLF is not OCIO and OCIO is not CLF, I have an extremely hard time understanding why CLF should comply with OCIO. 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.
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.
Well, I would argue that how alpha is processed is an application-level problem and that CLF should certainly not consider it (and same for OCIO).
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.
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.
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).
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.)
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:
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.
Add a note saying that the other ProcessNodes pass alpha through unchanged and that pre-multiplication is an application-level concern.
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.
It does especially because, you mentioned your proposal a few times but I did not really find defined points like the aforementioned ones.
I’m not convinced that the examples you gave are worth complexifying the spec and introduce potential processing discrepancies between applications. My points against the proposal are as follows:
Alpha processing is added to CLF with the only reason being parity with OCIO
Because of that parity, some nodes effectively process the alpha, some others don’t which is arguably inconsistent and adds complexity to the CLF specification AND implementation
It will be the source of significantly inconsistent output between applications using CLF (which I find orthogonal to the purpose of CLF and ACES in general)
There are a few secondary points but those are probably the key ones to me.
Thank you for bringing the alpha channel to my attention. Like Scott, I haven’t consider it so far. beyond affecting the range (e.g. from [0,1] to [-1,1]), of change in number encoding (e.g. from float to10bit unsigned integer), I can’t see why one would like to apply a transform to the alpha channel. If someone could enlighten me (or us), that would be great.
I don’t have the full history of why it was originally added to OCIO, but one of the uses there which I think explains its utility is in a class called DisplayTransform. The DisplayTransform is intended to be an example viewing pipeline for a vfx-centric app. Typically these apps want to allow the user to view the alpha channel in a diagnostic-type way. For example, bringing the alpha into the RGB channels (i.e. a matrix) and modifying the contrast (i.e., an exponent). Although you could argue those operations are outside the typical purview of color management, the fact that they are possible means that the entire viewing pipeline can be done within OCIO. That simplifies app development and encourages consistency between apps.
All of that said, it’s clear from the comments here that people are not wanting to deal with alpha in CLF. Therefore, I’m withdrawing the alpha proposal.
Nevertheless, in general I still do think it’s desirable to encourage the use of common math between CLF and OCIO, and if I encounter any other differences I will continue to try to bring them to the attention of the working group.
Just to be clear I’m against it mainly on the premise that we would add that for getting compatibility with OCIO. If CLF needs to handle alpha, then alpha handling should be a first-class citizen of the CLF specification, not an afterthought we add at the last minute because it is convenient for application X or Y, hence the all or nothing for consistency purposes. I hope it makes sense.
