Hi @Carmelo_DrRaw, I know next to nothing about this, but maybe this is useful?
https://learn.foundry.com/nuke/content/reference_guide/color_nodes/ociocdltransform.html
From what I understand, nuke allows the user to select the working space, but it defaults to linear. Maybe that means something? 
1 Like
It might mean that “a flexible standard is not a real standard”? 
Based on my reading, the ACES and OCIO way is extremely freeing. The user could tweak and use any combination of settings to their hearts content at any point of the workflow to suit their input, output, processing and viewing needs.
However, this portability and flexibility requires the user to have a deep grasp of how the colours and dynamic range contort, which I think is still a work in progress for industry professionals. They seem to be in discussion with colour and tech experts all the time.
There is a hint of that in one of the PDF links I made a while back but it is just a passing mention with no details or leads. I think that that is the most frustrating thing during my investigation. We talked about it, isn’t helpful for “outsiders” like us. 
ACES and OCIO are not married to each other - each can be employed without the other. In particular, an ACES workflow can be implemented using ICC profiles, assuming one is willing to accept the idea that unbounded ICC profile color spaces are not somehow breaking some profound rule of the universe.
This is just a guess, but being able to tweak and use any combination of settings to one’s heart’s content somehow seems not consistent with ACES goals of being able to easily share results across a range of diverse camera inputs plus sharing results of processing by different groups for different stages of a movie’s production. This is not to say that creative efforts within the workflow are somehow limited, but rather that all the individual creative steps need to fit within the set goals of archiving, future-proofing, and standardizing the exchange of output from each step in the pipeline.
Indeed, I have made a very general statement but it is not far from the truth in how ACES and / or OCIO is being talked about. I, too, would like to see more specific, precise, clearer and kinder language.
Ah, but in a way, that is the nature of the beast. That is why OCIO esp. is so difficult to talk about. Of course, when it comes to production, my guess (I am scratching my head too) is that a team would be responsible for deciding and developing the processing and transformation standard for any given project. That way all the separate teams would have the metadata and colour spaces on their devices before everything else. Ideally, given the flexibility, they should be able to change the underlying system without affecting the work of others because the data is supposedly intact.
At least that is what I have gathered so far. Sorry for being so unappealingly non-technical but I feel that a general discussion is also relevant. In the end, I admire everyone’s persistence in figuring out the details. 
I am simply too burnt out on the regular basis to understand the math and programming parts. If life circumstances were different, I would be right there and in step with you all but alas.
@afre - my apologies if my comment regarding “unbounded ICC profile color spaces are not somehow breaking some profound rule of the universe” was not kind. The bulk of my communications with Troy over the years has been on this topic and despite my best efforts I just don’t see why 1+1=2 except when using an ICC profile, in which case it seems that 1+1 must equal 1.
Judging from an email I got this morning apparently someone or perhaps more than one person on this list sent an email to Troy about something I said, and I’m guessing it’s my post quoted above regarding ACES and ICC.
Whoever you are, please feel free to post any substantial content about ACES/ICC/OCIO that Troy provides you, preferably in a new thread. FWIW “bullsh*t” does not qualify as substantial content. I’d very much like to discuss as openly as possible various issues in Troy’s presentation in this forum of ICC profile color management, and that discussion is completely off-topic wrt to the central questions of this particular thread.
Returning to the topic of this thread, @Carmelo_DrRaw said this:
I took a lot of math and science courses at University (not the dumbed down versions they serve up these days to humanities students). But that was a long time ago and these days I have to put stuff into a spreadsheet and draw graphs to see what’s going on. Well, that always was the case, equations per se just don’t conjure up intuitive pictures for me.
But what you said in the above quote puts all the stuff about ASC-CDL into a completely different light. The primaries matter a lot - there’s a reason why AMPAS decided to add ACEScg/cc/etc to augment the main ultrawide gamut “ACES” color space.
The “TRC” for want of a proper general term also matters - the RGB encoding, be it linear, log, “gamma” or whatever, that also matters. You are saying that changing the slope of linearly encoded RGB keeps the intensities proportionate to intensities in the scene. This sort of operation would not cause random hue/saturation changes. And applying a log2(c) offset to log-encoded RGB is mathematically equivalent?
On the one hand, from the perspective of being a photographer who’s camera input profiles are linear, and who for years has used a linearly-encoded RGB workflow, based on information learned long ago from the VFX people regarding gamma artifacts in general, and from photographers regarding specifically the issue of hue and saturation shifts, this whole idea of taking linear data and applying a log transform seems weird.
On the other hand, apparently video cameras do save the demosaiced and/or raw file frames already encoded logarithmically, similar to cineon and such film-based log encodings, yes? no? sort of?
Rather different starting points! That, by the way, was one of the take-away points from that nice ACES Primer I linked to - the fact that the ACES workflow had to accomodate two very diverse groups of people, VFX on the one hand, and people working directly with camera-saved film or log-encoded digital data.
Here is a simple spreadsheet example that shows what I am saying. The ACES → ACEScc → ACES formulas are taken from here.
I took a linear ramp in ACES, converted the values to ACEScc, added a constant value of 0.1 to ACEScc, then converted back to ACES:
As one can see, adding a constant in ACEScc is equivalent to scaling the ACES values.
Therefore, the ASC-CDL adjustments (for example the offset) have a completely different meaning when applied to ACES or ACEScc…
1 Like
This post from Troy says the CDL adjustments are not supposed to be done on linear RGB, and given that adding a constant on log-encoded is the same as scaling on linear, presumably the RGB really should be log-encoded:
The discussion of CDL uses the terminology lift/gamma/gain. Is one of these three the same as adding a constant to log-encoded RGB?
hi again, some more evidence that CDL is supposed to operate in scene referred linear space (as I was suspecting):
Doe Blender maybe add the log2 encoding to the linear RGB before applying the CDL?
This article from the ASC website discusses the whys/wherefores and also the limitations of CDL operations:
https://theasc.com/ac_magazine/October2008/PostFocus/page1.html
The article does mention using both linear and log-encoded RGB, but doesn’t say anything about when or why. But adding a constant to linear RGB just raises the whole original curve by the same amount, which would make colors less saturated and brighter, hugely different result than increasing the slope and keeping the 0-point constant.
The article is from 2008, so surely changes have been made since then.
I suspect that what Troy calls LGG in his post is the same as in this other post of him in the Blender stackexchange forum, the same to which @agriggio also refers.
It seems that lift/gamma/gain in Blender is different from ASC-CDL, which is there called Offset/Power/Slope. Troy says explicitly that “Also, the input to the CDL node must be scene referred RGB ratios.”
I guess @agriggio also refers to this specific sentence…
Too bad that Troy is not here anymore!
EDIT: adding a constant to log2-encoded data is equivalent to a gain adjustment in linear RGB
that, the multiple references to “scene referred data”, and the fact that all the illustrative plots are in linear scale…
@Elle @agriggio here is some more math for your pleasure… 
we have already seen that this chain of operations
linear RGB -> log2 RGB -> log2 RGB + offset -> linear RGB
is in fact equivalent to a simple scaling of the linear RGB values.
In fact, the properties of log functions are such that this other chain of operations
linear RGB -> log2 RGB -> (log2 RGB) * C -> linear RGB
is equivalent to
(linear RGB)^C
or in other words a linear scaling of the log2-encoded data is equivalent to a power function in linear RGB. This is because
x = 2^(log2(x))
2^(log2(x^c)) = x^c = (2^(log2(x)))^c = 2^(c * log2(x))
Hence
log2( x^c ) = c * log2(x)
There is therefore a very clear and direct relationship between CDL operations in linear and log2 encoding:
- offset in log2 encoding → slope in linear encoding
- slope in log2 encoding → power in linear encoding
However, there is I think now simple log2 equivalent of the offset in linear encoding. Moreover, power in log2 encoding does not correspond to any simple expression in linear encoding.
All-in-all, I am even more convinced that those CDL operations should be applied to linear RGB data.
Next question is: which RGB primaries should be used? A very wide colorspace like ACES, or a more narrow one like Rec.2020 or ACEScg?
@Carmelo_DrRaw - thanks! for posting above - I was wondering about what might be equivalent to what. The Wikipedia article says nine operations, slope/offset/power applied to each channel individually. I’m feeling very mathematically stupid at the moment, worse than usual! So is below correct?
-
Multiply/divide by a color (including gray):
offset in log2 encoding ↔ slope in linear encoding -
Add/subtract a color (including gray):
offset in linear encoding → ??? in log2 encoding -
Raise each channel to a (same or different per channel) power:
slope in log2 encoding ↔ power in linear encoding -
power in log2 encoding → ??? in linear encoding
What does raising to a power in log2 do to the image? Similarly to linear but affecting different intensities by different amounts?
Also, the Wikipedia article says “out = ((in times slope) plus offset) raised to the power”. So assuming my verbal descriptions of each operation are correct, in linear RGB the result is multiply/divide by a color (aka change white balance), then add/subtract a second color, then raise the resulting channel values to the specified per-channel power for each channel?
Do you remember that email conversation we had regarding the effect of applying a gamma correction differentially affecting each RGB channel? Identity produced horrible results. I seem to recall ACES wasn’t much better. ACEScg or Rec.2020 would be better simply because of the primaries. Or user choice, depending on what standard(s) you might want to follow.
Edit: Speaking of standards, this page with the indicated search terms:
brings up this book:
http://catalog.oscars.org/vwebv/holdingsInfo?searchId=9&recCount=50&recPointer=2&bibId=101887
The filmmaker’s guide to digital imaging : for cinematographers, digital imaging technicians, and camera assistants / Blain Brown.
which
covers new industry-wide production standards such as ASC-CDL and the ACES workflow.
My old Firefox browser doesn’t seem to show a button to show the table of contents. But I think when looking at the page using a newer version of Firefox, there was an entire chapter on ASC-CDL. FWIW, not sure if the book is available outside ASC channels. Oh, wait, here it is on Amazon so maybe libraries also might have a copy:
The handful of Amazon reviews are pretty funny. Maybe sending off to the ASC is the best way to get the actual equations and suggested color space encoding and primaries.
Oh heavens. Now I’m passing on information from Troy. I do wish he’d rejoin the forum and just change his methods of argument and discussion.
It does seem that linear or log are both OK to use, based on perusing what looks like totally reliable documentation. When used on log encoding, that offset thingy has to do with something called “printer points” that I seem to vaguely recall might be discussed in the ACES primer.
If I see anything about the actual primaries, I’ll add to this post - nope, no mention of any color space except Rec709 as far as I can tell.
Also see this link that Troy provided:
https://github.com/imageworks/OpenColorIO/issues/407
@troy_s who isn’t here anymore - did I miss anything that should be posted here? I haven’t looked at the actual equations, but hopefully you also sent/will send appropriate information to @Carmelo_DrRaw.
I haven’t been reading up on this topic or having a sharp mind for the past few months, so again my thoughts will be of the general and vague variety.
1. If you haven’t already, perhaps becoming involved in the discussions at acescentral.com, which has already been linked to several times, would be your best bet. Troy isn’t the only one with whom you could engage.
2. About log2(): just as jerk is the rate of change of acceleration, there are probably lower and higher orders of math for offset and power. I wonder whether offset could be embedded into the transforms… People from the OCIO camp seem to like their transforms a lot more than ICC adherents do with assign or convert. 
Awesomely good idea - even just the general conversations are interesting.
Hmm, you might be right, I don’t know. But I dare say or at least hope the people using OCIO have taken the time to understand what their LUT transforms actually do. Whereas it seems a fairly significant number of people using ICC profile color management just assume there’s nothing to learn, not even the absolutely basic difference between assign and convert.
Anyone who thinks using OCIO is simple, and your monitor isn’t calibrated to sRGB and you aren’t editing in sRGB, well, that’s the first hurdle - you need a LUT connecting your RGB working space to your monitor profile, which profile you almost certainly made using ICC profile tools.
The second hurdle is when you want to switch to a different monitor or you update the calibration and profile for your old monitor, now you have to make a new LUT connecting your new monitor profile to your old working space. And if you change your working space, you need yes, again a new LUT connecting your new working space to your new monitor profile.
FWIW, I think OCIO is really cool. But so far OCIO software doesn’t seem to offer anything that personally I need in my image processing workflow. If ever there comes a time when I find an “OCIO only” tool that I absolutely must have in my imaging toolbox, I’ll dust off that nice tutorial that Troy wrote, that I followed a long time ago, and set up some LUTS and some configuration files.
Oh, did I mention the configuration files? If you want to use OCIO, you have to have those files. And even with Troy and another person very experienced in using OCIO lending a helping hand, setting up the config file wasn’t easy for me to do, and I’m guessing a lot of people might find the task equally daunting.
Of course if you only edit sRGB images and you assume your monitor really is an sRGB monitor (maybe those Apple monitors Troy mentioned in another thread?), then there are default config files to help you on your way. But the same holds true when using ICC profile color management - just select sRGB for your monitor profile and also for your RGB working space and away you go. Equally simple. And if you decide to make a real monitor profile, just change the monitor profile from sRGB to the actual monitor profile, no need to mess with making a new LUT linking new monitor profile to old RGB working space. Likewise with changing RGB working spaces. That ICC PCS (profile connection space) is a very handy thing to have.
Yes, when I said “transforms”, I meant “transforms, luts and configs”. Without all these supporting files, the next team would not know what to do with the data. There is definitely more to keep track of. I can’t wait to see what you all discover about ACES. (Sorry about bringing in OCIO so frequently. I know that that is off-topic but I suppose that that is the community that works with ACES the most.)