Using Blender with wider gamut than 709 primaries (like ACES)

Question

There is a similar old unanswered question on this site with some vague comments (ACES workflow in Blender), so I'll ask it differently:

Is it possible to work in blender 2.8 with color spaces that use a wider gamut than Rec709?

Is blender's cycles still limited to Rec709 primaries only, or can it render images with wider gamuts?

Is the information on this link: Blender & ACES 1.2 accurate?, meaning that all it takes is to have a different config.ocio and the corresponding LUTS and set a system variable for OCIO, as stated also in ACES setup for blender using OCIO?

Additionally, I've found this article on how to work with Alexa Wide Gamut color space. Is that the only color wide gamut space that is usable today?

I hope someone (like @troy_s) can shed some light on this. Thanks.

https://www.toodee.de/?page_id=1221 wll i think since filmic came out and the several colorspace changes have been made i think blender is now flexible in this area, it comes down to tune it how you want.. (no idea how to test and verify though). — Peter, Apr 07 '20 at 22:45
You can, but it will look like ass. The larger issue here is gamut mapping, something that ACES has never had. Give it a try! It is pretty easy to treat all of your incoming buffers from the pickers as BT.2020 primaries for example. What you’ll end up with is over saturated garbage, much like everything that comes out of ACES! Gamut mapping is a huge deal, and well worth understanding. No better way to understand than to test it out. — troy_s, Apr 08 '20 at 23:30
Thanks @troy_s will try it. Where can I read about "gamut mapping"? — susu, Apr 09 '20 at 00:42
It's a bit of a dense and nuanced subject. The best advice I can give is to try and understand how the various chromaticity plots work. I've tried to lead folks down that path over at https://hg2dc.com. Once you get a firm enough handle as to how spectral light mixtures are plotted on that model, it becomes clearer as to what is happening when thinking about gamut volumes. Best advice is try Mareck's examples and look at the imagery to start. How does it look? What feels off? Etc. — troy_s, Apr 09 '20 at 19:15

score 11 · Accepted Answer · edited Jun 10 '20 at 12:57

Short answer

Yes you can use ACES OCIO config in Blender, but...

@troy_s don't hesitate to correct mistakes or add infos to what follows.

Longer answer

I've just try it since 2 days, I've seen the new ACES 1.2 OCIO config pop up and decided to give it a try. At the begining I was quite enthusiastic, made some tests, more saturated, ACES config need adapting color values.

First problem

Since you can't change the colorspace of the color wheels, they are going completely crazy, click on a color of the wheel, then in HUE change the saturation, or click and drag on the wheel, it speaks for itself, if a dev read this, we really need to have color managed RGB color wheels as well as a better color picker... if we want to work with other colorspaces.

Knowing that I thought, ok I know this limitation, so I can be carefull and use only RGB channels to set my colors (a pain but I've tried it and managed to make an ACES test scene)

I was quite happy with the render result even if it looks a bit too saturated and then I realised that the glossiness looks less present, perhaps it's like Filmic that looks to desaturated at the beginning because we weren't used to it, for this part I don't know if it's something expected and normal or not.

However, today I've made tests with a chart image to see if it is correctly interpreted.

Second problem

Images aren't correctly converted. I have this sRGB chart as a base to see what a transfer from ACEScg color space to sRGB should look (sorry I never know if it's EOTF or OETF):

A screenshot of the convertion from ACEScg to sRGB, we can see is that it don't react very well:

Even in Resolve/Fusion it's not 100% correct:

Conclusion

I don't know if the color difference is a big deal for a normal scene, but it makes me doubt that it's a valid workflow inside Blender, for now. If someone see a mistake in my test let me know.

I will perhaps try a real scene to confirm all of that, but looks like for the time being, there is nothing better than this great Filmic OCIO config we already have.

Edit 1

In fact all of this makes me think that I understand a bit better my fist test with ACES.
I've made a simple scene only with shader colors, no textures, resulting in an oversaturated image. What made me thought that, like Filmic at the begining we would have to adapt a bit the workflow, but now that I look at the wrong desaturation of the bars of the chart, it feels normal that I have an oversaturated image, and that it's not a workflow to adapt but that I'm fighting a wrong colorspace convertion.

The filmic scene:

And the ACEScg verions:

Edit 2

I've just understood some fundamentals things, and then read Troy's comment that confirm it.
I've made mistakes, and like he said I've learned a lot from them.
I will surely make more but perhapse all of this will help other to understand this so complicated topic.

What I've just realised is that ACES OCIO config doesn't map primaries to rec709 ones, it clamps them. So the desaturation of the top horizontal bars can't be something else, in fact I've ask someone to try with an other render engin (he tries with Guerilla render) I was shocked that it was the same.

And what we see on my test scene rendered in ACEScg is just that, clamped gamut, a bit like the clamped intensity of Blender's standard(sRGB) view transform but with gamut.

