benjamin-heasly
commented
11 years ago I discussed this with David. We decided it's not that useful to duplicate the renderer promotion code on the Matlab side.
Working with RGB textures already implies that we don't know the original spectra, so why try to represent them? Also, promoting from RGB only gives us 3 degrees of freedom, so even knowing the promotion algorithm would not put us in the spectral domain. If we really want spectral textures, we should extend the renderers to accept multi-channel OpenEXR files.
Instead, we can write a utility that tests the promotion code:
- specify an RGB color and a light spectrum
- make a scene with a point light and a reflector, wrapped in a texture with RGB color.
- what is spectrum of an output pixel from within the reflector?
This would expose the renderer promotion behavior without our having to duplicate the renderer code.
We can use this utility in a new example scene:
- get the output spectrum for several initial RGB colors, perhaps based on Macbeth ColorChecker spectra
- convert the output spectra to sRGB. How different are they from the original RGB colors?
- How sensitive is this difference to the light spectrum?
DavidBrainard
It would be useful to use RGB texture images in spectral renderings.
But these raise the question of how the renderers promote RGB triples to spectral representations. We want to know the answer, so that we can predict renderer behavior and specify other spectra that play well with the automatically promoted spectra.
David started implementing some Matlab spectral promotion code, based on the PBRT and Mitsuba source code.