The discrepancy, as far as I know, is the Spectral Branch. I haven’t tried with the regular alpha version. I can do that though, if you want.
Sorry for the confusion. My tests were with the stable build on Blender.org as well as the latest Spectral Branch build on GraphicAll. And I checked the ocio.config of both and neither have that line in them
Bear in mind that Illuminant E is the working space achromatic axis in Spectral, and that achromatic point is adapted to appear as achromatic on a D65 display. That means the IE white is mapped relative to the display D65 assumption.
Contrast this against the main branch, which uses a D65 working space achromatic point, and dumps direct. This means if any value other than BT.709 D65 is used, it will be “tinted”.
Does this explain the discrepancy you are seeing?
But this is in RGB mode, the spectral switch is off, it should have been completely the same as the master, right?
Like I mentioned, “RGB version of Nishita” and “RGB Cycles”:
1 Like
I am skeptical that the Nishits sky is working properly, so no one here would assure this. This goes for literally everything else in Blender; it’s a challenging surface across a haphazard piece of software with millions of lines of code.
Don’t test things contributed by random contributors and expect proper behaviour. There are a few folks in this thread with the knowledge to diagnose problems, but it is wiser to stick to more fundamental components for testing. Nishits sky definitely isn’t one.
But other things don’t yield such a noticable difference. I tried a lamp, for example, but somehow the difference in the lamps is so small that sometimes I don’t even notice.
I tried may other things, including textures, HDRIs that come with Blender, etc, but Nishita is the only thing that, I don’t even need to compare side by side, I just open a project and hit render view, I just immediately notice the difference
For example, here I did this lamp test:
Can you tell which one is the master? There are some small differeces (eidt: I saw the difference before posting, now I don’t, it could be either it has no difference or it is so small that I sometimes cannot notice it), but it is really only noticable when you are very focused, and compare them side by side. If I just open a project like this, I would not notice.
But upon opening a project I made with Nishita, I noticed the difference immediately, something seems off with the orange, the red is missing.
I also had doubted it to be the continuation of the color management redish tint problem, but after the lamp test I think this is not the case.
Edit: Here is an HDRI test:
I cannot even tell which one is the master (again you may notice it if you compare it side by side, but Nishita you don’t need to), but using Nishita I immediately see it.
Hello, I’m the guy who worked on the Nishita sky implementation, as far as I can tell the model is correctly implemented and using the color management properly (of course if somebody can prove it’s wrongly implemented then please let me know).
As a side note, but I think it’s highly related, the default clamp value in Cycles is set to 10, which produces these differences for the Nishita sky Default Clamp.
Here https://developer.blender.org/D10085 is the patch to fix the default clamp value, I think this should be more discussed as it actually makes a huge difference in the final results.
Also, @Eary could it be that the sky shows a higher difference than the default cube scene just because the light intensity is orders of magnitude higher than the default lamp and so exaggerating what isn’t quite visible in the cube scene?
There is also a difference in the tests above in this post
It’s not as obvious to see, but if you pick the RGB-rendered (so spectral off) version of the spectral branch and 2.92’s version, the top row will look slightly different after color management when it doesn’t *before * (see the diff)
Like, flick back and forth between this:
and this:
(and ignore the bottom row)
The most obvious difference is in the top left and top right triangles. For instance, cyan looks very different.
As the diff proves
They actually render perfectly identically. So this is purely a color management problem.
They use different working space white points.
Don’t compare Filmic. It should never have been re-integrated as I said before. The only ground truth for any sorts of comparison should be Display Native.
Display Native is 1:1 chromaticity output based on Illuminant E adapted to BT.709 D65, and it should render differently to the main branch. And of course, you are more than able to identify the gamut clipping points etc.
So expect differences in the achromatic axis as it moves all primaries around subtly when coming out as D65. The primaries should match 1:1, and achromatic point, but it is expected that other mixtures will deviate.
1 Like
Hmm, well, if the Spectral switch is off, they shouldn’t… Should they? –
ah nvm then.
I provided both Filmic and Display-Native for these reasons. - The quoted ones are the Display Native ones.
I am still hoping for “the proper way” of providing “Spectral Filmic” and it’d be easy enough to swap in once you got that figured out, I’d imagine. - BTW, once that does work, since it’d target the entire spectral locus, would this work for any color space? Like, would that then completely replace the current Filmic even with sRGB as the base? Or would every color space require its own Filmic?
I wish color pipelines would have gone the sensible route and defined X=Y=Z (so Illuminant E) as the reference white point for the most commonly used color space. But alas…
It just kinda sucks in particular for the Nishita sky texture, because the greenish tinge actually makes it look kinda worse. I wish there was a fix for that. Like, a proper one.
Down the line it’s seeming more and more important that we have some sort of control over the illuminant and chromatic adaptation in the software itself, both as an artistic tool and to remove some of the current shortcuts being made due to development time restraints.
It would involve selecting an illuminant for RGB emission, and the only way I can see that working currently is to have it as a global option.
That way, a flat spectrum would look that pinky red colour (the difference between IE and D65) but dropping in a spectrum which matches the white point of the destination space would properly be achromatic. No magic conversion and no confusion about why things are the colour they are.
I wouldn’t be surprised if there’s still a subtle bug in the spectral version of the Nishita sky, and we also haven’t nailed down the RGB spectrum reconstruction issue, so right now trying to identify the cause of some subtle colour differences might be difficult. Whether they’re actually a problem or not is also a separate question - as Troy stated there are some expected differences in colours which aren’t either pure primaries or achromatic.
being able to pick a whitepoint as part of the colormanagement settings would certainly be cool. “Just simply” select a set of primaries and a white point and Blender correctly accounts for the rest.
Following along Chris’ comments above…
They should still deviate; the configuration is fixed to the Illuminant E. When turning spectral off, we can expect incorrect assumptions using general RGB light transport, and therefore differences.
TL;DR: It’s spectral or the highway, or creative white point adaptation is added to the CM panel. In truth, this has been missing for a long time, and I reckon Brecht would actually accept a baby step patch here.
Yeah me too… for about eight years now.
This all loops back to my experimenting with gamut mapping prior to the Filmic release. I could not in good faith release a wide gamut variant because the imagery was getting mangled up in completely asstastic ways. I have yet to see any wider gamut system do things even remotely acceptably, including ACES.
TL;DR it is hard enough gamut compressing the volume let alone wider gamut. And spectral makes this about 200% more challenging.
There is a small cabal of folks working toward a solution that should land soon enough, however.
Bear with things…
I suspect so too. Do you have any insight on how difficult a change this would be?
Or do you have an insight, @brecht? - how hard it would roughly be to add creative white point adaption to the Color Management panel?
Maybe, if it’s an easy thing to do, I’d try learning to build Blender and make the change myself.
That’s encouraging to hear. I wonder how much sense it’d make to ship the spectral branch before this exists…
It seems like the biggest headaches of spectral rendering are turning out to be, much as you were saying all along, Troy, how to display colors on the screen.
1 Like
What does “creative white point adaption” mean exactly?
Is it about choosing a different adaptation method than Bradford? Or to have e.g. a view transform for sRGB computer display but emulating what it would look like in a cinema with a different white point? It would be fine to have more view transforms if they are commonly useful.
However, the config should do white point adaptation by default, and I think there is some issue in the current config and/or the Blender code where that’s not happening. We should not add a creative white point option with the purpose of fixing a bug.
My understanding of the white point bug is this:
- In both older and latest Blender versions, the XYZ color space is effectively defined as having a D65 white point. With the bundled OpenColorIO config, Cycles rendering is the same in all versions.
- However there was a bug in the handling of
Linear ACESandaces_interchangethat uses the wrong white point, which you’d notice when using another OpenColorIO config or reading/writing with theLinear ACEScolor space. That should be fixed in https://developer.blender.org/rBeb20250. - Blender/Cycles shader nodes and/or spectral branch code may be incorrectly assuming the XYZ color space has Illuminant E rather than D65. Help verifying and fixing things would be appreciated.
I think the idea would be a feature where, in addition to the primaries of a color space (such as picking sRGB or Rec.2020 or whatever), you can also pick a white point (such as “Ok normally sRGB is using D65 but I want a version of sRGB that is using E as the white point” etc.)
This would be independent of the Spectral branch, as far as I can tell. Just another thing you can do with color management.
It’d be useful for the Spectral Branch mostly in that there currently, as I undertand it, is some trickery involving assuming Illuminant E during rendering but then post-processing through color managed back to D65. If the white point could be set flexibly, that could be done more cleanly.
(Is that right @troy_s?)
The reason this trickery has been necessary is, that we don’t distinguish between reflective and emission spectra. Intuitively, if you set a color to be spectrally reconstructed, and that color is (1 1 1) white, you’d have two expectations:
- Materials with this color will reflect 100% of light
- Lights will appear whitepoint-white
But the only way to do this without distinguishing explicitly between emission and reflection spectra is to render assuming Illuminant E, where those two assumptions can be made to match.
I’m not sure whether there is some method that involves two strictly differing spectra, where you could keep the D65 assumption.
It also has to do with light sources having a color input that’s applied on top of the node setup. If you take that color to be a D65 spectrum, double applying it (as you would do simply by activating nodes on a light source) wouldn’t give you the same white light. Since we’re looking at a spectrum, and that spectrum isn’t constantly 1 everywhere except for Illuminant E, doing that double-application will give you a differently colored light.
I don’t understand how adding a creative white point option in the Color Management panel helps with that problem. What you’re describing does not sound like a creative choice, but a matter of correct implementation.
Perhaps that’s true. To clarify that is why I tagged Troy again. Learning as I’m going, sorry.
It’s all kind of convoluted and life would be a lot easier if the assumed whitepoint were E.
Part of the question is what the correct implementation even would be. Personally I’d like to get as close to Master Branch Cycles look (modulo any bugs there) as possible.
Since there recently (like, as you linked, today) has been a change there, it might be worth rebuilding the spectral branch with those changes in mind. I could then compare what’s happening directly between a most recent nightly build and the spectral branch.
But while there no doubt will be differences, the question is going to be which differences are ok and which aren’t. And that currently isn’t quite clear. - Do you, in principle, see an issue with the design I (hopefully correctly) summarized? Involving rendering in Illuminant E and then color-managing into Illuminant D65? Or is there already a problem with that as far as you can say? - Like, assuming every step of that is being built correctly which it might currently not be.
Visualize a slider that permits the image author to choose the “white balance” via some UI such as a CCT control.
Examples:
- Working primaries assume D65, but the author wants to “feel a blue tint” in them, so sets adapted value to 5600k.
- Working primaries assume IE, and the author wants to balance to D65 so they sense the tungsten feeling IE.
Analogous to setting the creative white balance in a camera, or choosing a white balanced film stock.
What is IE? Illuminant E? I have not seem that abbreviation before, and a bit odd to use it but not ID65.