Unfortunately not yet, running into some troubles with it.
1 Like
You can try this build, it’s the last one before Cycles X was merged into the spectral branch and also has spectral nodes.
Just tested Filmic’s new “There be Dragons” experimental update, this is amazing!
All these comparisons below are rendered with Spectral Cycles:
EDIT: Now moved here:
I can’t wait for the spectral version of it with IE white point adaption etc! This is awesome!
24 Likes
Wow that looks exciting !
Thanks for all your work on this @troy_s.
For context, does this address some of the issues left with the implementation of spectral rendering ?
1 Like
It’s a baby step of an attempt. Nothing firm. Just one viable baby step toward something that might be a “better” option. I would like to see if it is possible to have the attenuation a little lower in the meaty range of the image, but it’s a tricky surface!
It is one shortcut of a potentially more acceptable solution. It comes with other complexities, but the results are at least potentially more “appropriate” than the previous.
It really needs more testers to see if the values can be tuned a bit, and the more detailed problems with transform names etc.
If this pushes forward, I would like to make sure colour transform aliases are in place so folks can use prior work seamlessly without it tripping up over string identifiers for transforms.
All testing appreciated. It should be noted that the Apple P3 and BT.1886 display types snapped with this modification, and should not be used.
6 Likes
Will the final version come soon or will it be “years”? I really want something like this to be shipped with the official Blender master, or at least the Spectral Cycles branch. I think the spectral branch needs an at least acceptable image formation before it merges to Blender master, so when people make comparison videos of RGB vs Spectral, they won’t point at the glaring out-of-gamut skews and say “spectral sucks”
On that part, I think it messes up the classroom scene:
I don’t think the alias is working here:
Also checked my other files, they didn’t work
EDIT: Strange, some files work, some don’t
I think we should continue discussing this bug (?) in the Blender Artists thread since this is not really about spectral
The current sky texture seems to fail (completely black) if the OCIO config is changed to something else. I guess it’s related to the white point thing but it really feels like a bug @pembem22
What build are you using? I haven’t tested the branch in a while, so there might be some issues.
I am still using the August 2021 build on GraphicAll, not sure if this is still the case in the latest version. Well… This is one of the reasons why I have been waiting for Smilebags’ new build.
Good news and bad news. Good news is that I have been able to get debug builds working again, bad news is that it fails to run the ‘release’ build.
4 Likes
Nevermind, turned out to be the new config does not have an XYZ role, solved by copy & pasting the Linear XYZ IE space and the role to the new config.
2 Likes
A question about the new spectral reconstruction in the lastest spectral branch (that I haven’t got a build to play with yet), does it mean that the spectral reconstruction now does not hardcode BT.709 primaries anymore? If the image texture node has the input colorspace drop down set to P3, the reconstruction will reconstruct the color from P3 instead of BT.709?
Just putting this here guys, in case you missed it (from the recent rendering meeting)
- Christophe Hery (Facebook)
7 Likes
This is a deeper and challenging question.
Given that there is an assumption that when three channels are approximately reconstructed to a spectral distribution, there’s a need for the spectral distribution to contain a sampling of all spectra.
If this condition is not met, the reconstruction will end up with “gaps” in the resulting spectra. That means that all of the spectral “goodness” folks expect, would be missing; the spectral interactions would be interacting with the gaps.
As we “widen” the RGB footprint in terms of spectral locus area in terms of the CIE xy chromaticity diagram, we implicitly force ourselves to spikier and sharper spectra, reducing the value of the spectral reconstruction from RGB!
I am sure a local minimizer approach could likely find the maximal gamut RGB footprint that produces a sum of R+G+B yielding a flat Illuminant E spectra, but I sure haven’t done it!
Hope this helps to illustrate the tricky nature of the RGB working space choices involved here.
1 Like
Right, and eventually if the input is BT.2020 the primaries would just be three spikes of single wavelengths, and the scene response would be extreme.But I think the “spikiness” is also a part of the spectral feature, like metamerism etc.
Hmm is that how it works though? Individually reconstruct the three primaries and try to mix the three spectra to Illuminant E? Not sure if that’s how I understand it.
From the link Pembem posted:
colour.recovery.XYZ_to_sd_Jakob2019
Recover the spectral distribution of given RGB colourspace array using Jakob and Hanika (2019) method.
It reads to me that it would first convert the triplet of a specified RGB colorspace, to the XYZ space, and then reconstruct it to spectra.
illuminant (Optional [ SpectralDistribution] ) – Illuminant spectral distribution, default to CIE Standard Illuminant D65 .
And there is a parameter for white point as well, nice.
So it seems to me that it should respect the color input’s colorspace. I want to comfirm this since I believe we used to use Burns work that was hardcoded for BT.709 reflectance.
I’m not sure whether the new spectral upsampling model @pembem22 worked on implementing covers a footprint larger than sRGB, it is based on a lookup table so the bounds of the available gamut for upsampling is defined ahead of time. We had some troubles with that approach so have reverted to summing spectral sRGB primary ‘lights’. This means we’re still limited to converting RGB colours to spectra in the sRGB gamut. Other means of specifying a spectrum still allow for arbitrarily saturated colours (such as the spectrum curves node).
I have an idea for a unique method of representing smooth spectra with 3 values, but I haven’t validated the idea so it may not perform well enough to be practical. For the initial patch we’ll most likely be sticking to the sRGB-based light-summing approach for spectral upsampling. All approaches I’m aware of will also require the use of a lookup table, and there is some gaps in my knowledge around creating a lookup table that covers the entire visible gamut and is fast to sample.
6 Likes
Yes, this method allows to reconstruct even the entire visible gamut, though it won’t be perfect. You can find all of that in the paper. In that case it’ll be hardcoded to XYZ and OCIO will perform all required conversions from any color space, at least that’s how I imagine it’ll work.
Right now this reconstruction method is disabled because there are bugs, but you can easily enable it in the code by changing 1 to 0 on line 184 in intern/cycles/kernel/util/color.h.
2 Likes
As per @pembem22, this is 100% correct. Working through this, it would be reasonable to subdivide reconstruction into at least two categories:
- Selecting “within” a given CIE xy footprint. For example, it is entirely reasonable that someone may wish to constrain their reconstruction to a specific as-though-they-were-in-RGB domain. In this case, I strongly believe that summing to equal energy remains an important facet for individuals interested in a rapid reconstruction that maximizes spectral overlaps / effects.
- The general reconstruction for within the entire spectral locus, gaps or otherwise.
The least slope approach has been around since Smits at Pixar. Given that internally the original reconstruction was illuminant E, I would say it’s not quite the same, but identical general approach. I firmly believe Illuminant E is critically important to keep the biasing out of the math.
The larger issue really is a reasonable mechanism to build-spectra-yourself, without the overhead of a full blown spectral distribution curve.
I believe that it is possible to have a very fluid spectral UI design that is of a general close proximity to the existing paradigm of an HSV wheel.
Imagine an HSV wheel with “pegs” that can be moved around the outside. Exactly like the standard triangle inside ring versions that are already out there.
This covers “hue”, except we can think of the circle as being a normalized version of the locus. There’s a means to derive this as well, colourimetrically speaking.
For “saturation”, consider the pin position as the central wavelength of a Gaussian. The Gaussian width would be the “saturation” slider, where maximal “saturation” corresponds with purity, and minimal would represent a maximally FWHM Gaussian, essentially a flat illuminated E.
For “value” it would be the emission strength, or amplitude, of the given chosen model. EG: Could be closed domain image range, open domain general emission range, or something else.
So for a “simplistic” baby step in a direction that allows image makers to transition, this could at least seem like a mental-model friendly step in the right direction. And for more sophisticated spectral compositions? Just a matter of enabling multiple “pin drops” around that outer ring. In terms of palettes of mixtures designed, I believe that’s three floats per pin position:
- Dominant wavelength or compliment for purples.
- Width of Gaussian.
- Amplitude of emission.
Here’s a very rudimentary mock-up. The history scroll and swatch sample were for another design, but the general idea should be communicated within this.
Slight tangent, but it makes sense to explore user interface ideas, as the future is right in front of us. Having some general ideas out there might help someone to bridge to the next steps.
14 Likes
Just did some test against the August 2021 build from Graphic All. I don’t understand why but I think it is actually successful in reconstructing the P3 gamut:
Not sure if it’s my workflow being wrong or something. I had the color sweep texture’s input colorspace set to P3(OCIO stanza copied from Filmic Blender on GitHub), and the working RGB space was still BT.709, and had the texture be an emission plane, and the camera was right above it. And then Turned on the spectral switch and render. I used the new Convert Colorspace node to convert the render result from the working BT.709 space to XYZ (the Resolve diagram seem to have problems with negative values), and then export it to Resolve (timeline space set to CIE XYZ) for the CIE xy diagram. And boom, it roughly matches the P3 triangle!
Not sure why but if I am not doing it wrong here I think it just happens to work!