The chart is an image texture?
I suspect the image colour space may be being set incorrectly here?
Blender by default uses collapsed GPU GL shaders to perform the transform, and in some cases that can yield quite different results from the more accurate CPU variant which the file save would do.
Curious if the first issue is as I suspect or something else. The second is also worth checking to confirm things are behaving.
I don’t see how it could be anything else currently. Safe for, like, each square being built from geometry, giving them an individual material or something. Of course, it’s not an accurate test since the spectral data of the colors can’t actually be specified in any way yet. They are going to be upsampled just like any other RGB value.
Me neither, but have to ask.
I suspect it’s an inappropriately described input image buffer.
It’s a jpeg, srgb… Used just as any other texture by default. I suspect the difference is still the same cause as the other issue. Saved file looks different from frame buffer in blender.
What colour space did you set the image encoding to, however? Image Viewer, properties. What is the encoding?
There were 2 options, srgb cctf and srgb gamma 2.2(i used the 2.2gamma cause it was much closer to “standard” transform of RGB cycles - in extreme values that is)
I believe the RGB image buffer is skipping the spectral reconstruction it would seem. @smilebags? Ideas? It shouldn’t look like that. Somethings very broken there. @lacilaci is the black thing it’s on physically implausible fully absorptive 0 albedo?
There is no black thing, it’s all a texture. Not sure if the border is fully black though. I’m not at pc atm, I will do another test tomorrow just with spectral cycles comparing output in buffer VS saved images using either of available transforms. I’ll try latest available version and be extra careful to avoid error on my part. That said, I haven’t noticed before that blender saved output would show different as in framebuffer
I’ll have to look into that. I’m not sure how that would be the case, though, since not converting to spectral results in grey everything.
Did more tests. This is a very challenging, slow render with 100% indirect light, where I let light bounce off three colored walls before it reaches the camera. I have a few versions of it:
RGB:
Spectral:
Spectral (the other walls are nearly black):
The RGB version of that comes out nearly black. Didn’t bother finishing to render that one.
The light bounces off a red wall, then a green wall, then the final one is evidently blue.
Note not just the coloration of the blue wall, but also the reflections on the floor and ceiling. In the spectral version, there’s significantly more red there. And the backside wall looks slightly warmer in color. (It’s a grey wall but the bounce light of the red and green wall make it yellowish)
Using “A Certain Delorean” by Chris Kuhn from Blend Swap.
The diffuse passes seem to have their color’s switched.
Spectral Dif Dir, Ind, Col
Cycles RGB Dif Dir, Ind, Col
Something else that is interesting:
That’s a strange issue with the passes indeed. I’ll do a test to see if I can replicate and understand the problem.
So yeah the colour channel seems to be swapped with the other one, like diffuse direct is coloured and diffuse colour just contains light strength. Really odd but it should be a relatively simple fix (though it’s sort of low priority for me right now, since I would rather get more features in than fix something that can be worked around)
One more really simple test: Pure-colored Subtractive color filters in front of a white (RGB 1 1 1) light source of strength 3:
Two setups, first in regular cycles:
CMY color filters
RGB color filters
Then spectral rendering:
CYM color filters
RGB color filters
I wonder in how far the differences are due to tonemapping vs. this being spectral. I assume most of it really is spectral rendering in action, but some of those colors might shift.
Note that even “perfect” RGB filters end up with a (in these lighting conditions) dark brown shade in the center. Which is, of course, entirely expected. That’s the color of the leftover spectrum after each of the colors filters it out.
I think it should also make a difference to go through the same color filter multiple times (multiplying the spectrum making it more saturate) which would not cause any change at all in regular cycles, if you pass light through a pure R, G, or B color filter multiple times. (If you don’t use RGB values set to 1, then it would make a difference of course)
EDIT: I did an additive version real quick and it’s interesting. Now this might be entirely tonemapping but for some reason the circles of light look bigger in RGB than Spectral. (You probably aren’t gonna be able to tell at a glance. Gotta flip back and forth) - It might be that they are visually just brighter.
Truthfully I don’t even know why there is such a visible circle edge in the first place: All three light sources are point lights which should radiate the same in all directions.
Camera and light positions and intensities are the same. Everything is the same.
RGB:
Spectral:
Transfer functions impact intensity, but not chromaticity, although per channel they can and do, without more sophisticated approaches. “Tonemapping” here isn’t relevant because the current set of transforms dump the scene radiometry 1:1 out through the display linear output. So while there is a chance there is a small degree of chromaticity skew due to the way display referred transfer functions are applied per channel, there isn’t much of a chance it is skewing too wildly.
Can be deceptive as the “rings” are Mach bands and a psychophysical phenomena. They may very well be playing a role in the perceived differences. Given the mixing is spectral, it would also be plausible the mixtures over the fuzzy ranges of light are generating different edge values via the energy mixtures as it tapers off.
And again, there is no gamut mapping happening at all in the default two display output types, so the idea of “tonemapping” doesn’t apply here.
Looked up what mach bands are real quick and I’m not sure we’re talking about the same thing here? - I mean the very most intense ring for each color. Not multiple bands in each. I’d think that the most intense point is right under the light source - the point on the plane that’s closest to the light source.
But as far as I can tell the brightest ring is quite far away from the center below each light source. And in the spectral version, that ring is smaller.
That “ring” is the Mach bands making an appearance.
If you open up both images in an image editor, you’ll see that while the reflectivity is slightly different, as we’d expect given that the surfaces are reflecting in RGB versus spectral, the sharper outer “ring” that can be seen is entirely psychophysical, which is exacerbating the appearance of the falloff.
If we disrupt the visual field, the phenomena disappears. As you can see, the spatial dimension of the green luminous ring is much more challenging to discern when the psychophysical edge enhancement is disrupted:
TL;DR: The intensity of the falloff differences when comparing RGB to spectral are, as expected, different, but not nearly as different when the psychophysical illusion of Mach bands is disrupted.
Ok, thanks. Vision is weird.
There’s definitely a difference in that falloff, as we can expect due to the nature of those differences in processing.
It’s also really hard to evaluate with the blasted Mach band edge enhancement happening. A bit mind boggling really. If you look, you can see it starting to happen around the boxes I slapped on your samples; the green goes “lighter” just after the box, as though there is a green glow just behind the grey outline.
It seems that spectrally the falloff is faster. This kinda matches with my earlier tests involving absorption wherein deeper bounces were both more saturated (as expected) and darker than the RGB version
