Hi, we’re having issues delivering linear EXRs from our Aces-cg EXRs.
We swtiched our entire workflow to Aces 2 years ago, but never had any issues in the past.
Our client asked us to send linear sRGB EXRs instead of Aces-cg and we can’t get the same result.
What’s the procedure?
Is there a simple linear transfer function to apply?
Thanks in advance 
Sebastien
There is no transfer function needed. Indeed, if you applied a transfer function, the image data would no longer be linear. What is needed is a simple colour space conversion, with chromatic adaptation from ACES white to D65. I do not know what application you are using to process your EXRs, but in Nuke, for example, you could use either a ColorSpace or OCIOColorSpace node. Indeed in Nuke you could simply read as ACEScg and set the write node colorspace to Utility - Linear - sRGB as shown below (using Nuke’s built in ACES 1.0.3 config):
But bear in mind, if your client is planning to apply a simple sRGB curve to your EXRs, they will not see a result matching what you saw in ACES, as they will not be applying the tone mapping and other adjustments applied by the ACES RRT and sRGB ODT.
2 Likes
Well, a process could be built to invert the RRT and make the output old fashioned sRGB/linear file look like the ACES output… but that’s a pretty slippery slope, as there’s not such a thing as gamut mgmt, so you want to make sure everything stays inside the sRGB realm… feels like a road to hell (I’m standing by the river, but the water doesn’t flow)
Hi Sébastian,
my first question would be…why?
What does the client try to achieve with that? In what kind of pipeline do they want to continue working with the files?
It would be simpler than that. You would just bake in the RRT and all of the sRGB ODT, with the exception of the very last part, which is a 1D sRGB curve. However, as @TooDee says, you need to work out first what you are wanting to achieve, and why. Baking tone mapping into an EXR is rather counter to the purpose of a scene-referred approach like ACES.
1 Like
Well, that’s what I meant, it’s not that much simpler depending on where you come from 
Sure. It’s just semantics. I wanted to make it clear that no inversion of anything was required, because inversion of some things can be problematic. The RRT is a case in point, as it is not fully invertible. Pipelines built around the inversion of an Output Transform, to prepare the image for going through the forward Output Transform, do not result in a perfect match to the original.
Yes, I’ve read that, I thought it had been fixed at 1.0, like, not completely fixed?
A pointer to that discussion to avoid hijacking this thread maybe?
Sorry, I’ve been working on other stuff last 3 years, I’m coming back to it(and it’s fun!)
It’s a topic that has come up numerous times. Here and here are two examples, but you’ll find plenty more.
1 Like
Hi Daniel,
I have no idea why. We’ve been asked to deliver linear EXRs by production.
My guess is that the client uses an Adobe product to ingest our files.
Hello @sproulx sorry to bother you. I am a bit late in this thread.
How did it go ? Were you able to provide those linear exrs to the client ?
I am just curious if delivery went fine.
All the best,
Chris
Hi, I am a little confused. The original post was referring to linear-sRGB delivery,contradicted by your latest message mentioning “linear EXRs” which is only referring to the transfer-function and not gamut/white-point (although usually referring to the linear-sRGB output).
I am as curious as @TooDee, as to know why the production went for working with the ACES but the delivery being linear-sRGB.
1 Like