I am currently experimenting with the usage of the hyperspectral output of Radiance. When running rfluxmtx command I get the following header output in the .mtx file
Now I understand that WAVELENGTH_SPLITS refers to the partitioning of the spectrum for multiplication with the material colors. However, I was wondering if this had any effect on how the bands are divided in the output of the .mtx file. So for example, if I use 24 spectral samples are the bands chosen as uniform distant bands between 300nm and 1100nm or are they defined as 8 uniform bands in each of the partitioned wavelength splits?
Just want to make sure.
You are correct in thinking that the WAVELENGTH_SPLITS parameters only affect interaction between spectral colors and the material RGB parameters. The second and third wavelengths (588 and 480) typically do not change, as these values were tuned to the default Radiance RGB color space. The first and third parameters indicate the computed spectrum, and should in all reasonable calculations cover or nearly cover the visible spectrum.
If the spectral end points exceed the visible, either into the infrared or ultraviolet, these bounds will extend the red and blue material channels, respectively. This is unavoidable, but so long as you use “x x x” for your RGB material colors, where “x” is the appropriate scaling, it will not matter to the spectral results.
The actual wavelength sampling is always the first (longest) wavelength minus the fourth (shortest) wavelength, divided by the number of components (NCOMP). In your example, each wavelength band will be 33.333nm wide, equal to (1100-300)/24.
It can be confusing that the extrema wavelengths are not themselves part of the sample set. This is in contrast to the spectra given in the scene description, where a specification of 380-780 with 21 samples will have its first sample centered at 380nm, its second sample at 400nm, and its last at 780nm. In other words, Radiance specifications use the more common at-wavelength value specifications, but internally compute between-wavelength band values. This is only exposed in the spectral matrices and pictures, and most users don’t need to worry about the minor conversions that happen internally.
I hope this clarifies the matter, but please follow-up with any further questions you may have.
Thanks for reacting to my question! This helps a lot.
So if I understand it correctly, the output of rmtxflux is just the full range as specified, but with equidistant steps as specified by NCOMP. Which is what I surmised.
Then two follow up questions.
First, from the workshop presentation in 2024, it was said we could just add our own extended reflectance spectrum to the materials in the scene to avoid the cut off at the visible range, right?
So this way I can still properly get a full spectrum effect.
Second, the output of rfluxmtx, is it ordered from long wavelength to short wavelength or the other way around. I just wanted to check since the WAVELENGTH_SPLITS parameter starts from 1100 to 300, so I was curious if this was the output order in which the values where set as well.
The components in the matrix and hyperspectral picture files always go from long to short wavelengths, to stay consistent with RGB ordering in memory. I decided it would be too awkward to add a component-reversal step conditional to the number of wavelength bands. If you really need wavelength samples in ascending order for some application, you can apply a reverse-diagonal identity matrix to the components with the -c option to rcomb or rfluxmtx, but I’ve never felt the need to do that.
Thanks for the explanation. Thanks to you I have managed to set up a proper spectral RT setup for our tool. I had a last question regarding the bin limit imposed on the spectral bands. At the moment MAXCSAMP is set to 24 in Radiance 6.0, I believe. Is it possible to, before building the Radiance setup, set this to a higher number and then build the software? My colleagues are mainly wondering if this could be expanded and I’m not sure if it would be as easy as changing a 24 to something else.
Yes, you can either change this in the src/common/color.h file to something else, or you can add a global compile option “-DMAXCSAMP=81” or similar.
Increasing this maximum costs a fair amount of stack memory during rendering, which in very deep ray trees could cause a stack overflow error. I haven’t had that happen to me, but I just want to warn you not to go too crazy with it. The memory penalty occurs regardless of the -cs command-line setting, since array sizes are fixed in the RAY struct at compile-time.
As an aside, I chose MAXCSAMP=24 after numerous tests showing little difference for typical scenes after 15 spectral bands from 380-780 nm. This of course does not hold if your spectral range extends much past the visible, and how spectrally selective sources and materials are in your simulation.