I notice a big difference between 4.2 and earlier versions, previously EXR would always output the linear internal render buffer ‘as is’ independent of the colormanagement’s viewtransform set in the render settings. This is what you’d expect, you don’t want/need a viewtransform baked into your exr files for obvious reasons.
In 4.2 you have to explicitly override this and set it to ‘linear rec709’ to get the old behavior back, not a big issue but it sort of breaks existing scenes and it’s just not right from a technical point of view imho.
Sometimes they make decisions in a way, that I get the feeling they often don’t really understand certain user groups.
But like you said, it’s a simple tweak and easily saved in your startup file.
At least we have a new tone mapper for more pleasing colors when dealing with print.
At least here I can’t confirm anything so far. Saving from an CTRL+F12 render saves perfectly fine linear EXRs.
Saving F12 renders from the viewer as well:
Saving them from the Compositor works fine, too.
And BTW: In a perfect world EXRs should always contain linear data (gamma), but of course this data is in a specific color space (gamut) like Rec.709 or ACEScg. “Linear” is not a color space.
That is impossible if i am not wrong.If you export your EXR in Blender then it stores with the Blender working color space which is linear rec 709 without CM applyed.
Tbh i have not tryed the override option now.However if i store my testrenderings with my custom tonemapper build in the compositing,then i just save in the render tab the viewer node output.
What ever is set here, in the image below, shouldn’t endup or affect an EXR file, it’s a ‘view’ transform… applied when you output the data to a display device.
(ok, if you save to jpg, or some other ‘non professional’ format there is case to be made to bake everything down so you get a WYSIWYG output, but not for EXRs)
Anyways, Create a scene that renders a cube and use the compositor to save it to an EXR.
Then in 4.2: Case_1: write node set to ‘linear rec 709’ will output correctly independent of the scene colormanagement settings.
Case_2: write node set to ‘follow scene’ will bake the viewtransform into the exr data. You can test this by saving a few EXR with different viewtransforms selected, they all are different.
And in 3.5: Case_1: write node set to ‘linear rec 709’ will output correctly independent of the scene colormanagement settings.
Case_2: write node set to ‘follow scene’ it outputs the same linear rec 709 data as in case1, changing the viewtransform has no affect on output and EXRs are the same.
This is certainly a change compared to how it worked. To me, the 3.5 behavior was a bug, which was now fixed in 4.2. I remember having that problem and didn’t understand what was going on (and I am very happy it was fixed).
Still, the compositor, view transform UI always feels very wonky to me and I am constantly getting results I did not expect. With the recent developments, we are getting more controls and I hope the situation further improves.
Save image with render color management. For display image formats like PNG, apply view and display transform. For intermediate image formats like OpenEXR, use the default render output color space."
Only that checkbox isn’t to be found in the UI… not sure I’ve ever seen it before though, but if it’s simply missing in the UI it could be in a random ‘last used’ on/off state for different users resulting in different behavior?
(I’m checking EXRs in both mrViewer2 and simply reading them back into blender itself)
I’ll post some visual comparisons and screenshots later…
I use Affinty for post production and the override works, it set the color space from rec.709 to AgX Base sRGB. To get more of that Punchy look without a LUT, I usually just set the gamma to 1.3
