(I’m not sure I want to get into this conversation again but…)
I’m from the VFX film industry. We’ve pretty much all made the switch to ACES. Ok it’s not perfect. But it’s more than just a LUT, it’s a colourspace, it’s a way to conform incoming footage, textures and CG renders in the same color space and output to whatever the client desires. It’s compatible with Resolve and Nuke. ACES is the way to go. Nobody in the VFX world uses Filmic and getting it to work in Nuke or Resolve is a lot of trouble. I had a very long discussion with Troy about it.
Blender is moving into the professional world, with all the pro stuff (alembic, VDBs, USD etc). Now we need ACES. Blender could keep filmic for people who still want to use it.
Right now we are using a cheat for ACES with Blender and we have minor issues like the color picker acting weird and the playback of animation. But we can still manage.
Seriously, we need ACES properly integrated into Blender in order to play with the big boys.
There’s a reason why ILM, Weta, Pixomondo, Method, MPC, Framestore, Skyline and many other major studios use ACES.
Not the topic to talk about this. In terms of dynamic range or tonemapping, which is what the original poster was struggling with, ACES and Filmic have exactly the same dynamic range with ACES being slightly more contrasty by default (Filmic High Contrast Look gives about the same contrast level). Using ACES would not make the original poster happy. What they need is to understand the difference between open domain scene referred 0 to infinity data and close domain display referred 0 to 1 data.
As for ACES, here is the thing about it:
Again, please read the Chris Brejon article I linked above
Don’t know if you are aware, Troy recently has been working on a Filmic Nuke thing, as for resolve, he also has a Filmic Resolve that is not fully working yet.
It is surprising to hear that any part of the film industry might want to move away from the classic characteristics of photographic film. Film is where it started, and there are still those who claim it is the best. For them, anything that doesn’t look “filmic” is going to be rejected out of hand.
I did and when I had my conversation with Troy, Chris was part of it too. He has his point of view. That doesn’t mean he has the absolute truth.
Troy recently has been working on a Filmic Nuke thing
Yeah, he did it while we were having that conversation.
It doesn’t matter if Filmic becomes easier to use in Nuke. The point is that nobody outside Blender uses it. The VFX industry will not adapt to Blender. Blender needs to adapt to the industry.
ACES is not just a color space. When you have an ACES workflow, it’s not just for CG rendering. It’s a whole system to get every sources working in the same color spaces. So you get Alexa, Red or Sony footage. You linearize it into ACES. ACES has the log curves for pretty much all the cameras out there used in the professional world. Then your renders are also done in ACES. So every item in your compositing is in the same world. You do you comp. Then, for the output, ACES allows you to make it in any “format” that you want. So the colourist wants Reg Log, you output Red Log. He wants Rec 2020? You do that. He wants to stay in ACES and deal with the output himself, fine. So from the same ACES source, you can output Rec2020 for UHD and Rec709 for HD and DVDs. You have full control. ACES is a complex color space system. Filmic is just a color space and it’s only for Bender renders. There are no tools to convert Red Log into Filmic, for example.
No matter what Chris says, every major VFX studio works in ACES. That’s a fact. And it would be surprising that all the major studios are a bunch of idiots that don’t know what they are doing.
The discussion around ACES is not relevant to the discussion in the other topic, so splitting this into a new topic. If the ACES RRT or Filmic view transform is used would have made no difference to the points made in the other topic.
Do you realize what you are talking about here is possible with just OCIO? Current Blender’s problem is that Blender still has a lot of parts that are not OCIO aware, which means they are not color managed. This is the main obstacle to the system you described, not “the absence of ACES”. Adding ACES in now does not solve the problem, instead we should continue to make every inch of Blender to be OCIO aware and the system you described will eventually be there. This is why some time ago in another thread Troy said Blender doesn’t need ACES, what it needs is to make sure all of its parts are properly OCIO configurable. After that then the next step would be adding more colorspaces and maybe change the rendering space to something wider like Rec. 2020 (this would also make the compatibility work between Spectral and RGB rendering easier)
I can show you easily the problem, just try drag and drop an HDRI exr into the viewport as a reference image “empty”. Then you can see there is no way to view that image properly through Filmic.
Because adding ACES in now does not solve any of the color management problem Blender is facing now, it would only make things more complex and confusing.
I agree with @Funnybob , Blender will need to adapt to ACES whether it is the shitties idea humans ever produced or not. Most studios either adapted it or are adapting to it therefor it is harder to integrate Blender in such pipelines without procer ACES/OCIO fixes.
Since Blender already offers Filmic as one of multiple View Transforms, it’s very difficult to come up with an argument why not to integrate ACES. As many have pointed out already, pretty much the entire rest of the industry uses ACES. Most of the mainstream DCCs, most of the mainstream renderers, and even some mainstream game engines.
Even if Filmic remained the default View Transform, and ACES was optional alternative, present out of the box, that alone would solve a lot of headaches for anyone wanting to use Blender in any sort of professional pipeline.
Introduction of ACES does not have to mean Filmic going away, and once both are available in Blender at once, it will be much easier to have debate about which one should be default, given that making side by side comparisons would be very easy and convenient.
Sorry but that article does not allow copying so the screenshot.
Again, it does not solve the problem and it is complex, which means we are introducing a complex monster that many users would not sure how to deal with, into a system that is not properly OCIO aware yet, for nothing but to “follow the trend”. Can you sense the chaos here? This would be very confusing.
The thing is, once Blender is properly OCIO aware, all you need to do to use ACES is just to download its OCIO config and use it.
I said that mainstream software now supports ACES. I did not say movies are made with it, that would not make sense.
ACES is mainly meant to compress high dynamic range of the synthetic rendered light into a range which average sRGB display can output, so that when you work, you do not work with clipped areas of the image which you hope to fix in post. It’s just a way to transform synthetic, rendered light into a form that looks more natural to human eye, similar to what phone cameras have done in recent years with “HDR” photo modes.
But ACES is not a final look. The final color mapping look will always be artistic driven. ACES is just something to make artists throughout the pipeline look at something that looks a bit closer to what it will look in post, rather than working blind and hoping the guys in post will somehow save it.
Just a few days old, new Maya release has defaulted to ACES:
Recent release of Vray 5 has added out of the box ACES support
Corona rendered developers are currently in the process of implementing ACES.
ACES is not some instagram filter to make your images cooler. ACES is just a means of making sure that artists across different software are looking at roughly the same thing under the same lighting and shading conditions.
Again, it’s hard to believe but ACES is no magic, it’s just that there are so many people fail to see it’s cons.
You are describing the definition of color management in general, which ACES fails to do and that’s why Troy in another thread said ACES does not manage color. Again if we continue refining our OCIO support we will be there.
Sure, it still clips some values, but it’s still advantage over viewing completely raw sRGB output.
On scale from sRGB to absolutely perfect, ACES is obviously not at perfect, but the fact that so many different pieces of software now have the same view transform is such a huge benefit, even if it has issues.
Prior to ACES, things were a lot more horrible. Some people were just straight up using linear sRGB only, working half blind and hoping guys in post will fix it. Others were using some arbitrary multiplier values of some Reinhard based tonemappers or often even worse (for example Modo renderer had notoriously bad Tonemapper that unnaturaly oversaturated highlights), and everyone was looking at pretty much different thing.
What’s so wrong about including ACES as an option at least until someone comes up with something better everyone else adopts?
Imagine if Blender got something that would be pretty much perfect compared to ACES. It still would not be perfect just for the sole fact that it’s only Blender that is using it, and if you send for example your USD scene to different 3D software, whoever is viewing it now is definitely not viewing it the same way you did.
If I understand correctly. The whole issue is not ACES. It’s OCIO. Blender’s colour management pipeline needs fixing under the hood in all modules before decisions can be made about defaulting any kind of view transform. After this is done, it’s trivial for people to choose to work in ACES, Filmic, OpenDRT or whatever they want. We need to get everyone on the same wavelength here.
If my analysis is correct, the main issue about this subject is that people are asking directly for ACES support out of the box.
Given the way blender handles OCIO currently, any effort in this direction would probably be a waste of time.
What is needed and what people need to ask for or provide help for is a proper OCIO (V2?) support which would make using ACES trivial.
However, this seems like a huge undertaking that very few devs could tackle.
You guys can quote Troy as much as you want but (no personal offense to Troy intended here), Troy does not decide what the industry should or should not use. To my knowledge, Troy doesn’t even work in a major VFX studio. I don’t think he works for any VFX shop. He works as a grip on major films. Troy has very strong opinions on everything and I know he is seen for some as some kind of god in the Blender community but he’s but one man with his opinions. And filmic is his baby. So when you talk about ACES, it’s like telling him his baby is ugly.
The switch to ACES was such a benefit for us. And even if the hack implementation in Blender has some issues, I willing to ignore them and continue with ACES. I can’t send bug reports because it’s a hack, not an official release. But there are only two things I would report. The color picker and the render playbacks.
You want to play in the big league? You go ACES. There’s just no way around it.
I second this, there is no point arguing if ACES is good or bad. If it’s not closed source and many people want it, Blender should add it, that’s it, no arguments can change that.
Again, if you have read the “Mea Culpa”, you would know that the “the entire industry has shifted to ACES” is merely an illusion, with the truth being the studios using it are struggling with the output and trying to avoid it, which means it has caused a lot of trouble.
There’s two distinct things here. One part is using linear ACES color spaces for compositing, rendering and file storage. The other is the ACES RRT view transform. You can use one without the other.
We plan to add support for both in Blender at some point. I think the linear color spaces are the most important, and also the most challenging. However adding the ACES RRT is the easiest part and there’s not really any reason not to add it, regardless if it is used much in the industry.
