Interesting, AgX looks cool
I’ve noticed there’s a few branches with more recent commits, which branch should I download?
I think you can try out the main branch. Other branches are not yet user-ready.
AgX looks really good, I think I might continue using it
I think adding ACES to Blender (for people that need it for their pipelines) and replacing filmic with AgX would be a wise move. I can’t go back to filmic after seeing this:
AgX
Filmic
6 Likes
I agree, Filmic also lose differentiation and clarity in highlights when u make high contrast, but Agx still has differentiation of highlight intensities,
I made a new ACES config for Blender. I made a thread about it at Blender Artists:
Here’s the summary of what I did:
- I deleted over 300 of color spaces that are useless for most Blender users. I left 28 color spaces that looked marginally useful, even though I have a hard time trying to imagine use cases for most of them. You really only need 4: Utility Raw, Linear, sRGB Texture and ACEScg.
- I deleted the LUTs that were no longer required to make the setup smaller. The remaining LUTs are still 237 mb unpacked, though.
- I hid most Output color spaces. They are used only in view transforms now. If you want them back, change their “family” attribute from display to Output.
- I kept the view transforms in case anyone needs them.
- Most importantly, I made the config use proper Blender’s roles.
- Changed the default roles so that HDR environments are assigned the Linear sRGB color space on import. This means, however, that if you import actual ACES EXR textures they will also use the Linear sRGB color space. Change to ACEScg or whatever your color maps actually are.
- I also made it so that sRGB Base Color (non-EXR) textures are properly assigned the “sRGB - Texture” color space on import.
Roughness, normal and other non-color maps seem to be importing properly as raw data.
2 Likes
Hi,
that’s funny.
My OCIO differs only by color picking in ACES and adding (what I forgot):
!< ColorSpace >
name: Input - ADX - ADX10
Plus I was to lazy to kick out all the unused Luts.
But I’m still wondering what the ACES 1.3 version brings, if Brecht isn’t quicker.
But always the same problem. The people who have knowledge of ACES and such, miss out on knowledge in blender AND vice versa… 
But this OCIO setup we use, works very well for me since Blender 2.93.
Hello!
Well, I guess It’s a good thing we came up with the same config, It gives me hope I didn’t get something horribly wrong.
I’m really not sure which color space I should use for the color picker. I tried changing it around but I don’t see much difference, or more likely I don’t know what to look for. Can someone explain it better?
I used a simple python script to check which lut files weren’t mentioned in the config and then deleted them.
It looks like ACES 1.3 is mostly bug fixes. And what do you mean about Brecht? What’s he working on?
Edit:
I tested the color picker some more, I’ve tried
ACEScg
sRGB - Texture
Linear - sRGB
Output - sRGB
And they all look consistently wrong. I can’t pick a color in the texture paint mode with flat shading and paint it back.
Here’s how it works with the default Blender (Filmic) settings:
The texture is ACEScg EXR, by the way.
The same test with AgX:
@Nurb2Kea
Can you please do the same test with your config when you have the time?
Here’s the blend file I use for testing:
If the color picker works properly for you, would you mind sharing your config.ocio file?
Hi,
when rendering and working in ACES it makes sense to have the color picker the same!
The view transform is still RGB, but we change the color profile for each image etc. so you work with ACES color picker.
Brecht said in one of the forums here or on blenderartist that he is looking into it and already changed some ACES things in blender, but I can’t remember where exactly. So they are aware of ACES, but will take some releases until it maybe comes to blender as we would like. (like light linking…)
Oh, I see. There are color spaces introduced in 3.2 that make it possible to import ACES textures properly, but they still look off in Filmic. I thought that’s what it was about.
Regarding the color picker, I’m absolutely confused. It samples correct colors if you use the S hotkey in texture paint mode, but if you use the eyedropper icon from the color picker pop-up palette, the sampled colors are all wrong. It looks like it’s hardcoded or something. I tried setting the color picker both to ACES - ACEScg and Utility - sRGB - Texture, same results:
From what I experienced with blender 3.0, when i were using sRGB as picker it wasn’t working, but with the later versions 3.2 -3.4 it works. But these are mainly alphas or betas or just released with corrective updates missing.
And that they are both picking the same color means it’s correct.
You need an ACES ( wider color room) image containing a color that can’t be displayed in sRGB.
When using the picker with an sRGB picker setup, you should get an odd value.
Because you’re working in ACES but your view transform is showing you sRGB…
If I’m not totally wrong !
I did some more testing. It looks like the color picker in the node editor is working properly.
It is affected by the setting in the config file. If I set the color_picker role there to ACEScg, it becomes linear. If you set it to sRGB it becones non-linear.
In both modes, however, the node editor color picker always samples correct values from the viewport.
The texture paint color picker, on the other hand, always stays linear. And it always samples wrong colors from the viewport. It samples the right colors from the Image editor, though. A way to sample correct colors in the texture painting mode is to use the S hotkey. That seems to be working perfectly no matter what.
Is the texture paint color picker just poorly implemented? Can someone more knowledgeable explain this?
3 Likes
Yes I agree, supporting something extra doesnt make any bad, but in devtalk, people keep going against supporting even extra things when noone wants to remove old alternatives.
I fully agree with you when someone try to harshly convince or insist and ignoring the points u make and telling other things or giving wrong alternative/ or no alternatives to prevent any advancement or new additions instead of compromisising or finding middle way but turning into ego-fights just by throwing their own technical details. Devtalk usually turn into a quarrrel instead of being respectful to new ideas and finding middle way. Rude words is not acceptable. There should be some rules about constructive actions and being over-reactive to new additions
1 Like
He’s explained it more times than he can remember and since people don’t fully grasp his points, and still refute strawmen, he eventually got tired of that.
Even worse, people that hasn’t read what he’s written about the topic all over the internet expect him to explain things again, that’s not how it works specially in such a technical field.
2 Likes
I dont think so,
First of all, People might also look for practicality and support for new things without judging idealism of new alternatives.cuz noone says those systems are perfect. So both side talk about different things, one side being more idealist and other side being more practical or focusing on small benefits of something new compared to current system or just simply support for ACES internally
.Its not right to always prevent support of blender on new things by finding faults on them, topics is about blenders support for aces,
Second, explaining things many times is a sign of insistive behavior when people dont expect any explanation
Third, Things u have said are not excuse for being ‘‘rude and insistive’’ or being preventative on new support of things by throwing technical details. Its an offical platform, not friendly talk where u can do mobbing or insistions or bullying to prevent development or diverting topic when someone open a tread for specific purpose.
1 Like
I don’t understand why this discussion is still going on when there is a 54.2 KB ACES studio config available here
If you want ACES, download and use it, the only thing you need to do is to open the file in a txt editor and change the color_picking role to ACEScg to prevent a Blender bug. That’s all, I am not sure what’s there to argue. For those people who see the flaws in ACES and aim at achieving something better, let’s walk towards the future. For those who just want to use ACES, just download the 54.2 KB config and use it.
12 Likes
I was wondering… If changing the color management just a matter of changing the .ocio in Blender’s files, is it possible to merge Blender’s ocio and ACES’ ocio files into one?
4 Likes
this video shows why it would be handy to have an out of the box soltion to switch in Blender between Filmic and ACES
3 Likes
This shows why Blender desparetly needs it rather than it being a handy nice to have.
I know, as i tried to make someting for a movie a month ago, the whole colour management process from blender to davinci was a utter nightmare due to the lack of native Blender aces tools in the colour management.
1 Like