Wide color gamut (ACES) and full OCIO color management
Make Blender render in wide color gamut and get rid of the hardcoded rec709. That won't make any difference for regular users as they will be able to choose, but it will allow some pros and big studios to work in ACES color space and be fully competitive to the big industry players. Long story short for those who are not familiar with it: ACES color gamut is the widest and includes all the possible colors a human can perceive. Much wider than the current rec709. From this colour space you can convert colours to smaller gamuts for any of the output devices possible. One more benefit from it for big pipelines is unification of colour work across all departments. Troy Sobotka gave us the outstanding Filmic, but we need to go deeper than rec709.
More reading about it theasc.com/asc/committees/aces
40 Comments
ACES has plenty of issues, such as missing controlled desaturation and other gamut mapping issues. With that said, ACES is a smokescreen for the core issue: Blender needs an audience that can see and understand the issues first, long before the software issues are solved. For example, only a small number of people knew that Cycles wasn't colour managed. As of May 2, Brecht committed some of Lukas Stockner's work . How many people know how to test it? How many people are capable of analyzing whether or not it is broken?
Long before wider gamuts, it's up to the culture to step up. Then, in order:
* @troy_s * I was reading this book talking about ACES. It seems that ACES is going in the right direction. I still confuse with how Blender deal with this color management thing, I hope with a task on Color Management Improvement in developer.blender.org can make this more sense for Blender.
* @bintangsenjapratama * Sorry I don’t drop by here much. I don’t want a single person being confused because that’s one less person who is able to keep their eyes on how various software manages or, more typically, mismanages pixels.
This forum isn’t ideal for answering questions however. Feel free to reach out in other ways and we can see if we can smooth out some of that confusion.
At our company (we do film and TV vfx), we are ditching Maya for Blender and our entire pipeline will switch to ACES for the next and future projects. So there's a way to do it but it would always be better to have it direvtly from the Blender Foundation. We also use Nuke and Houdini, both in ACES. So we need Blender to do it too.
For everyone interested, the main CM task is now up on Phabricator: developer.blender.org/T68926 - I hope we can turn it into a master plan as soon as possible, so we have a clear view of the scope of the issue.
Not a programmer so probably wrong but this seems a fairly easy fix - but crucial. If rec.2020 was the default space then images in lesser gamuts, including rec.709 would fit within it but the software could honour the color space of the image materials actually used (it seems to me). In my case, as I go to print, the images and the output are usually Adobergb. Currently the sRGB limits make colour results far less than ideal.
can we have a file slot for changing the OCIO directly in blender? Because if we work together in a vfx company we need some sort of extranal file for the color management....we cant use the local blender folder for that....
* @Timo S * You can run Blender with any config like so OCIO=/path/to/config.ocio blender
* @Yegor Smirnov * ok so we have to make a specific start up file for that?
* @Timo S * it depends on your OS. Ask your admin.
I feel having wide gamut support is extremely critical for the success of Blender, and its adaption in the industry.
Though I'm not sure if having Rec.2020 gamut would be better. Since all the latest pro monitors are moving in that direction (Like EIZO, ASUS, etc).
Having Adobe RGB as well, would be helpful for those who will still need time to migrate to wider gamuts. In movie industry many workflows are tied to DCI-P3, and in Photography industry towards Adobe RGB. This is the reason that most professional monitors list them both seperately.
Example: eizoglobal.com/products/coloredge/cg319x/index.html
* @SomeAB * It does not really matter which device you are using to output. Aces includes all the color spaces below it. So you can tonemap down to any of them. Which is not reversable.
* @Yegor Smirnov * Well if a broader gamut is implemented (and is not a lot of work, well documented and royalty free) then who am I to complain.
But if that doesn't workout, I would recommed implementing the Rec.2020
It's really very important. We need to develop this.
I would like to see live reload of ocio config without app restart
Not to hijack this thread, but is there any way to open older pre-ACES blend-files, and not have all texture color spaces in shader editor reset to something new. Is the recommended workflow to manually go through each and every image texture node and choose the incoming color space from that huge off-screen list?
wow. it's been almost 9 months and still no improvement! Damn. seriously how hard is to make this is Blender?
This is marked as done, but I'm not sure it really is. I just tried to use Blender's OCIO implementation for a commercial project and the UI/implementation is almost unusable. I'm not sure it's fair to label this as done.
* @fsprinkle * You're right. I'm not sure if that was me who changed the status, but I'm changing it to In Development as it's half done and something is going on around this problem slowly.
Blender already supports such colorspace because this is available through OpenColorIO that Blender uses. You can just download ACES config file and use it. Everything is explained in the Blender manual and the OpenColorIO website .
* @Vincent Girès * Yes, you can load the config and input aces files and compose, but you cannot render out in aces, because Blender is tied to rec709.
* @Yegor Smirnov * What do you mean? Of course you can render EXR which store linear colorspace to use with ACES or other config like Filmic. I don't see what's currently missing.
* @Vincent Girès * Linear is not a color space. Linear is a way numbers are presented. A function. Linear data can be in every color space. Aces can be linear and can be log. Rec709 is also linear and can be presented via log filmic compression. The difference here between ACES and rec709 is in working and available color range robbessette.com/wp-content/uploads/2016/12/Screen-Shot-2016-12-12-at-10.30.50-AM.png So Blender now is only capable of rendering in narrow rec709 color gamut.
* @Yegor Smirnov * When the ACES config is used, the Log view transform of the config can be used for saving files. Are you talking of something else?
* @Vincent Girès * I'm talking about raw scene referred image and values of the light which are used inside Cycles. It renders in linear Rec709 no matter which OCIO config you are using. This config is only for manipulating of the render output or input, but has nothing to do with the way Cycles treats lights and colors internally.
* @Yegor Smirnov * I opened a ticket 10 days ago; T63571, but I don't see much interest from the developers. Currently OCIO is not fully honored so you get mixed results, like hard-coding Rec.709 for byte textures. The ticket should be resolved in order to pass correct data to Cycles prior the merge of T54659, also required for rendering with OCIO.
* @jose * No worries, the One-and-Only is aware of that twitter.com/tonroosendaal/status/1117843732945088516
* @Yegor Smirnov * Can you refer to your sources regarding this? I've been using the ACES config for a while now, and loading the resulting EXRs into Nuke seems to confirm that Cycles does encode to ACEScg. I've also taken a brief look into the Blender source code with Jeroen Bakker, and as far as we saw at that point, it uses the scene_linear space your OCIO config defines, as it should. Unless you have other information? I'm pushing the developers at the Institute for the most pressing colour management flaws to be fixed, and if Cycles is hardcoded to render to whatever space, I really want to pass that by Brecht as soon as possible.
* @Sam Van Hulle * wiki.blender.org/wiki/Source/Render/ColorManagement it's on the way
* @Yegor Smirnov * Sorry, did you read my comment? I was referring to you saying that Cycles is hard-coded to rendering in Rec. 709, which is simply not true.
Regarding that wiki article, I saw Brecht post it. Besides it being horribly incomplete:
I've spent a few weeks researching and emailing with Troy about the various fixes Blender needs in this area. The result of that is a google doc that's been reviewed by Brecht and far exceeds the wiki article he wrote prior to that. I'm going to push things a little harder to make it end up as a design task on developer.blender.org , because as long as it's in limbo, there's not even an overview of the state of things. Let alone any of it being 'on the way'.
* @Sam Van Hulle * I was wrong about the fact that it's still hardcoded to rec709. The patch was commited to master in may or so and i've missed that. So now it's able to render out in wide color space. The only thing missing is the colorspace representation for the viewport and for file output, which must be separated, as you can't output anything but srgb or wide 32bit exrs from blender for now. This one is for another proposal.
* @Yegor Smirnov * That's correct. But it's not the only thing missing. I'll try to push some developers next week, to get the developer.blender.org tasks up asap. That's what should be bounced around, instead of that stupid wiki article.
Sounds nice.
Like we need someone like Øyvind Kolås from gimp.
* @1d.inciner * like the one that developed filmic? But currently he is pissed of because of some change with the color in blender.. troy_s on twitter
* @SilaS * What change in the color are you talking about? Is it something recent, that I don't know about?
* @Yegor Smirnov * he brought us the filmic color managment... and the change was somthing how blender handles color... when you search on blender developer troy´s account you can find the thread
* @1d.inciner * Fuck. No. Useless software with useless developers.
* @troy.sobotka * Øyvind makes non-destuctivity and some color enhancements (babl/gegl). I don't know anyone who can challenge this kind of tasks. At the end, every software is useless until it is not supported ^^ We use it a lot, that means, we are making it useful =)
* @1d.inciner * Anyone who believes what you typed has no idea about pixel management pipelines. GIMP is busted up precisely because the developers were clueless about pixel pipelines. Folks responsible for problems shouldn’t be tasked with fixing things.
Ye! We need it!:)