for quite some time I am pondering with an alternative approach to open colour decision interoperability. Here is a proposal for a new linear light open-source colour decision specification.
I would love to know if you think this is any useful.
Proposal_Academy_Linear_Grade.pdf (730.6 KB)
Interesting proposal. Is there a reason you feel that a new container for these operations needs to be specified? Since they boil down to an addition and a 3x3 matrix, they could easily be expressed as a CLF. In which case the requirement would only be that colour correction and VFX vendors agreed to provide a mechanism to create, save, load and apply these operations for primary corrections using CLF. That plus education so people understood that this was the proper way to apply such corrections.
Mainly I try to avoid side care file handling for such simple thing as 10 numbers.
We have CDL pipelines in ALE, XML etc… CDL are 10 numbers, my proposal has ten number so should be very easy to reuse existing infrastructure.
CLF would be possible but quite possibly overkill.
Also from the software perspective, you can do much more interesting stuff if you know you expect just a matrix and an offset. CLF can contain much more, so you would need to distinguish normal CLF from CLF just containing the 10 numbers.
Fair points!
You say “Each post-production company and grading manufacturer could incorporate their own models and tools to calculate the 10 numbers.” Would you envisage including a comments field in the format, which could potentially describe in human and/or machine readable form the derivation of the ten numbers? If an ALG file contains a single 3x3 matrix, which combines exposure, white balance and other operations, might it be useful if a grading system which exported an ALG could read it back and break it into the original separate parts? Thus an ALG correction could be reloaded and edited by its creator or a compatible system, or applied “blind” by a non-compatible one.
Good idea.
I think it is quite easy to find out if a 3x3 matrix was derived from your own algorithm, software vendors could include such an option.
You can’t imagine how much I wanted this since I learned what CDL is! I’ve been always against white balancing using offset for (not-actually-true-) log footage because of its over-correction in the shadows. Probably because of my OCD 
Finally there is a chance to change it!
I think this proposal is really interesting. I have seen similar technical approaches used in certain VFX companies for “neutral grade” workflows, where a color adjustment is applied to plates in order to balance color, exposure, whitebalance, and flare prior to work. spimtx files were a popular choice for this because they work out of the box with OCIO and store a 3x3 matrix + 1x3 offsets in 16 bit integer code values (a bit weird, but functional).
The only potential drawback I could see with 10 number instead of a “3x4 matrix” like the spimtx file has is the lack of per-channel offsets. With digital cinema cameras I guess in most scenarios a color-balanced flare compensation would not be necessary, but I’ve definitely seen scenarios with film scans where it would be.
@daniele with your experience do you see this as uncommon enough to be unnecessary?
The ASC CDL is not suitable for directly modifying ACES Linear encoded files (both AP0 or AP1) - mainly because of the order of the gain and offset operations
I didn’t previously realize this, thanks for sharing that knowledge!
A standard 3x3 matrix + offset is the wrong way around I am afraid.
The RGB ratios in the bottom and are very sensitive to minimal R,G,B individual changes. We found that a constant offset is typically more save and does the job for most situations. But worth discussing more
Thank you Daniele, very interesting!
Without bringing this thread too much off topic, would it be possible to expand some more on the possible methods for calculating the IDT matrices?
Eg with which software is this possible and how is this done? (Using a colorchecker for calculating the matrices or is this too simple?)
Hi, I think this is not really a topic for this thread. The point is to make it possible to communicate production-specific IDT tweaks in a pipeline.
Just a humble artist here, but I think this is an excellent proposal. Current CDL spec is outmoded and promotes compromised creative choices, in addition to the limitations and workflow problems mentioned in the doc.
Hi Daniele, great idea. I was thinking about a similar topic, not quite as elaborated and not quite as long but for a few month. I am missing scene linearity bewaring operations in CDL, too. The simplicity of your proposal is outstanding. A question which raises in my head is, if the way the white balancing between the LMSish matrices is calculated and the way the saturation is applied, should be standardised as well between the applications. WIthout that, a communication with words about single parameters could lead to mistakes. Without considering this disadvantage the simple 3x3 system independent matrix is way cooler as you can add custom corrections inbuild nicely. In linear space saturation can cause negative values quite easily as you know so that would also be something to think about. From a colourists perspective I am also thinking how much more you want to add to the shot by shot matching factor, I was considering a post addition after the 3x3 in vec3(RGB) for possible shadow leveling issues. I know you disagree about that and you are probably right that this is too dangerous for a general system. Another add-on in question would be an as simple as possible highlight zone mapping or at least a softclipping, now in the days, where HDR previews and monitoring is more common. But difficult to accomplish in an easy way. Not sure what would be a good solution, besides a fixed more complex tool on which industry agrees on.
Thanks for the comments, these are all valid points:
I think it is the most important priority to not alter scene-linearity.
Specifying the primaries for certain tasks can limit the use-cases of such a tool, for only a marginal improvement of interoperability. And potentially it would stop people from innovating.
Significant modification of saturation and highlight compression, as well as coloured shadows, are more located in the Look Development part of the stack, in my opinion. Keeping CDL 2.0 simple will prevent you from doing too much as part of a technical grade. Such transforms can be easily communicated as LMT via CLF.
How is it going with CDL 2.0 progress? Is there a chance it could be presented as a part of ACES 2.0? I really like the idea of a scene linear alternative to CDL.
So, until CDL 2.0 is here, is it possible to use current regular CDL with ACEScg images? I mean I know I can use gain control only and it lets me adjust the exposure without breaking scene linearity. But can it be done on set during production for example? And can it even be called CDL? Or CDL should be applied to a log footage only, if I still want to call it CDL? How legit is using CDL AND calling it CDL that is applying to ACEScg?
Or probably for VFX round-trips at least?
Mu goal is to make some basic balance with CDL controls for the shots that will be sent to VFX. So VFX artists could see the image with the corresponding CDL in Nuke. But I want to do it in a scene linear. Can I just send them CDL and tell them that they should apply it over ACEScg and still call this CDL?
Thanks!
The ASC CDL spec specifically does not define what encoding it should be applied to. It is up to the user to specify that as part of their pipeline design. So applying CDL to linear data is perfectly valid, as long as everybody who has to apply it knows that’s what you have done. But the same applies with any CDL. You need to communicate if it was applied to ACEScct, ACEScc, LogC, or whatever.