One other thing I've realised is that wider gamut isn't about having better color display on a standard monitor but having more colors to display to a wide gamut monitor and surely internals calculations. Perhaps it looks obvious but this topic has so much confusing part that I was thinking, converting from a colorspace to an other was also to match primaries from the first one to the other but it's not what ACES does.

So, can you use ACES OCIO config in Blender, yes, would I use it to have better images than with filmic, hell no. Even if Filmic isn't perfect, I think it's still better than to fight clamping gamut, unmanaged color wheels... and I don't think the cases where you would see a gain compare to Filmic worth the pain. If you need ACES it's for other reasons.

I'll surely add more stuff here later when my knowledge grows, or perhaps add a new question on Stack Exchange, like for exemple converting rec709 values (or pointer's gamut ones) to ACEScg colorspace.

Cool, thanks for your tests @Mareck! If I would add a bounty, do you have the time creating a complete scene? — brockmann, Apr 09 '20 at 06:58
@brockmann I was planning to have a try on a prefessional preject that I'll work on, but with all of that I think it's a bit risky, so I dont know when I'll have the time to do it, in all the cases when I'll have something I'll post here. And by the way thanks for the edits. — Mareck, Apr 09 '20 at 14:24
Thanks for taking the time to test. I'm confused though, images rendered in filmic and ACES are like apples and oranges since they are using different color transforms on the way to display referred. If I understand the issue here, filmic creates desaturation in the highlights, converging to "white" or "achromatic", while there is no such transform available for ACES (or other wide gamut color spaces). — susu, Apr 09 '20 at 17:11
I read the answers in this page and I feel a bit discouraged. Please correct me if I'm wrong: the software seems capable of rendering "color agnostic" rendering (through OCIO), but the interface and tools are crippled by the limits of sRGB display referred. So how is one to use blender to integrate CG and images generated on a camera using ACES then? — susu, Apr 09 '20 at 17:11
I'm a bit like you, I'm not an expert about all of this, I've just spend hours, days, years now^^ interested by those subject but as soon as it involve internal behaviors, code, or math I'm lost. For now I think like you about the color agnostic and limitation about what's under the hood, there is too much involved here for me to spot what's really "broken"... So for now I think ACES isn't something working well enough to switch to (in Blender at least). Plus the fact that from Filmic POV we only miss the wider gamut which in most scenario we wouldn't see much of a difference. — Mareck, Apr 09 '20 at 19:06
Remember that equal values in one colour space are not the same visible light mixtures. That means to get identical chromaticities from RGB values, you need to calculate what the values are in both colour spaces. This is excellent experimentation, and I'd encourage absolutely everyone here to stumble through and make mistakes. That is invaluable learning. Specifically, yes Filmic has a (not very good) gamut mapping for intensity. Given the source and destination are BT.709, no gamut mapping is provided for saturation. ACES has neither, and results in pretty ghastly imagery by default. — troy_s, Apr 09 '20 at 19:19
In terms of starting out, use RGB values to define your surfaces. Importing input textures for albedos requires tagging them with their encodings. If you render out very saturated colours, which ACEScg (AP1) permits as it is basically BT.2020, pay attention to the regions of the image that should gracefully graduate across the surfaces, but instead have sharp and posterized results. This is gamut clipping to the sRGB destination. I'll leave it at this for now, but keep testing! It's absolutely critical for learning how the concepts lead to imagery. — troy_s, Apr 09 '20 at 19:21
As specifically for the camera question, it might be wise to phrase it in the form of a Blender question here on Stack Exchange and I'll check in to give the best answer I can if someone else doesn't answer. — troy_s, Apr 09 '20 at 19:23
Awesome! Going to add a bounty in the upcoming days (when SE allows it) and let you know. Cheers @Mareck — brockmann, Apr 10 '20 at 08:20
@troy_s here's the camera question: https://blender.stackexchange.com/q/173981/92768 thanks! — susu, Apr 10 '20 at 21:23

Robert Gützkow · Answer 2 · 2020-04-09T09:35:09.333

Blender uses OpenColorIO therefore it is possible to use the OCIO configuration and view transforms for ACES. This is documented in Blender's manual.

The standard Blender configuration includes support for saving and loading images in ACES (code and documentation) color spaces. However, the ACES gamut is larger than the Rec. 709 gamut, so for best results, an ACES specific configuration file should be used. OpenColorIO provides an ACES configuration file, though it may need a few more tweaks to be usable in production.

Download the OCIO configurations and extract the archive.
Open Blender's installation directory and navigate to [version]/datafiles/ ([version] is the Blender version, e.g. 2.83).
Rename the directory colormanagement to something else, e.g. colormanagement-orig. This allows you to restore the original configuration in case you want to revert the changes.
Create a directory colormanagement in [version]/datafiles/ and copy the content of the latest ACES configuration and LUTs into colormanagement. At the time of writing that is aces_1.0.3 in the archive. Copy the config.ocio and the directory luts with its content into colormanagement.

Please note that I haven't used ACES and there may be parts of Blender that don't work well with this modification, e.g. Video Sequence Editor, Compositor, color pickers or add-ons that rely on color spaces from the original OCIO configuration.