OCIO from @Eary on both scenes (Eary’s AgX Version 12.3 RC). As instructed, I have changed the XYZ to Linear CIE-XYZ I-E on the config file for the spectral build.
The Scene uses a nishita Sky Texture which is what I assume is provoking the difference. According to GraphicAll — Blender Community , it should be fixed? (" Temporarily added D65 to E conversion for nodes that use XYZ colorspace to fix greenish tint ")
What I’m doing wrong?
(GPU also doesn’t work for spectral: “Illegal address in CUDA queue synchronize (shader_eval_background)”
Result:
This workaround is no longer included in the builds.
As far as I understand, the result of spectral rendering you are seeing is correct. The RGB output is the one that’s wrong because of the nature of RGB calculations. Blender uses sRGB color space by default, which uses illuminant D65 as a white point. The problem is, when you multiply value (1,1,1) by itself, you get the value (1,1,1) back. That’s not correct, because the only illuminant that has this property is illuminant E. For compatibility with the RGB behaviour, spectral cycles uses illuminant E when reconstructing spectra from RGB values, meaning the value (1,1,1) will be mapped to I-E, which by definition reflects 100% of energy. And that’s why CIE-XYZ I-E should be used in the OCIO config, so that I-E is mapped back to (1,1,1) RGB value.
The nishita sky shader does all calculations using spectra and doesn’t depend on the OCIO config. The differences you are seeing are because of changing the white point from I-D65 to I-E, similar to changing white balance on a camera.
Just want to mention, in AgX’s Pull Request page, Brecht disagreed on the use of the XYZ role and requested using aces_interchange instead, which doeesn’t take care of the I-D65 vs I-E difference.
I still believe replacing XYZ chromaticity with ACES2065-1 is a very very bad idea, but I compromised for now by adding the ACES role back, while leaving the XYZ role in, so if spectral branch were to continue using XYZ role, you just need to comment out the ACES role (having both XYZ and ACES role active will result in ACES role overwriting the XYZ role). But just note that I-E white point for XYZ and working BT.709 space might be a bit tricky for Brecht trying to follow the “standards”.
Somehow the green tint feels “wrong” if the other configurations are right (coordinates, time, …) on a calibrated (sRGB) monitor. I’m not saying the image on the left is the right thing one should see, but it seems the spectral version doesn’t show the “golden” sun I would expect for that setting.
Is it only (mine) perceptual problem, or is there something else?
There is a chance this is actually related to the whitepoint.
Are you using the Nishita sky model here? - We’ve had this “too greenish” issue with it in the past
I’m really not quite sure but I suspect what’s happening might be, that Nishita somehow is expecting an I-D65 workflow, and so it’s a bit too greenish
One extremely silly thing you can try to confirm is this:
Try rendering out a high res environment texture from a scene that’s just the Nishita sky in regular Cycles as an exr, and then use that image texture in Spectral Cycles.
If that fixes the issue, I’m pretty sure that’s what’s going on.
There was previously a workaround using the white point adaptation matrix LUT in the code to fix the wrong assumption of XYZ space being I-D65, but in the current build it’s not there anymore.
I believe stuff will get more complicated since Brecht disagreed on bringing back the XYZ role. We lost the way to directly read XYZ I-E chromaticity, and the ACES2065-1 to XYZ conversion also seem to meet the I-D65 assumptions. It’s really hard to squeeze I-E in there.
Maybe eventually we would read ACES2065-1 and convert to XYZ I-E, and XYZ’s white point assumption in Cycles can also be refactored to I-E. Then things might work. (Though I still think reading ACES2065-1 first and then convert to XYZ I-E, instead of reading XYZ I-E directly, is such a bad idea, such an unnecessary step, but this is what OCIO is standardizing and what Brecht is trying to follow.)
Just because one project has been infected with corporate parasitism, doesn’t mean that all other projects must follow suit.
I’ve said it before, and I’ll say it again: ACES is a cancer, and it spreads as such.
The only way to cut this specific cancer out is education. The more folks who get a handle on what is going on, the more folks who can push back against dreadful ideas.
Why is that? I’m not an expert in the topic, but I thought ACES was a standard that allows a wider range of colors closer to what our eyes can see. Is it not?
I won’t belabour this thread on the reasons why, which are plentiful.
Yes it’s a standard. But so is scRGB and many other really woefully bad ideas. Just because something is a standard, doesn’t mean we ought to be using it.
Colour doesn’t exist outside of our cognition. Colour is cognition at work. As such, the whole “more gooder” is just number fornicating. If you’d like to catch even a slight glimpse as to how foolish this is, feel free to watch these two demonstrations.
As you will hopefully realize from even these two ridiculously trivial examples, visual cognition shapes and forms colour. The stimulus “outside of us” is but one context in a field of many, many contexts.
ACES is yet again getting in the way of actual attempts to solve problems. It’s a horrible idea that never “worked” in any capacity. There are folks actively being paid to shill it and pretend it does, however.
Thanks for the reply. I know and understand that color is something that exists in our minds only and it’s an interpretation of what happens with light in the real world (just the other day we were talking at work about the whole “magenta is an extra-spectral color” thing). What I don’t understand (and I don’t mind if you DM me with the answer) is, why is ACES so bad? What would be a good solution? Is there a good solution to have digital material compatible with filmed material and being able to display it the most true to what our eyes/mind see? Color is a thing that fascinates me, and I’d love to understand it better, if you will.
Just for reference, the Spectral Cycles branch from Weizhen is still in the very early stages of development, and many things are not functional (both RGB and Spectral rendering don’t work properly. RGB rendering is just black. Spectral rendering is basically greyscale and I believe very few if any spectral effects have been properly implemented)
Instead you’ll probably be interested in trying out the previous version of Spectral Cycles from other users like pembem. Sadly there doesn’t seem to be a easily publicly available version of that branch for Linux. So you might need to wait for another user to link you one, or build the branch yourself.
It’s likely a bit of both, the spectral Cycles branch acts as a kind of proof of concept and seemingly the blender devs are making provisions like working to replacing Filmic with AgX to better facilitate it.
AgX is an upgrade regardless of spectral rendering, though that will absolutely benefit from this. Other stuff did happen in the background though, such as transitioning from types that demand RGB colors to ones that are more agnostic such that you can easily work with either and basically switch it on or off.
One big showstopper of the old branch was, that the render kernel was basically duplicated instead of reusing most of the structure flexibly
This should no longer be an issue with the deeper reworkings
Perhaps @pembem22 or @weizhen have some more insights into the state of Spectral Cycles though. No idea if Weizhen started completely from scratch or is able to reuse some of the old branch’s work
I’m pretty excited for spectral rendering in blender since I used to be an Octane user. I have been playing around with AgX in the past few days and it solves so many problems that I had with renders that I didn’t even know I had. Much better view transform especially for intense lighting conditions.
