Chris, I’m not going to redo the same conversation we had before.
Yes, Weta is using ACES on a per case basis depending on what the client requires. I asked a friend who works there as a compositor.
When I say nobody uses filmic in the VFX world, you know very well that I mean the major studios, the ILM, Method, MPC, Framestore etc. That’s my universe. If small shop want to use anything else, I don’t mind. They can do whatever they want. In Hollywood, you can’t. You follow the industry.
What I mean by The VFX industry will not adapt to Blender? That means that they will certainly not change their workflow to use filmic. Come on man, you know very well what I mean.
What does working in ACES means? What do you think it means? It’s not like there are 1000 ways to use it. You linearize your footage in ACEScg. The renders are made in ACEScg. The compositing is done in ACEScg. Then you output to whatever colourspace is needed.
As for Troy not working in a major VFX studio, well, if I never worked in a nuclear plant, I’m not going to tell them how to do their job. Chris, you work at Animal Logic! It’s not a small shop. If you get a Marvel job and they tell you that frames are to be delivered in EXR with an ACEScg profile, and don’t get me on the technicalities here, you know very well what I mean, what are you going to do? Tell them ACES is crap because this and that? You know very well that you guys will gear up to work in ACEScg.
We just delivered over 300 shots for Moonfall. Guess what? ACEScg delivered in ACES AP0
Yeah, I sound like a broken record because I keep repeating the same things over and over. When I talk about the major studios working in ACES. I asked all my friends in many of them and they all told me that their composting is in ACEScg. All of them. All the renders are in ACEScg. What about Animal Logic? What are you guys doing for rendering and compositing? I’m really curious to know.
And you know very well what people mean by “add ACES”. And you know very well that it means when people say “working in ACES”.
So Chris, since this is the developer’s forum, could you please make a clear and detailed list of what needs to be done in Blender in order to have a fully OCIO compliment implementation so that ACES (Or any other OCIO config) could be properly Implemented? This would be more helpful than us insulting each other and it would be much more constructive for everyone. Thanks.
I’m guessing since blender internally uses linear and rec 709 primaries the only real difference with acescg is the gammut limit and white point diff. I guessing using the acescg ocio in blender’s current state keeps the colors in the rec 709 boundaries. Am thinking about this wrong?
Sometimes it seems that talking about colors is the same as religion :-). Not sure if a versus discussion will lead to any result.
Personally I would love to see that Blender is able to handle ACES workflow. Not that I see it changing the default color space in Blender, due to compatibility reasons, but having the flexibility would support future development that none of us can oversee right now. Setting up the default color space should be done/decided per project, and the tool should not specify how you should work. I am aware that this isn’t the current situation in Blender.
As the industry is somewhat closed it is not effective that Blender developers would be the problem owner. There is more experience, knowledge and benefits for people/companies working in the “industry”. The experience for me would be more theory than applied, but would like to learn from this opportunity. As Blender developer we could bring the experience of Blender source code and direction where we would like to go on the table.
But being realistic if this is important of the “industry” and Blender being open source I would like to see the industry step up by defining the project and help out in this area. As pointed out in this thread, the main reason is to support studios to use Blender in their pipeline.
I you could do the same, but from the other side. I.e. a detailed list of what you’re missing, that would also be nice.
I’m a complete noob in colormanagement. To me this whole discussion looks like people misunderstanding each other because they are all talking about slightly different aspects of the same problem. It would be very useful to have actual lists of problems instead of all these nebulous preferences
first of all, I would like to state very clearly that I am not trying to convince anyone to not use ACES. I am just trying to raise some questions. I am also really trying to be accurate as I can because ambiguity is not our friend here. So let me recap of this is okay.
Perfect. Would you agree that saying that “Weta uses ACES” and “WETA uses ACES on a per case basis” does not have the same impact ?
I am not disagreeing. But please, try to understand. 90% of Hollywood movies are using K1S1 to display the images. Not the ACES Output Transform. I will repeat for clarity : K1S1 is the most popular rendering transform in the industry. And then it creates lots of issues for archival (see my diagram from the other thread for instance).
I promise you, I am not trying to play smart here. But just listen. Do you realize that you could do the exact same thing : linearize to ACEScg, render in ACEScg, composite in ACEScg BUT display in TCAMv2 ? And you would end up with completely different images. So I always come back to the same point : would this qualify as an ACES workflow ? If the most important part of the chain (the View) is replaced, are you really using ACES ?
Yes, totally. I would deliver ACEScg exr files as the client requested. That is the delivery format. But I promise you : I would most certainly render in ACEScg and display with something else, as most of the industry actually does.
Yes, totally. Thats is my point also. ACES is mainly used for exchanging files in AP0 to avoid ambiguity.
The Lego Movies were rendered in Linear - P3D60, not ACEScg. And Animal has a Baselight in-house DI. Peter Rabbit movies were rendered in ACEScg, but I don´t know what Display Transforms were used (since I left Animal in 2017).
I promise you : I don´t. Or at least, I would be curious to know what they really mean. To learn more about OCIO, I have created these K1S1 and IPP2 OCIO Configs. Thanks to OCIO, I can render in ACEScg with these configs. But I would certainly not say that I work in ACES with these configs. It is an over-simplification.
I am not a Blender user, so I cannot be 100% sure. But these are the general recommendations I make to softwares´ developers.:
I would ask for Blender to be colorspace agnostic (I am certain that this has been asked before). It means that no features have their colorspaces hard-coded. Two simples examples come to mind : the Physical Sky and the Kelvin temperatures. In most softwares that I know of, these two features are hardcoded in “linear - sRGB/BT.709”. So what would be really nice is to have through OCIO, this possibility to choose our working/rendering primaries based on the config and that these two features adapt accordingly.
I would also ask for an OCIOv2 implementation to be on the same page as the VFX Reference Platforrm.
And finally I would raise awareness about the color UI (or color picker). There is a role named “color_picking” in the OCIO configs that have generated a lot of ambiguity in the industry. In Maya, it is used to set your color palette to a certain color space. For instance, you can set it to “ACES - ACEScg” and it means that in Maya, if you use (1, 0, 0), this red color will be an ACEScg red primary. If you modify the config and set the “color_picking” to “Linear - sRGB”, the behavior will be different. A color of (1,0,0) will be a sRGB red primary. As a full CG artist, Ihave always found this feature interesting.
But AFAIK, Maya is the only DCC to use the “color_picking” role this way. In most softwares, it is used to display colors within the Color selection UI. Because the definition of the “color_picking” role is not clear on the OCIO website. So it has been decided that for the next ACES OCIOv2 Configs, the “color_picking” role would not be present by default. Shame.
Hopefully I have not insulted anyone and I am happy to keep chatting with you guys. You were mentioning the playback of animation ? I guess it is like a playblast that is not properly color-managed ?
Final point : if I were you, I would not push for ACES in Blender. I would push for diversity through OCIO. So that any artist can use Filmic, IPP2, K1S1, Filmic or ACES OCIO configs safely.
Okay, this is the kind of info I was looking for. The working/rendering space could be using the role “scene_linear” from the OCIO Config. This is what “Houdini” or “Nuke” have done for instance.
On the other hand, it is worth noticing that Maya uses the “rendering” role for its working/rendering space, which make more sense to me. And it creates less conflicts with other DCC softwares.
If you guys want to get a bit fancy, you could even come with a “filmic_working” role to avoid any clash with other DCCs. This is what Mari has done for instance. And if this is role does not exist, there would be a fallback mechanism.
Edit : Thanks to @Jeroen-Bakker comment, I think I understand better the situation now (and my misunderstanding). And this ties up nicely with what I have been saying. The Color Management in a DCC Software should rely entirely on the OCIO Config.
Agree, and from a developer point of view, don’t implement something that isn’t clear. This is also one reason why I didn’t take on the challenge to ‘fix the color picker’. Perhaps we should add a bug report towards OCIO asking for a better description, including how it is meant to be used. This might currently be different between software, but at least gives us some ground to move forward, or to clarify in a manual why it isn’t followed.
yes, agreed 100%. I think that the official OCIO answer on the “color_picking” role would be : “we removed it from the next ACES OCIO Configs because its behavior is too different between softwares.” Which in my opinion was not necessarily the right move.
I would have preferred that we settle on defining it precisely and making sure that all developers are on the same page. This is the current definition :
colors in a color-selection UI can be displayed in this space, while selecting colors in a different working space (e.g. scene_linear or texture_paint ).
The ambiguous word here is “displayed”. I asked in one of the OCIO meetings to replace it by “set” or “defined”. But instead, they updated the docs with this warning :
Unfortunately there is a fair amount of variation in how applications interpret OCIO roles. This section should be expanded to try and clarify the intended usage.
So I guess it is up to the Blender users/devs to implement it the way they prefer. If I can give you any advice, here is the link for developers for MixingHelpers in C++.
And here is the mockup I did and presented at a couple of OCIO meetings some months ago :
Nothing is wrong with asking for a better and more solid implementation of OCIO/ACES like this is done in other apps. Others users in this topic already mentioned all the rocky experience one has when trying to setup ACES workflow in Blender. I am personally more interested in integration with other apps and the studio workflows where this kind of stuff is asked from me. Arguing on the look issues and why it sucks are not something that matters atm for my use case.
Regarding scene_linear vs. rendering space. It’s not clear to me how using rendering for the working space like Maya would work, what we should use scene_linear for when it is different than rendering.
In general I don’t believe in making a distinction between the working color space and rendering color space. If you’re already having to deal with the complexity and confusing consequences of those being different, you might as well go all the way and use spectral rendering.
The color_picking one we could try to make more compatible, but both the current OpenColorIO definition and the proposed one are unclear to me. However my understanding is that Blender uses it the same way as the OpenColorIO MixingHelpers, that is as the “approximately perceptually uniform space” mentioned in the docs.
I think the main thing we are missing in our color picker is a distinction between different types of colors (albedo, radiance, UI element), as well as options to use a different view or look than the scene for albedo and radiance type colors.
I should also mention that shader nodes like Blackbody, Wavelength and Sky Texture do not have their color space hardcoded and use the aces_interchange role to figure out the appropriate chromaticities. Although there are some things we should improve there for better results.
It’s quite tricky to be compatible with other apps, we’d almost need to add options to make reading the config compatible with Maya, Houdini, etc. Or we could support e.g. blender_color_picking, blender_scene_linear overrides that can be added to a config. Ideally the OpenColorIO definitions would be clarified and followed by all apps though.
I think the biggest issue when using ACES is that you would need to convert all color textures and colors to match the color space. Hence there need to be a way to globally influence the color space of a scene, without adjust each texture and shader. That would be an overkill.
Also standard colors, RGB values, need to be floating bit and not 8bit. Kind of big change for Blender. But nearly all other commercial software has done that change years ago. The software I worked with 3dsmax, Maya, C4D and Modo all have a global color management and support for LUTs In shaders and rendering. I miss that in Blender.
For example, in Blender you can set each bitmap texture to a different LUT, but the scene default is missing. So while all textures in other software is threaded as a standard LUT defined by your scene setting, which would be sRGB for all colors, and Linear for the rest (with normal map as exception), Blender wants you to set all manual. Now good look if you have a scene with 100 shaders and want to use ACES… well maybe someone writes an Add-on, but I think that should be done different.
You simply set the textures to the appropriate color space:
Utility - sRGB - Texture (if it’s RGB)
Utility - Linear - sRGB (if it’s an HDR or EXR)
Utility - Raw (for roughness maps, normal maps, etc.)
This is exactly like setting sRGB, Linear, or Non-Color in Filmic. You can use exactly the same textures that you currently use with Filmic, no conversion needed. Your workflow is exactly the same, you do everything exactly the same as in Filmic (except with a very different look, of course!)
You can even use 8-bit PNG, though in that case you might get some clipping. This isn’t specific to ACES, it’s a limitation within Blender itself.
There are some issues, such as with black body, the sky texture, the color picker, etc. but overall ACES works just fine in Blender. Of course improvements to OCIO should be made, but OCIO is currently functional in Blender.
The real issue is the setup: in order to use ACES, you have to download a zip file which is several gigabytes, then you have to edit the config.ocio file to remove the unneeded color spaces, then you have to configure the OCIO environment variable.
The goal is that using ACES in Blender should be just as easy as using Filmic: you just select ACES from the dropdown list, no setup required. That definitely isn’t true today, but hopefully it will be that easy in the future.
