I would like to add a tool in PhotoFlow that implements the color adjustments described in the ASC-CDL standard. The math is quite simple, however I could not find anywhere a clear specification of the reference color space for the input RGB data.
On the other hand, since the standard is there to guarantee an identical output independently of the software in use, I assume there must be a recommendation regarding the color space…
Anyone has an idea?
Thanks in advance!
Well, I’m sure more knowledgeable people will chime in. But the ACES Primer I linked to here:
says on page 21 that the Look Transform is part of the Output Transform, and page 41 seems to lump the ASC CDL into the Look Transform.
Somewhere it almost seems like the Primer says look transforms are applied in ACES. But on page 46 ACEScc is mentioned in reference to color grading tools, and ACEScg is mentioned in reference to CGI and compositing. So as a wild guess, I’m guessing that maybe ACEScc is used for that ASC CDL stuff as a “transient” working space. But again this is just a guess.
The Primer does give a nice overview. And again I’m sure more knowledgeable people will speak up.
Hi @Elle,
it seems you got trapped in the same confusing references as I did 
I’m exactly trying to figure out which ACES flavour is the correct one for such adjustments…
Let’s see what the experts can tell us.
Ah, here you go:
Quoting:
An alternate design approach
ACEScc or ACEScct are appropriate color spaces in which to apply ASC CDL operations.
Does it mean that one should give users the option of choosing the color space?
Troy told @anon41087856 to not use the CCT version as that toe was a concession to how things used to be done, over in one of the long posts regarding the new darktable code. I’m guessing that CC is the preferred version:
@Elle @afre
Thanks to the links, I’ll be looking through them in detail over the next days.
However, I have a basic mathematical problem that confuses me, before proceeding further.
Quoting this answer from the ACEScc vs ACEScct discussion linked by Elle:
“Because most color correction tools were built to operate on “log-like” data, the knobs and controls would feel “way off” if ACES were not converted to ACEScc, which is a space more suitable for color correction.”
I do not really understand what way off means in this case. My problem is simple: the proposed CDL comprises a slope-offset-power sequence of operations. However, an offset applied to log encoding corresponds to a slope in linear encoding:
log2(x) + log2(c) = log2(c*x)
In other words, if one applies a log2(c) offset to log encoding and then translates the values back to linear encoding, this is equivalent to the application of a slope c to the linear data.
Therefore, an offset applied to ACEScc encoding is not way off with respect to an offset applied to ACES. It is a different operation.
I have no problem applying the slope-offset-power sequence of operations to input data encoded logarithmically, but I would like to be convinced that this the right thing to do…
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? 
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…
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
