My goal is to work within the AgX transform from Blender to final deliverable, but I’m having an issue with Photoshop.
This is what I’ve set in Blender using AgX-12.3RC, with nothing set in ‘Look’ because none of the ‘Look’ options appear in DaVinci Resolve or Photoshop.
These are the settings when saving the render as a multilayer EXR.
In DaVinci Resolve’s Fusion tab, when I pick these options for the OCIOColorspace(OCC) node, I get the same look as the rendered result in Blender.
However, in Photoshop, when I use the OCIO plugin and set these options, I get a washed out light grey look. https://youtu.be/dksSrFWxLr4?t=353 - in this video, it’s mentioned that in the case for ACES, another instance of the OCIO filter has to be used in a somewhat opposite way to counter Photoshop’s own sRGB view transform that’s applied on top. What is the equivalent step for AgX?
I know I can work with Affinity Photo as it has native OCIO support, but due to client constraints, I HAVE to work in photoshop, so a solution to this is really important. Any and all help would be greatly appreciated!
while I love using the viewport compositor for color work , the hsv nodes (hsv, hue correct, and hsv separate/combine) are acting suspect and changing my colors. I would be great if anyone else can confirm issues with their images. I’m mostly see problems with Yellows and oranges , but not only .
I just installed Fusion Studio 18.5 Public Beta 2 from today and although the change log doesn’t mention anything in this direction, the OCIO Colorspace node runs lightning fast, even with your very latest config from the pull request
I know this is not directly Blender related but it’s a good sign that your awesome config doesn’t need any special treatment to be used by even more users (aka “the industry” ).
P.S.: 18.5 beta 1 from a few days ago was slow as hell still…
I believe this is common. Photoshop and Affinity keep a non uniform encoded version within their internal buffers, I believe. I have tried some versions of Affinity and they frequently require an additional exponent of 2.2 or the two part ~2.2 exponent encoding to “undo” this internal encoding. This is where I would start.
If Photoshop and Affinity are doing similar actions for their internal buffer, it would simply be a matter of undoing that specific encoding. Be warned that the internal encoding may be subject to the working space ICC profile.
@Eary_Chow I can’t seem to use your AgX build in Affinity Photo. Affinity has proper OCIO implementation. It doesn’t seem to read the file. When I try Troy’s it does.
found out one of the reasons I was seeing more color shifts was because of agx config. With one of the recent fixes I was not seeing the shift with the default config using filmic, but agx showed it.
The difference node shows that a diff is there it is just more visual with agx and aces.
Why does standard need to be replaced? I use it for when I’m doing motion graphics with assets created in photoshop or illustrator. It’s the one that doesn’t change the original colors at all. Is guard rail as good at not changing the original colors? If so, why does it need to replace Standard?
Guard Rail changes original colors, it’s a non-functional replacement for Standard. Incidentally, this very issue is the main thing holding up AgX being merged into Blender main; Brecht refuses (rightfully so) to approve it until 1:1 color preservation can be demonstrated
It’s not the main thing holding up AgX. The regular Display’s Native is already back in as “Standard”, Guard Rail is just another option in there, I tried to replace “Standard” with it, but not able to do it with LUTs. So I compromised.
AgX is perfectly ready to be merged, the thing holding it up is Brecht wants to bring back Filmic Looks and he wants old .blend files can still auto select the Filmic Looks, he believe it requires code change in rest of Blender, I have been waiting for that code change to happen but they don’t seem to pay attention to AgX anymore, I don’t know why the code change is not happening. Maybe Brecht himself isn’t even clear how to do it.
Because it only works from 0.0 to 1.0 and nothing beyond that. In modern CG workflow you get values outside of that range most of the time. But as I said, I kept it in for now.
I am not sure about why the viewport compositor differs from regular compositor, but the HSV node in regular compositor has always been clipping negative values, you might see difference because of that.
Perhaps it would be better to keep AgX as an option for power users to download from Github until it is time to break compatibility again (since I do not think the devs. had the breaking of backwards compatibility in mind for a 3.x release)? The exception would be if there was a way for Filmic and AgX to live side by side for now to give users a time to transition.
I do believe backwards compatibility will be broken again as soon as the devs. remove the old particle code in the wake of Simulation Nodes going in (as it can do particles even in its first iteration), which might be the 4.0 release as the devs. tend to place set times on the roadmap when it comes to whether or not compatibility should be kept.
I missed this and can give a more or less “truthy” answer; it’s number fornicating to permit all values of DCI-P3 colourimetry to fall within the specified CIE xy 1931 colourimetry.
You will see that the primaries in DCI-P3 are “outside” of the CIE xy triangle shaped by ITU-R BT.2020.
I was told to post here, I present a janky method of making colors do stuff.
It is based on the idea that the punchy look in agx increases chroma by having a power function on the log space, and I stumbled on everything else by luck.
Everything is first planned in the blender compositor then written by hand into the ocio config file, I don’t know another way.
I also used the rinehardt tonemapper function because I can easily implement it with blender nodes and simple python code to bake the lut.
matrix (a) → clamp 0 → inverse matrix (a)
the power stuff normally makes the extreme edges of the larger gamut (b) (outside the spectrum locus) do weird things, clamping to a slightly smaller gamut reduces that behavior
matrix (b) → log
this puts it in the larger gamut to do stuff with
power 8 → inverse matrix (b) → clamp 0 → power 1/8
this is the power stuff to increase the chroma
inverse log → matrix (c) → log → curve → inverse matrix (c) → power 1/2.2 → clamp 0
this does the “tonemapping part” and tries to make colors have better brightness going into the curve
Some issues:
Complements have less chroma than primaries
Blue is too bright
).
