Oh I see! That is interesting. I didn’t try this before.
I think that would suggest there is a problem with the color management rather than the spectral upsampling?
@troy_s what do you think?
A few folks have reported problems to me. Apparently using the config at my GitHub works, so unsure where it’s been bungled up. Haven’t seen A / B comparisons to be able to make a diagnosis.
What kind of test would you need? A rendered exr of regular and Spectral Blender?
If it has nothing to do with Spectral, just an A / B of what the current config in main is mangling up, versus what the config at my GitHub does. EXRs won’t have the transforms baked in, so aren’t useful, unless the data is actually being rendered differently which a diff would reveal.
Generic output referred files would suffice, assuming folks can describe how they are different.
https://imgur.com/a/DqLUwDs will this do? (Uploaded to imgur so you hopefully get the full quality)
All three of these use Filmic. It’s quite clear that the reds feel weaker in the Spectral branch
Here is a complete comparison using stable master and the latest Spectral Build:
Master:
(bottom row requires Spectral branch to work)
-
Standard:
-
Filmic:
Spectral Branch:
- RGB:
-
Display Native:
-
Filmic:
- Spectral:
-
Display Native:
-
Filmic:
Diffs:
(Diffs performed in Master)
- Master vs. Spectral Branch (RGB):
- Master vs. Spectral Branch (Spectral):
- Spectral Branch RGB vs. Spectral:
Thanks for putting the work in Mark. I think I have identified where the bug is in the official config. Will try to fix it when I get home.
Thanks again for putting the effort into this.
3 Likes
I made a small mistake in that imgur story and accidentally uploaded the spectral version twice. It should now be fixed though. (You get the same green tinge either way, modulo the differences that actually really are because of the spectral upsampling. For instance, the spectral version of green looks more yellowish, and red is darker)
Can you do me a favor and comment out the aces_interchange role in the official configuration and let me know if the white balance goes back to normal in the test?
if that’s in config.ocio I can’t find any such line. This is the file as it’s currently in the build:
config.ocio.txt (10.7 KB)
In the official 2.92+.
I thought the discrepancy was 2.93?
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.