You guys can now Relax, Blender 3.1 has introduced Convert ColorSpace Node which also supports ACES by the way
What i never understood is when i use a contrast setting this conversion is not possible? I am supposed to render with no contrast?
Please screenshot your settings
Under Color managment the Look option when you render with filmic and in the look option with high contrast. Will it still be possible to transfer that to aces?
Just a comment about ACES Blender that is made vs filmic in screenshots. (Not about detailed understanding of ACES)
I think filmic always look washed out even if we choose the contrasty ones, it feels like fake contrast, its impossible to use it as final output without fixing highlights in other software, I always feel like render looks better after fixing highlights etc. Filmic is not bad but I think never look natural like a movie, I use filmic none to have high control on post processing the highlight and shadows on other software.
ACES is like mix between SRGB and Filmic and best result without using any compositor or post processing levels of image.
No, you need to understand that in the “washed out” aspact, we are basically talking about dynamic range and tonemapping. ACES and Filmic share exactly the same dynamic range, and ACES is a bit more contrasty by default, Filmic has about the same contrast with High Contrast Look. ACES also has a flaw of mis-mapping the middle grey, while Filmic maps open domain/scene referred value of 0.18 constantly to 0.5 across its several contrast looks.
??? You are making me confused, fake contrast? What are you talking about?
It doesn’t make sense, AFAIK OCIO looks operates in open domain (before view transform), what you do to “fix” your “highlights” would be in close domain (after view transform), it doesn’t make sense.
No you need to understand what ACES is. When you refer to ACES, what exactly are you talking about? Are you talking about the ACEScg colorspace that has AP1 as primaries? Or are you talking about its view transform that skews Rec. 709 red to orange and blue to purple?
I assume you are talking about the view transform, well, here is the thing:
And let me show you a way way better view transform here:
I have also been checking out OpenDRT which does not have an OCIO version yet (therefore using the resolve version):
I know that I dont fully understand ACES science. I just told u that I am just giving my opinion regarding those ACES Blender builds on first comments with comparison of ACES and Filmic Medium High Contrast. ACES looks more natural (=less fake contrast) compared to filmic with contrast in Blender. Just subjectively according to images posted in first comments. I didnt mean something complex. I mean that tutorials to put ACES on blenders color management and use ACES vs using regular filmic blender. Thats all.
What I meant is yes they both have same dynamic range but how the middle tones, highlights or shadows are distributed must be different. It might be because of what u mean ‘‘a flaw of middle gray mis-mapping’’
I don’t think having the middle grey to be a bit darker would yield a “natural” feeling, and you can simply achieve that in official blender by lowering the “Gamma” inverse power curve setting a little bit in the color management panel.
You call Filmic contrast looks to be “fake contrast”, I would like to hear the definition of “real contrast” and how Filmic’s looks are different from that.
If you ask me what is “natural looking” vs “unnatural looking”, I would tell you to look at the light saber images above, and obviously TCAMv2 and OpenDRT have the natural looking ones, and ACES has the “unnatural looking” ones.
Filmic has its flaws yes, and its three flaws has been summrized in Chris Brejon’s article. But its contrast is not one of them. Filmic’s base contrast was designed to approximate the sRGB contrast asthetic, if you observe it closely you would see.
What you’d consider the more natural look is highly dependent on what lighting you are trying to emulate. (As well as highly subjective).
To me the right (filmic HC) pictures look like direct sunlight, while the left (ACES) ones look more like sun with some clouds in front. So if this scene uses a sun light to me the filmic pictures look more natural.
Of course this is also dependent on the monitor you’re looking with. On my laptop (which is badly calibrated) the filmic images looks somewhat oversaturated.
I know they can be fixed by gamma or color management curves, what I just mean is that if those comparison pictures are made with same settings coming out of filmic and aces without a changing any gama or anything, the untouched output without changing gama etc. looked better on ACES than filmic.
What I mean by fake contrast is that the highlights are washed out too much causing inadequate contrasty feeling,so it always require a highlight fixing. In the histogram, it push especially highlights too much to middle area so highlights looks too much compressed.
There is no official definition of fake contrast or real contrast. I already told that I am not talking about anything fully scientific and just judging the outputs from both photos posted below by eyes. I already told that my comparison is subjective based on images other people posted here.
No not “fix”, this is personal favour creative grading, or what people would call a “Look”, this is not fixing anything, not at all. When you say “fix” it means technically there is something wrong that needs to be “corrected”, and the inverse power setting with the damn name “Gamma” in the CM panel is actually there for creative purpose.
Again this is talking about “Look”, not “View”. “Look” is about creative grading, and is very subjective. I think this “Look” is cool, you may find it ugly. This is personal favour. This is not the reason to ignore the fact that ACES is baking a strongly skewing “Look” into its view and leaves you no choice but that one skewing “Look”. Your creative freedom has been limited by it.
People need to learn to see problems, just like how most people have been ignoring the glaring Notorious Six skew all over the internet.
If that’s the case you should also do the subjective reaction to the following images posted by me:
I know these are not Filmic vs ACES, these are AgX vs ACES, but since this thread is not really about Filmic vs ACES, I think it is appropriate here.
And this is another example:
Hey @Atticus! Where can we find this addon?
Now that Blender 3.2 beta is out with default support for ACEScg input transform/openexr baking (note it is different from previous Linear ACES, which assumes ACES2065-1 color space), I have some follow up questions:
Without adding OpenColorIO profiles, Blender itself still use linear rec.709 (sRGB) as working space by default, right?
Even if we added the OpenColorIO profiles, how do we know whether we are using ACES workflow? By setting the “Display Device”, have we actually changed the working color space in Blender? Or have we only changed the so-called output transform (RRT+ODT)?
Even if we can set the working space correctly, how do we know the final output transform is using the default ACES gamut mapping and tone mapping? This is the “View Transform” and “Look” option as I understand, but how do we find an option that can match with other applications? Say for example, a game engine using ACES tone mapping (which is likely using an approximation due to performance reasons.) Do I basically had to sync these OCIO profiles to every applications for consistency?
In short, what do we actually get by adding OCIO profiles to Blender 3.2 at this point?
You can set the working space with the config.ocio file’s scene_linear role. You can open the file with any txt editor. You can of course set the working space to ACEScg but I don’t recommend it. Actually if you are not forced to use ACES by your client or by your studio’s decision to switch to ACED etc, if you don’t have to, don’t touch ACES.
Be careful of what you mean when you say “ACES Workflow”, this is what Chris Brejon was warning you folks in another thread. Make sure you describe it clearly instead of using the seemingly obvious but actually ambiguous terms. For example, when most people say “ACES Workflow” they actually mean OCIO’s Scene Linear workflow, so they don’t even really need ACES to achieve what they want.
For the display device setting, when the config is written properly, it is meant to be the kind of hardware you monitor is. For example, if you are using Apple Display P3 monitor, you should not have display device set to sRGB. Which means if you are using P3 monitor with default Blender (doesn’t have P3 support yet), you are seeing wrongly encoded colors. Image formation needs a medium, in this case the medium is monitor. Image formation needs to consider what the medium can and cannot express. Therefore the signals sent to your monitor need to be tailored for the specific characteristics of your monitor hardware.
- The current official Blender does not include ACES’ output transform. Even if it did have it, don’t use it. I am not joking, look at Unreal’s document page about ACES, the demo images they use. ACES looks so bad in UE’s doc that I am surprised they just went ahead and ignore the problem.
Trying to match ACES’s output transform look from other application is a bad idea, I don’t believe your client etc that require you to use ACES would know how to identify between TCAMv2 results and ACES Output transform results. Don’t chase after a broken result.
Again, if you are not forced to use ACES, don’t touch it.
- It allows those ACEScg encoded EXRs to be imported and exported. You can manually set it to be the working space but again I don’t recommend it. If you are forced to use ACEScg encoded files sent from or to your client, things are now easier for you. But again, if you are not forced to use ACES, don’t touch it.
Thx Eary, I find your objective answers very useful and I am not going to argue about the subjective aspects.
Based on your answer, I am going to assume just appending OCIO profiles and setting Display device is not going to change working space color gamut, I saw a recent video on this and I was confused why we had to change
scene_linear. That’s of course my own mistake for not reading OCIO spec and how other applications implements it.
It is also true I am not looking in particular to ACES, just wider color gamut in linear working space, to see if actual improvement can be obtained by this workflow (in general, even if we know the display device is often sRGB / rec.709 only, we would like the gamut clipping to happen as late as possible, for example during output transform)
Note that I want to replicate this in game engine as well, but so far neither Unreal nor Unity actually had wide color gamut support, they are all assuming rec.709 + linear when rendering; what they have are just ACES tone mapping or other sRGB → wide gamut transfer functions, as a part of their output transform. But as you said, Blender doesn’t even have these transform functions, and it looks like we cannot get these output transform via OCIO profile neither?
And just one small note about the ACES’s ubiquity you might worry about: the only game engine that actually support a full scene linear wide gamut workflow is Amazon’s Open 3D Engine, and they of course, had chosen ACEScg as the default working space. So good luck fighting this trend.
Nevertheless, thank you for your detailed reply.
If you are just looking for wide gamut rendering, check out Spectral Cycles X branch, which covers the entire visible locus. And again, ACES does not solve the problem on wide gamut end, look at these spectral renders I posted:
Spectral rendering is the future, ACES doesn’t work well with spectral rendering (both AP0 and AP1 cannot be produced by mixing wavelengths so strictly speaking ACES does not work with spectral rendering at all. Though there are some algorithms trying to map it back to the closest point on the horseshoe locus before turning it to spectra, but why not use BT.2020 then?) Therefore, ACES is not future proof.
You can have ACES’ output transform by loading ACES’ OCIO config. My above test images were done this way. But again it produces broken result and the people that forces you to use ACES is very likely unaware of the difference bewteen TCAMv2 result and ACES result (I.E. show them TCAMv2 result and they won’t even notice that it was not ACES), so let’s use the better one.
That “trend” is what I mean by “if you are forced to use ACES”. If you are forced to use ACES just because downstream in your pipeline the other people are using ACES in their software, or you need to make a shot for a movie and all other shots were made with ACES output transform so if you use a different one it will stand out… This is kind of sad, and I feel sorry for this situation. If you are forced to use ACES, you can load the OCIO config and use it. ACES is having an OCIOv2 config with no external luts so some people’s argument about “ACES config being too large and needs Blender’s native implementation” no longer stands. The ACES OCIOv2 config is only 16.2kb in size. But still, it produces broken result, so don’t touch ACES if you don’t have to.
Here I made a wide gamut render with Spectral Cycles today for you (the EXR file is encoded in Linear CIE XYZ D65, you can just import to Blender and in the colorspace setting select XYZ):
Here is what it looks like with AgX Punchy Look:
Character copied from Blender’s offical demo file for pose library.
Here is ACES output Transform version for comparison:
Here is the CIE XY plot to prove to you this is indeed wide gamut:
If you want to know how it feels like to work with wide gamut renders, here you go, do some experiment, and have fun.
Thx for taking your time to make an example and usage guide, yes I can see in this case other output transform would be more suitable and natural, given the saturation of all ranges.
Having ACES as the defacto output transform definitely cause CG and Game makers to bias towards a certain set of pictures that make ACES shine the most. (high contrasted scene, which you see in all those AAA games and cyberpunk movies)
Though a question, if my working space is still rec.709 (eg. we sample the EXR in XYZ color space but we shade in linear sRGB), doesn’t the input transform already had to remap the gamut to sRGB range? So the rendering result we see is mostly due to final tone mapping, as wide gamut was lost at input stage?
Out-of-gamut values in RGB relative encoding becomes negative values. Negative values are tricky, very very tricky, because they are basically the values that the encoding model fails to encode, so relative to the context of that RGB colorspace, negative values are meaningless. But in a broader context, when you put it back to the absolute CIE XYZ model, we can say those negative values can retain its meaning relative to this broader context. But that requires future research to find a better way to handle negative values to turn them back into meanful values. Currently the most common way of handling negative values is to clamp it. AgX does it too.
One of the most challenging problem wide gamut brings to our table is negative values. You generally won’t have negative values if you are just working with Rec.709 all the time. When you try to use wide gamut, negative values will come for sure, because the RGB colorspace with the purest primaries possible is Rec.2020 (let’s not count ACES’s AP1 and AP0 because they are not possible) and spectral rendering can still render values outside of Rec.2020, so simply making the triangle larger is not going to solve the problem.
More about the aspect of negative values I am going to refer to @troy_s 's post in a Blender Artists thread: