Ok if the blue is at its limit, before all negative things happens you are described.What about bringing the other channels (RG) down a bit for balance,if that makes sence.?
Because now it seems a bit unbalanced does it?
How did you develop your AgX ? Have you a App where you can test all things and equations in realtime like the node system?
Go nuts. Try it!
Everyone is free to establish their own little personalized canned library of looks. I know @Eary_Chow has been doing some experimenting using the GradingPrimaryTransform and can probably walk folks through it. We need more folks to help out others. There have already been a string of bugs reported upstream at OpenColorIO because of folks testing the AgX approach.
As an initial “default”, my role is to provide a tonally smooth image entry point with a reasonably dense signal. This could be expanded to other entry points that perhaps privilege different responses. While I am offering up AgX here for testing, there’s another branch of effort going toward a more deeply engineered result. Short term, it is challenging for me to make a strong case that the inset approach utilized in AgX is not a remarkably compelling and useful result, that clobbers even the most well intentioned and more colour science-heavy efforts of wise minds. It’s dumb, but dammit if it simply doesn’t yield the best tonal variations.
Your role is to take the entry point and work in creative flourishes that suit your different needs.
From the technical vantage, it’s not. The nature of the inset is such that the complimentary light is uniformly inset. Perceptually, however, there is an entirely different result. Engineering such things is massively complex however.
I would rather simply assert that the inset approach provides a very simplistic entry point that preserves the signal enough to be a strong basis. The creative options are up to you. Otherwise, if I am making more aesthetic based guesses, it ends up being just guesses that will likely fall apart more greatly, in a biased manner.
The AgX inset has been rolled through quite a bit of imagery at this point. It’s reasonable and inhibits some greyness boundary errors etc., despite not being engineered specifically to address them. It also holds up reasonably well for spectral based emulations, which is somewhat remarkable. As such, and as designed as an intermediate step between where things are at and a more completely engineered (and more complex) system, it seems a reasonable experimental bed.
Current further things that could be implemented right away for those interested:
That’s a longer story. It comes from having observed way too many different attempted approaches and considering existing toolsets.
Considerations:
I learned a lot from the various responses to the now nearly decade old Filmic. There was significant push back and aesthetic “trend” that was not easy to overcome at first. Folks understandably wanted something “sRGB EOTF-like”. Folks also wanted distorted chroma levels and hues, likely because they were familiar. It seems the audience around here is well positioned to try things, and there are a good number of folks who aren’t obsessive about ridiculous garbage “standards”, instead of you know… making kick ass imagery that doesn’t look broken to shit. Which is why I remain keen on the culture around here.
I’ve always been rather obsessed with the unique nature of subtractive mediums and their resulting densities, and have been chasing tonality for far longer than Filmic. Having observed some chains, such as the original ARRI K1S1 chain, and how the per channel curves were interacting with the primaries, it became clear that the very nature of the per channel lookup could be somewhat “countered” by using an inset approach. This “counted” would yield “muted” chroma in the initial state, which would be then “undone” to a degree when the per channel curves are applied. The result is what you see. I am sure someone else has already tried this approach, I just haven’t seen it.
Part of the “solution” involves the audience too! I can’t sit here and slap a hugely complex piece of colour science engineering on things and try to convince people to use it.
We’ve already seen how things are received with the first version of Filmic. I would say that given a tremendous number of tools still use per channel, such as Photoshop, Affinity Photo, Blender, Nuke, Resolve, etc. it seems very appropriate to accept that for now, and provide image makers with an entry point that might provide a “graceful” transition into the future.
For those willing to use their eyes and brains, the approach in AgX is pretty straightforward and should be a decent entry point for moving forward, without absolutely imploding existing understanding and response. Hence why it would be excellent for individuals to dip their toes into editing some text files and experimenting. Better still are the dozen odd (thank you folks) people who have been aggressively testing the inset approach behind the scenes on footage and other unique contexts! Keep demonstrating the results. I know @3pointEdit has done some interesting experiments too, for example.
One never knows what can happen in the future…
First,thanks for the detailed explanations.
Sure like with Filmic,you can grade your work as you want,fair enough.
Then i can not argure about it,as said this less blueish appearence is just what i noticed.Just to give my humble feedback.
The thing is,if Agx has always this less blue look as basis,i guess that the most artist have to use allways some colorgrading for compensating.VS Filmic was/is more neutral with the flaws it has nonetheless.
This is interesting.Are there some paper or article we can look at,to understand the “chain” better?
At your Filmic github you have given some details about the primarys are based on rec709 and the 1931 cie observer model.
What about AgX has its colormetric information changed?
Since Eary made some tests with wide gamut,as posted before.I wonder if it would “fit” with different gamuts,if its based on rec 709 primarys too?(i guess its based on rec709 too)
It somewhat needs to be this way as most chroma adjustments are also uniform. If it were unequally weighted, then a general chroma adjustment would end up pushing the red through the wall before blue etc.
It holds up on most photography by default. It is equally balanced for the given BT.709 basis primaries.
Nothing. It is BT.709 based for the BT.709 output.
Just saw the Light Group demo image in 3.2 release note:
The moment I saw this, I know it needs to be put through AgX 
AgX version:
Agx seems to have an issue with Texture Basher when used with normal maps and rotation rand is increased and the vertex rotate node used.
Texture Basher:https://erindale.gumroad.com/l/untiling
Can you describe it more? Like what’s the expected behavior and what is it doing now? Any screenshot of the problem? And steps to reproduce it?
When you connect the rotation per cell to the angle of the vector rotate node:
There are black splotches in the texture. When I use Filmic, it isnt there. Normal texture is set to Generic data. 
I don’t think I can reproduce it
They behave the same on my side. I am using 3.3 by the way, not sure if it’s related.
Should I use XYZ with IE or D65 in the XYZ role? @troy_s My original thought was to make my version compatible with the spectral branch so I have been setting it to IE. But as I share my version with some of my friends, they say they found my version to be colder, I think it’s because of the white point of the XYZ space I picked. Should I revert back to D65 and only use IE when using the Spectral branch?
Very interesting. Comparing AgX and TCAMv2 here, I’m not quite sure what to think of the blue stripe to the left: Is that supposed to be “actually blue”? Because in AgX Punchy it looks kinda purple.
That being said, the comparison also reveals that colors look far smoother in AgX. I perceive a ring of sorts in TCAMv2 where it clearly starts oversaturating whereas AgX looks perfectly smooth in those regions.
It’s also interesting to see that they have different tradeoffs with contrast. Like, while yes, the blues in AgX look less saturated and, correspondingly, the regions relying on fine differences in blue have slightly lower contrast, greens actually seem boosted over TCAMv2. (Check out Ellie’s face) Imo that’s roughly a wash.
But the presence of oversaturation artifacts in TCAMv2 makes it quite clear that AgX is superior here.
And of course both of them are vastly superior to any of the other transforms. Like, it isn’t even remotely close.
This is that i meantioned.Maybe a look into the blendfile and especially at the blue lightsource would give a answer ?.Is the file somewhere for download,then we can have a look.?!
Btw the rec709 gamut render at the top.There is hardly primary blue present vs the red and green primary coordinates on the gamut triangle.
Hm on this rec 709 wiki the gamut in the triangle is very similar,with small presents of blue
I wonder if we have more reference scenes for render comparsion.Or build them like the color ramps to get expected results.
@kram10321 you are good at math and building such color scenes.Can you build a rec 709 triangle as scene?
The exr was provided by @Eary_Chow. Not sure if it’s also a render by them
I know that full space of colors isn’t exactly linear, but it at least suggests, that the blue primary used in sRGB is much closer to spectral blue than the other two. Whereas the green primary is way off. Nowhere even remotely close. And the red one is somewhere in between. It also suggests we are generally way less sensitive to blue light. Which is, perhaps, true. Spectrally blue light looks much darker to us than red and, especially, green.
(A full analysis of that would really require correcting for distortions though. As said, not quite linear https://en.wikipedia.org/wiki/MacAdam_ellipse )
@troy_s I have a feeling that, at this point, AgX is tested enough. At the very least it’s well past an “alpha” phase if you will. IMO it would be fine to send it off to be included in Blender Master as an extra option?
It cerainly seems robust enough.
Though based on the feedback, the version to land in master maybe shouldn’t be darkened. I guess if it were to be a replacement for Filmic it might be good to give like three contrast stages. - But honestly I like the option that simply isn’t contrast-boosted at all, just saturation boosted (i.e. in the settings, Saturation to 1.4 as you have it, but the curve to 1.0 / off rather than 1.35)
What even is the process of that? How would you (or anybody) decide that enough testing has occurred, and how would we go about getting this into Blender Master?
I made a wavelegth testrender.
From 380 to 780 nm.
Emission lightstrength 0 to 10 from left to right.
With AgX punchy appearence.
The purple look is very present in this render the blue vanish with higher lightstrength even more.
nice, here is my version
In that version, I’m scaling the light strength exponentially from 0.001 to 1000 so I get a wider range of intensities.
Note, I used the available build of the spectral branch with CyclesX. In principle that allows me to render actual spectral colors. However, the CyclesX version of the spectral branch unfortunately never had the spectral color socket and associated nodes, so I can’t use the actual wavelength conversion. It’s still based on RGB. Really wish a build with the Spectral socket was available…
I tested these just now and noticed something is off.
Specifically, I used the Spectral branch (see post above)
The Base Contrast version looks fine:
But any other version doesn’t correctly fade in strong light conditions:
Vey High Contrast:
Very Low Contrast:
Something in your view transform seems to be off
Either that, or it’s related to the OCIO bug. This is an old version of Spectral Cycles, since no recent build exists…
Spectral branch is not yet 3.2… I have been asking for a newer build for a while now…
In all pre 3.2 versions the other Looks will remain the same as Display Native because of the OCIO error
Sure but afaik the wavelengths colors of the wavelength node, are from a list of the xyz gamut coordinates in 2 nm steps, if i am not wrong.
it’s specifically based on sRGB so it’s essentially clipped. (And it has to be because otherwise you have negative light which would really suck to have in the rendering pipeline, as that would remove light)
Here, I added this part to check:
To represent actual spectral color it’d have to go negative somewhere but as you can see it nowhere does
