I do it all day long. Guess I’m invalid.
3 Likes
I wanted to show a method to keep the original hue of a image with AgX tonemapping.
Its quite simple,just seperate the color into HSV from the image you want tonemap.Then combine AgX with the original hue from the image.Then you have a AgX tonemapped image with the original hue.
Notice that the tonemapping is happening in the compositing and not in the colormanagment,this is set to Raw.Otherwise you overwrite your tonemapping in the compositing.
The result should give you a AgX tonemapping without hue rotation.
Since AgX base is sRGB we have to set the original image to sRGB too,otherwise the hue would not match.
Variation 2.
Here i leave the original hue as is (in this case linear rec709).And change the gamma after the AgX base sRGB back to linear,to match the original linear hue.
And for the reason that the combine result is a linear image,i set the colomanagment to Standard.
Or you can make the gamma correction in the compositing and set the CM view transform to RAW like this.
2 Likes
But still, comparing both methods there are differences in some hues.
However, I wonder how these methods look in more complex scenes (photographs, animation frames, or as in the initial example, a product render).
Please do not get me wrong but no one else in the field (films/games…) uses Filmic or AGX. My point is that we need a consistent color pipeline across tools, all these new inventions keep creating more confusion. I personally do not care if the perceptive qualities of AgX is better than crappy ACES. I work in studio pipelines sometimes and this stuff does not fit because no one even heard of AGX or Filmic, these things are really that good. Even people who code color for other DCCs don’t know what filmic or AGX is, because these are Blender specific arbitrary implementations. Think of them like Blender add-ons that can’t be installed in other apps.
Like I said if BF trusts their color implementations then they should talk to the VFX platform or similar bodies to make these standard across DCCs. I would be more than happy to use AgX and Filmic when they are the gold standard in the field.
2 Likes
These are just methods to keep your original hue within the composting.
A better way would be to use the “old” AgX because this has not that extreme hue rotation if this is important to you.
Or you can make changes to the actual AgX code that Eary has posted.
1 Like
Works perfectly well with Khronos PBR Neutral… It is very intuitive to work with, because when I have neutral lighting, I can place a red object in the scene and no matter how bright I make the light, the hue is preserved. Achieving that with AgX is literally impossible.
You definitely are wrong! How dare you! 
2 Likes
Yes, I’m looking into that. Personally, I don’t mind the hue change, I’m more interested in ways to use AgX flexibly, but the conversation that’s going on is something that can’t be overlooked, because it’s a problem for the workflow of others.
Not that I care to attempt to get any specific color codes in my renders , but this looks interesting. I’ll try it. It might be better for some stuff like product visualization.
I think it’s very nice that they are adding Khronos PBR Neutral. The more choice the better. And this one might be the right choice for many people. I tested it with a few of my renders and can say with certainty, that I prefer AgX for my interior renders a lot more. But I can see how it might be perfect for something else. Nice vivid colors, but highlights seem too saturated for my taste, I love AgX in that respect and I think it looks a lot more natural.
1 Like
The Hue Correct node in the compositor actually does a pretty decent job of correcting the hue shift if needed, that is what I am using.
That makes sense as a lot of studio workflows basically force you into ACES. AgX is definitely better for us who make work as individuals, but working for someone else often requires adherence to the standards, and they are unlikely to switch even if you figured out a way to lay out Troy’s arguments in a massive spreadsheet.
1 Like
I’ll use whatever looks better to me no matter if anyone knows about it. Even better if I can use something that looks better and no one else knows about it. Please, don’t ruin it for me and don’t tell them.
Most of people I compete with for work use 3ds Max, and they don’t use Filmic or AgX. I like it. I say, let’s keep our little secret in Blender forever.
1 Like
That is fine, I am not arguing against AgX or Filmic per se based on their technicalities. I do not have love/hate relationships with Filmic, AGX or ACES. It is a bit disapppointing that BF has been going around implementing full ACES workflow, rather including these partial implementations. Blender eventually needs to have full support for the exact same ACES workflow (or whatever is named at that point) that the other DCCs support, whether Troy or somebody hates ACES. ACES is a color pipeline, it encompasses many things, the display transform is only a partial feature of the whole pipeline, which is what has been dragging every color talk into a brain farting fights.
We need to stop just focusing on the display transform aspect of the whole color pipeline. As of now ACES is the only set that has been supported by the other DCCs. That is what we have, and we need to work with it until someone else comes up with a superior set of the current color pipeline, then everyone will move to it. So far ACES is the only sane color workflow everyone else supports it. It has its own issues for sure so does everything else in life.
Blender’s color workflow is based on OCIO configs, so ACES is supported if you can live with some dreading issues (which are not small) that comes with when you install the actual config files.
1 Like
This is important. Perhaps I’m wrong but adding ACES seems like it would be simple so I’m not sure why it wouldn’t be an option for those who need it.
There are all kinds of “standards” that are not the “best”. However, when working together with others it’s better than no standard most of the time. In some cases you’re not allowed to play unless you follow the standard.
1 Like
It is not about specific color codes. It is about predictable hue.
Edit:
Essentially, it is about working with the intuition I built for my whole life so far in the physical world. When I have a red object and I turn on a lamp, the red gets brighter and the original hue is preserved.
1 Like
Not sure that’s the full story. In my view we are used to predict hue the way it works in Standard and in many cameras and everywhere around, but it doesn’t mean it looks natural. Not claiming that AgX has it figured out, but personally, I often question this predictability and think it’s just what we are used to when working with digital color while when actually using our eyes and observing the world that predictability… well it gets more complicated. I think that’s why I find AgX way of doing things more natural. The predictability is different and has a tiny bit more to do with perception and the context of the image. But sure, let’s change “predictability” to “ability to match colors to images we are used to” and I have no problem. It has it’s uses.
‘Predictability’ argument seems sort of week to me. Since I work with AgX, I find it predictable, because I am used to it, I know what to expect. If i worked with ACES, I would soon be used to it as well and have my predictability developed in ACES. It just changes so it cannot be used as a strong argument. If we are talking about ability to match hue to the way it behaves in some other pictures - well OK, I cannot argue about that.
1 Like
Ideally, AgX would eventually come coupled with an interface where you can tweak all of the various tradeoffs for the look you are after, but last I heard OCIO does not have a system the allows the construction of that kind of UI (where various aspects of the transform changes dynamically with sliders and buttons). The best it can do is the looks menu and those are fixed.
The BF can always attempt to roll its own custom build of OCIO that adds this, but that leads to issues when it comes time to apply official updates.
That would be awesome.
To me, it is the full story. In the real world, when I have a red object and make the lights brighter, I don’t perceive the object’s color becoming more orange (unless it is a special material). That’s what I mean with predictability. It is something that more closely replicates my perception and the intuition I have from the real world to the digital world.
It is intuitive, because I know what kind of outcome I can expect. Something that should replicate a red object as I experience it in the real world should not drift towards orange.
That’s what I mean when I am talking about predictability. I am not talking about the ability to match colors.
1 Like
It’s closer, the way I see it.
…but we are starting it again. The big thread was enough I think.
1 Like
I’ve used that node once, you’re right. Although I don’t know if that node operates linearly or its implementation is display referred, I also don’t know what consequences it would have if it is the latter and I use an open domain workflow.
We definitely needed another thread on this debate.
1 Like