I feel like this topic is very common, but maybe I’m approaching this differently (and need a correction).
I have ACEScg renders and need to composite them over client provided sRGB graphics. It seems the one way to keep the edges proper (as the graphics sometimes are 1,1,1 white.) is to use an OCIOcolorspace node set to in : Output - sRGB and out ACES - ACEScg while either reading in the graphics as raw or applying the same transform, then merging A over B and reversing the colorspace back to ACEScg. However, I found I need to unpremultiply before the OCIOcolorspace node and then premultiply after to keep the edge colors intact. This removes any glows from the CG and clamps the values when it is all flipped back to ACEScg. However the client’s colors are preserved.
What I’d really like is to leave everything in linear but not have edges affected by comping CG over white values of 16.
What am I missing. Is there a different colorspace I should be converting to as an intermediate? One perhaps that wouldn’t require a premult?
Thank you!
I’ve actually now had better luck converting to ACEScct, but this still requires the unpremult and premult. So any bokeh or glow that is done to the CG element, which of course you want to do in linear, is lost. Going to cct does preserve the overbrights though, which is a net positive, even if I can’t work with them downstream without blowing out the whites in the source design frames. This must come up often in commercial production. Has anyone found a good workflow?
here is one way that leads to some potential image quality loss, but most of the time it works:
One stream in the nuke node tree is the comp in ACEScg. When the element is prepped and “ready” you apply one ODT to the image data. Let’s say ACEScg—>Out_Rec.709.
After you burned in the ODT into the image data you remove the sRGB gamma (EOTF) with a colourspace node sRGB—>Lin. From here on the nuke tree behaves like when you work with Nuke-Default.
The second stream in the nuke node tree has the sRGB client image. You load it as sRGB-Texture, followed by a OCIO-colorspace node ACEScg—>Lin_sRGB.
Now both streams in your nuke tree will do exactly the same as when you work without ACES. Merge the two images. After the merge operation you apply the inv. EOTF (sRGB gamma) with a colourspace node Lin—>sRGB.
Whether you write out the comped result as “raw data” or you add another OCIO colourspace node with the inverse ODT. In my case Out_Rec.709—>ACEScg. With this step you loose some image data, but it depends on the content if you will notice it or not.
At this point you can use a normal write node and write out with the ODT of your choice, but always remember that the ODT was once baked into the image data in the nuke tree.
Hey Daniel,
Thank you for sharing your work around! This is definitely leading me somewhere, especially in that it doesn’t seem I need to premult to pull this off. A wonderful first step. I’m going to keep playing with this because I’d love to find a way, now, to not have to clip all the values at 1 when I apply the ODT… or I suppose not apply an ODT. I’m thinking maybe I can switch to logC or something that also lives outside of ACES as an intermediary before the merge. I love the ACES rolloff for CG, but having sRGB (and rec709) behave this way is a real detriment to a design workflow. 100% makes sense for film and episodics though where color is relative through delivery from comp. I’ll post here if I get lucky.
Evan