Frame buffer for spectral rendering back

(L) [2013/11/26] [ost by raider] [Frame buffer for spectral rendering] Wayback!

When sampling wavelengths, am I right that frame buffer have to accumulate values in some linear color space like CIE XYZ, and only the final image to be converted to let's say sRGB? I mean can't accumulate pixel intensity directly in sRGB as it incorporates some transfer function (gamma curve), so that two sRGB values can't be simply added to represent resulting color from two samples.

(L) [2013/11/26] [ost by ypoissant] [Frame buffer for spectral rendering] Wayback!

It is easy to linearize sRGB by de-gammaing it.

The color pipeline I use is:
1- degamma all colors (textures and colors specified as RGB from the user) when they are read from file or from input fields.
2- Do all rendering calculation using those linearized RGB colors.
3- Accumulate those RGB results in the frame buffer
4- Apply gamma to frame buffer data while transfering them to output.

(L) [2013/11/27] [ost by toshiya] [Frame buffer for spectral rendering] Wayback!

The correct order is, accumulation, tone mapping, and then gamma/color correction.

You can think of accumulation of spectral contributions as a part of Monte Carlo integration, which should be done before any image processing like tone mapping and gamma correction.

Having said that, if you can easily invert your tone mapping and gamma correction functions, you can store the final image as a frame buffer, de-gamma correct and de-tone map it, accumulate values, and then tone map and gamma correct it to do the right thing as suggested :->

(L) [2013/11/27] [ost by Serendipity] [Frame buffer for spectral rendering] Wayback!

The more interesting question to me here is: How much do you loose by accumulating the values in XYZ instead of accumulating them in a true spectral buffer and convert the accumulated result afterwards? Especially with fluorescence this would be very interesting to evaluate.

(L) [2013/11/27] [ost by ingenious] [Frame buffer for spectral rendering] Wayback!

>> Serendipity wrote:How much do you loose by accumulating the values in XYZ instead of accumulating them in a true spectral buffer and convert the accumulated result afterwards?
I suppose this depends on the spectral resolution of the (spectral) buffer. If you only use 3 spectral bins, I wouldn't be surprised if you get a less accurate result than when accumulating in XYZ.

(L) [2013/11/27] [ost by raider] [Frame buffer for spectral rendering] Wayback!

Thank you guys! It's clear for me on the framebuffer. Now, what about converting RGB textures to spectral representation? There is no unique transform from RGB to spectrum. So what is good approach here? to use scaled color matching functions or something else?

(L) [2013/11/27] [ost by friedlinguini] [Frame buffer for spectral rendering] Wayback!

There's this: [LINK http://www.cs.utah.edu/~bes/papers/color/]

(L) [2013/11/28] [ost by spectral] [Frame buffer for spectral rendering] Wayback!

Yes, there is this paper... but don't forget that your image will not completly match the spectral generated one. If you use a language like C++ it is easy to have a kind of "Spectrum" color class to handle everything, you can easily switch between the RGB/XYZ and the spectral model.
This way you can compare the results and speed.

(L) [2013/11/28] [ost by toshiya] [Frame buffer for spectral rendering] Wayback!

I also have a code that does RGB <-> spectrum conversions in my gpusppm:

[LINK http://cs.au.dk/~toshiya/gpusppm.zip]

I've tested the code and it should be fairly accurate in the sense that RGB -> spectrum -> RGB well recovers the original RGB value. It's based on that paper with some improvement.