You made my day!
I don’t know, maybe this?
I honestly don’t understand why one would still want ACES output transform after seeing these images.
Sigh, if only we have an open source OCIO config that is as good as TCAMv2
Maybe the issue is that you don’t understand or appreciate the opinions of people who disagree with you.
It is a pipeline issue not a look issue.
For example I consider FBX to be a poor exchange format, much worse than for example GLTF. Yet it’s been so prevalent in the industry that Blender wouldn’t be anywhere near where it is today if it did not support FBX, despite FBX by far not being the greatest. If we followed the Eary argument, then there would be no point supporting FBX because there are theoretically better formats.
No I posted those images because Brecht said this:
So apparently he doesn’t want to continue the discussion about “following the trend”. So I showed him something other than the discussion about how everyone uses ACES thing.
And you guys apparently want to get back to it
It’s not about getting back to it in a sense of fighting or arguing. You yourself said you don’t understand why many of us would want ACES even though it’s not perfect, so we are just answering that.
It’s because despite not being perfect, after seeing those images, we still want to have option to use same color transform across multiple different software packages. Because for many of us, imperfect compatibility is still better than perfect incompatibility.
I think I will end my participation here. My current end thought is this:
TCAMv2 is so nice (it even kinda works for the Spectral branch except for the white point adaption and Sky Texture) but sadly not open source. OpenDRT seems to be a good candidate, but unfortunately it does not have an OCIO version yet. And there are many issues on Blender’s own side as well. I guess I will see how it goes.
Just posted the image here since it’s not really related to this thread: Thoughts on making Cycles into a spectral renderer - #1697 by Eary
I do not know about everyone but the ones I deal with uses ACES and custom OCIO configs. As a Blender user I need a proper way to handle their configs.
This is not just about rendering, there are other areas like texture painting where such pipelines matter as well.
Those are OCIO issues, right ? Can you explain precisely what does “ACES properly integrated” mean ? In the OCIO config there is a role called “color_picking” that has been implemented in different ways between Maya and other DCC softwares. Which behavior are you exactly looking for ?
Why would you say such a thing ? It has been said on several projects that I linked in my article. I don´t think this is a fair statement.
First, Weta Digital does not use ACES. Then, as I have tried to explain to you several times, ask yourself what does it mean exactly “to use ACES” ? If ACES is only used by VFX studios to exchange files, does it count ?
I don´t have the truth but I try to look for it. It has taken me two full years to appreciate what ACES really does. Please, do the same exercise. It looks to me you are pushing for something that you don´t fully understand.
What does this even mean ? I am pretty sure that what you really want is a good OCIOv2 implementation. I think you are confused about what ACES does and what OCIO does.
You could add them to the OCIO config yourself. You know that, right ? One year ago, I didn´t know anything about OCIO. Now I edit the configs for the studio where I work. Please, just make the effort. it is really worth it. And actually fun to learn !
Again, what does “works in ACES” mean ? If you are using only a small part of the ACES eco-system, does it count ? If they render in ACEScg but display with K1S1, is it worth asking ourselves : why is this happening ? I think your statements are misleading.
Again, what is missing in Blender from the ACES point of view ? If you load an ACES OCIO config, what happens ? Can you work ? Can you describe precisely what is not working and which behavior would you expect ?
I still don´t understand what are you guys looking for ? Which implementation ? A CTL implementation of ACES ?
Did you have a look at the examples on their website ? The blue sphere gets magenta because of the sun light.
I am really sorry, I don´t understand. What ACES part cannot be used through OCIO in Blender ?
So what ? You already commented on his job in the other Blender thread and I think this is patronizing/insulting. So basically only if you work in a major VFX studio, you can have a voice here ? Not cool.
Ask Troy what he thinks about his filmic… Please do.
This sounds like an ad. Weird. You keep repeating these slogans…
Again, what does it mean to add “ACES” ? Can anyone explain it to me ?
Not at all. He is trying to raise some valid points that are worth investigating. I really think that what you guys want is a good OCIO implementation. Then you just use Filmic, ACES, K1S1 or whatever.
The default TCAMv2 config is available for free. Then you just edit it (like any config really) to your needs.
Hope it helps,
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.
Let’s not forget about Adobe’s blend modes being broken in anything other than sRGB.