So I have been getting a lot more comfortable in ACES, and have found ways around issues like the weird primary controls etc.
One issue I still have though, is that HSL keying still takes place behind the RRT+ODT and therefore, the color picker is very vague, and once I try to make the key more specific, it is very sensitive.
This issue would also exist in a traditional YRGB system if the colorist was applying a Display Output LUT, so I feel there must be strategies for this.
My thinking would be, why can’t ACES be implemented in resolve in a way that allows the controls for something like keying, to apply the RRT+ODT in the background just for the pixel selection.
Hi Brett.
The feature you are talking about does not depend on ACES design at all (as you also correctly stated citing YRGB), but rather depends on the color tool implementation by that vendor.
Are you particularly referring to keying or color-picking? Some applications have ways to pre-select the color-layer or color-space where tools like color-picker read pixel codevalues (CVs) from.
This allows to composite graphic elements that need to have a specific final RGB CV in the final output color-space like, for example, legal-white subtitles for a specific output delivery.
Not all the applications allow that though (at least in a “direct” way); it usually depends on the color pipeline’s implementation by individual vendors (and this is independent on whether ACES is used or not).
If you are specifically referring to keying, instead, the fact that keyers work on ACES CVs (“below” application of the Output Transfrom) is correct ― at least conceptually. Even in a non-ACES setting, in fact, it is desirable to have as much color-processing as possible take place in the “broadest” color-space, while things are usually viewed (and rendered out) through a viewing pipeline (e.g. a viewing LUT, or an ACES Output Transform) that “sits on top” of it.
I just tried in Resolve 14. As far as I can see, the scopes and colorpicker values display the actual output including the RRT/ODT. So if you select “No output transform” you can see values in the thousands when you go to a highlight region. So far that’s to me all as expected.
The HSL and the other keyers seem not to be affected by the output transform. Whatever I set as output transform leads to the same result when picking a color for the HSL keyer. That leads me to the strong assumption, that that process is handled like any other process in the working space which means ACEScc or cct.
I never found any problems how the controls respond in ACEScct but if it’s to sensitive to you, that may be, because in a Log-like space (which ACEScc and cct are) all values are squeezed into the 0 to 1 range. So the ranges are narrower and anjustments need to me smaller.
Thanks for your responses. I am referring specifically to keying, for secondary operations.
My question is really, do colorists just deal with this sensitivity in log-like space? surely using HSL where the colors and luminance of your selection matches what you see with your eyes would be much quicker and less tricky?
I was hoping there was some way that the HSL could pick values with RRT+ODT applied, and then send the selected pixel info to the working space. Then one would be working in the broadest space, but the HSL selection was “what you see is what you get”.
I hope this makes sense.
Also, I tried color picking a pantone brought in to apply to a solid in resolve, but the color chosen is the color under the RRT+ODT and therefore its impossible to do this operation. What is the answer?
I am not a fulltime colorist, but so far I deal with this sensitivity. Until ACES I had to do the same with many log-formats. Now it’s just one
The conceptual problem with picking RRT/ODT values would be, that you would have to deal with a “working RRT/ODT” that is not the same as the “output RRT/ODT”. So for example if you would chose to work in 709 and therefore the colorpicker would select what you want (which for the real workingspace of ACEScct would be a different value internally) and then choose a different output (for eample outputting to P3) those values would not longer be the same unless you have that imaginary “working space just for the colorpicker RRT/ODT”. That’s so complicated that I am almost not understanding my own lines
So I strongly reccomend to getting used to colorpicking in log-space.
For the other issue of hitting certain colors:
We discussed that in at least 2 other threads, that you find here on the forum.
But in essence: The only way other then getting it close by eye is to get through an inverse of the RRT/ODT of whichever your output RRT/ODT is. As far as I know that’s pretty hard to do in Resolve. Maybe by the following workaround:
Make a sRGB TIFF with that color you need to pick. Without a coloprofile applied in Photoshop. Then import that into Resolve and apply a sRGB IDT to that. Now colorpick the value from what you see on the screen. That may be then perfect for a sRGB output and close for Rec709 output. But I am not sure what happens when you get to other ODTs. Probably it’s wrong then.
