The person who make this config is my friend. Actually this config fix a lot of problem. A useable Color picker(I think still have some problems, but it was broken in the github version), back to filmic without uninstall it, etc.
This is the result he shared on a discussion group a few days ago.It can automaticly change the image when import it.
Exactly. People are focusing too much on which is ābetterā, but that completely misses the point. ACES is the standard for color, it is widely used in game engines (Unity, Unreal) and also throughout the film industry.
Even if ACES is inferior, it does not matter. Everything else uses ACES, and so Blender needs the ability to use ACES as well. If Blender cannot use ACES, then it will never be accepted in the industry.
And even for indie developers, it is very useful to have Blender match what other programs (e.g. Unreal) do. Itās hard to do texture painting when the colors donāt match. You end up needing to do a lot of guesswork.
Saying that Blender shouldnāt support ACES is like saying that Blender should only support .blend and should not support .obj, .dae, .fbx, or .glb. Thatās clearly absurd, Blender needs to support the same formats that other programs use.
Nobody is asking for ACES to be the defaultā¦ Filmic can remain as the default. We just want the option to use ACES without having to do a lot of external setup.
6 Likes
While I disagree with the part that says āit does not matterāā¦ I get your point, and I can relate and agree with it.
We can agree in that ACES is kind of broken or itās inferior, but I reckon that for some pipelines that does not matter because it has to use ACES since itās what itās being used in the pipeline.
So I personally support that point of view 
2 Likes
Then sit in a room and generate random light mixtures.
The rest of the people with eyes care.
What is the ā ā ā ā ā ā ā point of a system for imaging if it generates absolutely hideous and irregular results across different display mediums by default?
1 Like
No, no, you donāt get what I mean.
When I say that āit does not matterā I mean that if a client asks me for a shot with ACES I have to comply, thatās it, I cannot argue that I will deliver with Filmic because itās better, the problem will be theirs, but I have to deliver what they ask for and my opinion here, valid or not, reasoned or not, is useless
So good or bad, having an option is not bad because sometimes itās required and we have no control over it.
4 Likes
A few points that seem to be being missed here:
- ACES is a monolithic nightmare complexity surface.
- Blender already canāt even get basic things right via colour management. Many DCCs are worse, but Blender isnāt really āthereā yet.
Now people want to tack on some random variant of ACES, like has been the case for literally years, that is not only broken, but also out of date, as an added thing to maintain. This has already happened, and it isnāt doing anyone any good. At all. Itās a great, huge, dumb, Bad Idea.
Given the complexity of ACES, isnāt it wiser to just bloody well get the most updated version and use the official version?
Like letās face it, the folks here trying to make a case for ACES clearly wouldnāt be able to tell if it was working properly or not anyways, so letās not even bother discussing the technical merits.
ACES is already supported via official repositories, and the idea of placing more duress on a DCC that already has enough problems regarding colour to keep it maintained and such is just absolute madness insanity. And that isnāt even scratching the surface of the absurdity as to how ridiculous all of this discussion is because ACES does not do what people thinks it does.
5 Likes
Yep, probably.
The thing would be to be able to change to ACES without ābreakingā the color picker and without having to make an external change with Filmic, so maintain our default configuration but having ACES as an option, and if itās with the official repo, the better, as you say if we have to use it, better to use the official one that can be updated.
2 Likes
Thatās overhead.
Like I just pointed out, have a look around Blender and see the transforms that are outdated, outright broken, or should just be removed such as the ACES one that lingered around forever.
Just go get the official ACES and use it. In fact, if someone canāt do that it is a good sign they shouldnāt be going anywhere near ACES to begin with. Itās a bad idea on so many levels. If you donāt believe me, I dare anyone here to look at the many hybrid variants out there that a few people were using as āACESā that were completely broken.
It would be much, much, much more beneficial to Blenderās design if more people were able to identify the breakage points and hard coded colour bits that still need addressing. Help Blender become colour managed properly, then worry about other ancillary rubbish.
2 Likes
Agree, but what I mean here is not about the things that are wrong or broken in Blender regarding color management, that as you said are many.
What Iām talking about here is that as an artist you may have no choice, and with other packages, better or worse, you have coices, and in the same way we can go to sRGB or Filmic, could be a good idea to have ACES as an option, at least to have a way to include the official ACES OCIO config without having to remove Filmic and the current OCIO config.
Iām not sure if Iām explaining my self right.
ā¦ unless what Iām saying itās already possible and a user can get the official ACES OCIO config and install it in Blender to use it with Filmic without any trouble, in that case what Iām saying males no sense.
3 Likes
100% Correct.
Incorrect?
ACES is ACES. Once someone is using ACES, they have to stay within it for the duration of a project. Thereās no flip flopping.
Further, configurations should not be mixed and matched without knowledge and understanding. In the case of Filmic, itās more or less BT.709 / sRGB, so things work more or less as everyone expects. It is impossible to mix and match it with ACES by and large, as there is a nightmare stack of other issues going on there.
Exactly, but we work in different projects, so in the morning we work in project A, in the evening in project B and in the night in project C.
That means that project A must be forced to be done in ACES, while project B and C are done within Filmic.
In that situation we need Blender to change from Filmic to ACES, not within the same project, but within the same install of Blender for different projects 
1 Like
This is something that people should not be doing then if they donāt know or understand the implications.
The proper way to change OpenColorIO configuration status that should be honoured across DCCs for the given installation is:
export OCIO=/path/to/whatever/OpenColorIO/configuration/you/want/to/use/config.ocio
Should Blender have the ability to change the configuration available via the UI and set per-project? Scroll back in time about a decade where a few folks have been suggesting that would have been wise since the advent of OpenColorIO in Blender. That sort of glacial movement on these matters is evidence as to why the above thread is problematic at best.
Wellā¦ thatās kind of what we do with workspaces.
Thatās what I mean, itās not our choice, we work with Filmic always, except when a client requires a different thing, in that case thatās not our choice, but we must do it.
You mean as a system variable?
Iām not sure how should be done, what I expose is that there is a practical problem that we have to face, like it or not, and a solution is required in the end.
In other packages you have a UI to pick the OCIO config you want to use in a project, what Iām saying is the same
1 Like
Think about the implications of that.
Work with something that no one understands to achieve something that no one understands.
See above to appreciate the absurdity of the whole idea. No one knows what is going on, and they donāt know how to perform it, and they have no idea of the implications, and they donāt know what they are looking at. But here we are.
See above where some folks said this over a decade ago. But thatās not what this threadās subject started as. Iād support full configuration selection, and have done for as long as OpenColorIO has been partially integrated. I donāt support, for good reasons, the absurdity of some of these hypothetical and ridiculous speculative fictions from some folks.
Thatās what I mean, and thatās what I say that other softwares are able to do
Right now AFAIK there is no UI to be able to configure this.
Last I checked, and since the basic integration of OpenColorIO, this is correct. Not sure if / when it would get added, so itās command line / environment variables right now.
JuanGea. Thats easy, many shops does including ours. Just use environment variables and youre ok.
We just launch software in a shell with predefined variables based on each show. You can do the same on any OS.
Weāve been using the official ACES repo on blender for a while. Sure a bunch of nodes internal to blender have botched color management but by and large you can get ACES work in the blender right now just fine.
I agree with troy that ACES leaves A LOT to be desired. Its a mess but its yet another standard to adhere to.
But also if you canāt get ACES working in Blender you really shouldnāt be playing with it.
2 Likes
This is the part that absolutely frustrates me to no end regarding the obsession over protocols. There is a huge void that can be solved with protocols, so absolutely no disagreement from me. But what is the whole point? The only reason I have even a sliver of interest in pixels and their management is because of the imagery. If the proposed āsolutionā solves nothing but some problem that is tangential to some mythical problem that isnāt terribly clear, it screams madness.
The largest gripe I have with ACES is the lack of gamut mapping and generalized approach that consistently yields the derivative and gaudy over-saturated digital RGB look. Thatās just my personal preference however. The fact that this design also gets in the way of image makers being able to express themselves is far more foundational, and a much larger problem.
Pushing back on this rubbish is key.
I disagree with that, in that we in our projects for our clients have no need to adhere to any āstandardā, in fact unless itās good and proven good we avoid standards hahaha
But itās something you cannot avoid when you work in a bigger projectā¦ the standard gets imposedā¦ usually by a person that decided to follow it just because āitās the standardā not because the implications are understood, but it is what it is
1 Like
I asked the guy that made the config, he said he did not modify anything, he just made sure the ACES config is aware of Blenderās OCIO system and make them compatible, he said because Blender is still not officially supporting ACES so there is a limit of what he can do, but he said all he did was just make sure the ACES is aware of Blenderās system, like the system that automatically detect whether the imported texture is 8bit or 16bit, and auto assign sRGB or Linear to it. He is not really doing anything to ACES itself, nor mix sRGB with it.
I told him what you said about ACES, about its lack of gamut mapping, but he argues we still need ACES because currently Blender does not support higher bit depth cameraās footage. He gave me an example, like an image texture was shoot with a higher bit camera, and the image was supposed to be loaded in a particular color space (he did not say color space but I guess that was what he meant), but Blender would currently only mark it as sRGB, and that would make the image look a bit different from what it should be. He said with ACES, he could just pick one of those camera profiles and the image would look closer to what it should look like.
What do you think about it?
1 Like