Note on AgX: The Spectral branch uses a different whitepoint to render images. It’s based on I-E rather than I-D65.
The reason for that is, that we want the default conversion of an sRGB Red 1 0 0 plus Green 0 1 0 plus Blue 0 0 1 to add up to a completely uniformly flat spectrum (so that, say, a color of 1 1 1 means 100% reflection) which implies that the whitepoint needs to be I-E. (That illuminant is literally defined to be the flat equal energy spectrum)
As a result, by default, the config is going to be slightly off.
To fix this, you have to
go into the config.ocio file (just open it up in notepad),
find the roles section (line 10 and onwards) and
locate the line XYZ (line 23)
change that line to XYZ: Linear CIE-XYZ I-E
(so just change the last bit to I-E)
Then the colors will end up looking a bit more comparable
An easy check if you did it right:
Does the default scene in Cycles look kinda yellowish or pinkish? You’re still on the wrong whitepoint.
If it looks the same grey as regular Cycles, you did it right.
You’ll have to restart Blender each time you change the config though. It only gets loaded at launch
I am curious if this is something that can eventually be changed so that one does not have to restart Blender. Would it be possible to eventually have a dropdown in rendering preferences that tells Blender to use I-E or I-D65 without restarting (likely with a note specifying that I-E is for spectral and I-65 for non-spectral)? I would suppose that if the spectral branch replaces the non-spectral Cycles, this might be unnecessary.
EDIT: Please bear with me if such a question reveals the great depth of my ignorance on the topic. I am simply a curious bystander.
I’d very much love a more interactive/dynamic support for OCIO, yes. I think it’s on the radar in theory, but at a very low priority?
At any rate, it’s entirely independent on the Spectral branch
The Blender developer documentation says there’s no publicly available HIP SDK for Windows yet, which means I can’t compile the kernels myself. But that shouldn’t be a problem on Linux or later on Windows. I expect the HIP kernels to work without any additional modifications, the spectral rendering is implemented in a platform-agnostic way.
For context this should make for an ever so slightly slower render but color noise should disappear more quickly, right?
For those looking for it, it’s here:
Do you think it could also be made into one of the builds that lands in the branches menu on Blender Builds - blender.org ? It seems like there are talks of basically ending graphicall in favor of that place in the near to mid future
Also, this by default of course still ships with Filmic as is generally the case, but due to the ability of spectral rendering to produce out of gamut values for sRGB screens, it might be a good idea to use AgX instead, which is built with such possibilities in mind. You can find a recent version of that here:
Basically just drop these files into the colormanagement file and “replace all” (or backup the old files if you intend to use them still)
Note that by default the whitepoint of this is set to I-D65 though, as regular Blender will render with that as a target. Spectral Cycles instead uses the whitepoint I-E, so you will have to:
open \blender\3.x\datafiles\colormanagement\config.ocio in notepad or your favourite text editor
find the roles section (line 10 and onwards)
find the XYZ role (should be line 23)
change it from Linear CIE-XYZ I-D65 to Linear CIE-XYZ I-E
save and restart Blender
If you don’t do this, “pure” grey will render with a yellowish/pinkish cast. If you did it right, it will render in the same grey you’re used to from regular Cycles
Oh I’m actually not sure already including AgX is the best of ideas yet, as it’s still kinda subject to change. That was less for you and more for others?
I mean I’m not opposed to it by any means, but people might be confused.
The above two are Filmic results. CPU has the blue light purplish (what we are expecting to see with Filmic) but the face is somehow broken. GPU has the face fixed but the blue light looks cyan instead of purple.
Did you take care to set the colors to the correct saturation? In ACES, 1 0 0 Red is gonna be a different value than usual, right? - Not sure what the config does.
It looks like the grey in the tunnel is slightly more bluish, and whatever color the debris is, it’s less to the red light reflective than in the spectral version
Hmm, good one. I’m not sure if this is an issue since both versions share the same ocio config, so even if one version is not exactly purely red, the other shouldn’t be purely red either(or so I think). Also I noticed that in the spectral build with ACES, I’m getting pure white lights being shown with a pinkish tint. So either I screwed up ocio with the spectral build or it may be a bug?
In how far are these the same config? I thought one of those is ACES and the other is AgX? Those should have different roles, I suspect
In the ACES version, are you still selecting colors from sRGB or are you selecting them from ACEScg or something?
In the Spectral version, currently you can only select from the sRGB gamut (though with white point E) because of the relatively simple spectral reconstruction - assuming it’s still the same reconstruction as in the old build.
In regular Cycles, the colors are normally selected from sRGB (and whitepoint D65), but that’s different from ACEScg (more saturated colors as the primaries, i.e. the values you get for RGB 100, 010, and 001 respectively, in fact they go beyond spectral and don’t represent actually visible colors)
I think the whitepoint of ACES is D60 rather than D65 which might explain the bluish cast of neutral grey.
The fact that that isn’t correct makes me think the primaries are also similarly affected.