-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Two questions about spectral rendering and output #318
Comments
|
Hey Matt, For 1, what about the EXR extensions proposed by Fichet et al. (2021): An OpenEXR Layout for Spectral Images Cheers, Thomas |
@KelSolaar yep, that seems like the leading contender at this point! |
thank you both for helping! It is good to know that both points 1. and 2. are rather easy to integrate. For output I will probably just store all spectral data in the color channels of a couple of exr files for now. |
FWIW I've implemented Fichet et al's OpenEXR spectral encoding in pbrt-v4 and just pushed it to github. |
Thanks for that! Definitely looking forward to the v4 book release. |
Hello,
First of all, thank you for the great book. It is a really useful read to understand spectral rendering in particular and the maths behind tracing. I have two questions that are hopefully easy to answer.
How easy is it to modify the code to save spectral images as output instead of XYZ (or RGB)?
From what I gather, I would 'just' have to grab them before the SampledSpectrum method ToXYZ computes XYZ from the spectra (the Rieman sum for equ. 5.1, chapter 5.2.1). I am aware the amount of data would much larger (eg 20 times that of RGB for 20 spectral points). It would be great to have this as a cmake option in pbrt v4.
How easy is it to integrate optical dispersion, i.e. wavelength dependence of refractive index for realistic camera lenses?
The realistic camera works well, but I would like to try and add dispersion to the lens materials. Would it be ok to have a look-up table n(lambda) and grab the corresponding refractive indices from it for each wavelength while tracing instead of assuming the refractive index as constant?
I am trying to get a feeling on how deep the coding rabbit hole is for those two suggested additions. (few lines of code or engine rewrite)
The text was updated successfully, but these errors were encountered: