The thing that surprises me the most is how convinced each of them is, about their own belief. Enough to write doctorate-level thesis just to try to convince the other one (even though clearly, neither would budge). That’s 10x more effort than what I would ever invest in a conversation.
What’s important here, whichever is “the right one” (ACES or otherwise) is that it’s used by the industry, and that creates the need for some users to have this standard integrated in the software.
At the same time, it’s important to understand that the development team is limited in number and they have their plate full (Cycles X, Geometry Nodes, Eevee rewrite for Blender 3.2, then there’s Particles Nodes, Physics Nodes etc.). There’s just so much that the devs want to implement, and that Blender users want as well, that creates this prioritization.
And it makes sense.
Now: if ACES is still in the works, then it makes sense that it’s not prioritized yet.
Yes Davinci Resolve uses ACES. In fact it doesn’t even let you use OCIO to specify something besides ACES (for example if you want to user Blender’s current filmic color). This is one of the main reasons people are asking for default ACES support, it has standard support across applications and renderers.
As someone who does all my grading in Resolve and works with many other applications and renderers that’s the main reason why I’ve contributed to this thread. There’s also a lot of misinformation about ACES and strong opinions that give people cold feet when it shouldn’t be such a contentious thing to support.
Yeah haha the reason I’m giving it my time is because misinformation about ACES and overzealous criticism by color nerds hinders adoption, which just hurts the actual artists looking for a practical standard to work across applications.
The actual “support” for ACES is already there, as long as Blender supports OCIO, the only thing they really have to do is decide on how they want to write the config file.
ACES is already in active use and has been for years, it’s on v1.3 and part of the VFX Reference Platform. There are many strong opinions about color management, so there are many discussions about what people would do differently for future versions of ACES if and when a version “2.0” were made. For now 1.x is the standard.
People misunderstanding what troy is saying is because lack of understanding the basic and fundamental of this topic.
Again as troy mentioned above, please read again Chris Brejon’s book on this matter.
Also read his original explanation on this website as also mentioned by him previously.
I’m quite sure I read couple thread on this topic from some other sources out there, and I can agree and get what he is trying to explain
It is not just about ACES, sRGB, whatever terms is scattering around out there, it is bigger than that!
He did explain in many places, as I mentioned above, I encourage you to do your own research before express your criticism, some people might not like the way he explain this, but I personally like the way troy communicating his knowledge, it’s straight, sharp, and force me to rethink what I believe previously.
We have read Chris Brejon’s book (which contradicts many of the things Troy is saying), and our own personal experiences also contradict many of the things that Troy is saying.
Troy is extremely abrasive and very bad at explaining things to others. He makes a lot of claims but almost never backs them up with proof, he just expects everybody to treat him as a God and blindly listen to him. And he also seems to be missing the point about what we are talking about.
Stop assuming that everybody who disagrees with Troy is stupid or uninformed. As I said before, if many people are misunderstanding you or disagreeing with you, that’s your fault for not explaining clearly enough.
Which part of the book that you’ve read ? Because Chris try to correct some of the misconception about ACES that he wrote previously, especially on the spesific page link above
I am Chris Brejon, author the CG Cinematography website.
I unfortunately do not have the time to read a thread of 168 messages but I would like to state a few things.
Indeed, I have written an article last September to update my past mistakes about OCIO and especially ACES. It is a mea culpa. I would like to state very clearly that 90% of the content of this article comes from my conversations with Troy over the last year. I have tried to re-formulate and illustrate it with examples so it is easily understandable to anyone.
If you pay attention to the Chapter 1.5 of my book about ACES, it has gone through several updates over the past year. Going from “ACES is awesome” to “ACES has issues and limitations”. I have tried to update as best as I could every time I discovered something new or relevant and that was able to test it myself. I still need to update the article during holidays because I don´t think I am explaining clearly enough what ACES really does.
Let me give you an example. I was helping a French studio last October about color management. They told me that they wanted to switch to ACES because they were currently clipping their values on display. I replied to them : this what ACES does as well ! If you look at the CTL code of the Output Transforms, there is a clip in there.
I would like also to state that Troy is probably the most helpful and patient person I have ever met. You have no idea how many times he has explained to me Gamut Mappping, what his FIlmic does, what “Chromaticity linear” means, how 3x3 matrix works… It is also important to note that Troy has always pushed me to test and see for myself. Hence the article.
So please do not use my website as a justification to use ACES. It is used to be the case but hopefully it is not anymore. I know I had an active role into this whole ACES fashion and hopefully with my latest article, I make up for my past mistakes.
If you really want to know what ACES is and how bad the situation is, I would suggest you have a look at any TAC meeting or Output Transform VWG from last year… And see for yourself.
Thank You Chris! Your book is so Great! I encourage our lighting team in studio to digest your book, all the practical things in industry has been recorded there perfectly
Love your contribution to the whole industry and community.
Anyway fun fact, Barbara is also my supervisor couple years ago, she is very generous mentor I ever had!
I don’t know how the situation is now but I did not have any luck with setting up correct color management in blender. I was very excited about OCIO and ACES but could not get the colors to be accurate on my wide-gamut display. I am a experienced photographer and know a lot about color management in the photographic world. But I must say that this ACES system is extremely confusing, it requires the end user to juggle with 3d LUTs to do the correct color space conversions instead of doing it automatically by itself. In photography you just specify what color-space is your image and you calibrate your display. The software takes care of the conversions between the spaces. It’s my understanding that the implementation of OCIO in blender is not complete and therefore not worth it for me.
can explain a bit more on what you mean “juggle with 3d LUTs”. How are you planning to use ACES in blender and what other softwares are you talking about that do the automatic ACES conversion if I understood you correctly.
Sorry I was not clear. The user has to do everything or in other words know exactly what he is doing. In version 1 of OCIO you can’t use monitor profiles especially the common ICC profiles. I tried taking the red pill and reading all the documentation and converting my ICC profile with various utilities and had no luck. You really need to understand deeply how this works to use it. If you can’t display the colors on the screen correctly I don’t see the point in all this. At least such was the case a year ago when I got my hopes up. I gave up on Blender for now, but didn’t use Maya for a while either. When I have time, I will try with LUXcore Render… it looks like they added OCIO v2 support to it. OCIO v2 should support monitor profiles.
By “juggle with 3d LUTs” I meant that you use the pre-baked LUTs to convert from one space to another in contrast to Photo color management where you simply provide color space information and the software calculates the transformations automatically. Someone correct me if I’m wrong. And I hope this clarifies it.
I have found a utility to make LUT-s and ICC DeviceLink profiles to convert from ACES CG to ICC monitor space. It’s called “3D LUT Maker” and it comes with the Argyll CMS / dispcal. On Linux this can be installed from the Distributions software center. Try installing Argyll CMS or dispcal.
Tried it with V-ray and It works better than the built in V-ray functionality in VFB. To use ICC monitor profile run the 3D LUT Maker utility select the source profile and select a monitor profile as the Destination Profile. For V-ray saved the 3D Lut file as a “Device link profile .icc/.icm”. I selected Absolute Colorimetric and got a good result. The output icc file is used in VRay VFB for preview. Now importing a colorchecker as an sRGB texture on a material, properly lighting it and setting the correct exposure with the physical camera yields rendered spot colors which are very close to what they should be and match the original texture well visually. If someone is interested I can provide more detail. But I don’t think this is easily achievable in Blender for now.
As a final note in this post remember to try setting the Render Settings > VRay > Color mapping. Type: Linear Multiply, Gamma: 2.2 (Or whatever you use for your display) and Mode: Color Mapping and Gamma
