<blockquote>
  <p>Is it reasonable to expect the image of the described scene to be "in grayscale"? If so, do light intensity spectra indeed are required to be multiplied by D65 spectrum? </p>
</blockquote>

<p>My expectation from a physically-based spectral rendered is that it would</p>

<ol>
<li>compute the physical spectra</li>
<li>use the CIE color matching functions to relate that to a quantified color space (eg CIEXYZ)</li>
<li>convert that into the destination color space.</li>
</ol>

<p>D65 shall not appear anywhere till step 3, and only if we actually render into sRGB (or similar).</p>

<p>A flat spectra translates to <code>XYZ = (0.33, 0.33, 0.33)</code>, which is <code>RGB = (1.20, 0.95, 0.91)</code> prior to gamma compression. So the "red tint" is the expected result following the above procedure.</p>

<p>Don't know why Mitsuba would have such a 'feature'.</p>

CC BY-SA 4.0
2020-01-07T05:20:49.280Z
2020-01-07T05:20:49.280Z
Yakov Galka
<p>I'm trying to implement a spectral path tracer and comparing results from my program with renders of the same scene done with <code>pbrt</code> and <code>mitsuba</code>. The scene is just some spheres in a box with one point light. All the surfaces have simple Lambertian BRDFs. The light has "uniform" spectral intensity (i.e., every wavelength has same power as others), same holds for surface reflectances. When I try to render the <a href="https://gist.github.com/dmikis/3c66718d27fa672219d618a96c95f7ff#file-mitsuba-xml" rel="nofollow noreferrer">scene</a> in <code>mitsuba</code> I get a "grayscale" image, as expected:</p>

<p><a href="https://i.sstatic.net/xxBsY.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/xxBsY.png" alt="Mitsuba render"></a></p>

<p>However, if <code>pbrt</code>'s used to render the <a href="https://gist.github.com/dmikis/3c66718d27fa672219d618a96c95f7ff#file-pbrt-pbrt" rel="nofollow noreferrer">same scene</a>, result image has a reddish tint:</p>

<p><a href="https://i.sstatic.net/XhqUA.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/XhqUA.png" alt="enter image description here"></a></p>

<p>With my program I get similar result:</p>

<p><a href="https://i.sstatic.net/u8SyF.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/u8SyF.png" alt="enter image description here"></a></p>

<p>After some digging through source code, I believe difference lies in <code>mitsuba</code> <a href="https://github.com/mitsuba-renderer/mitsuba/blob/master/src/librender/scenehandler.cpp#L592" rel="nofollow noreferrer">multiplying</a> spectral intensities by D65 spectrum.</p>

<p>Is it reasonable to expect the image of the described scene to be "in grayscale"? If so, do light intensity spectra indeed are required to be multiplied by D65 spectrum? Again, if so, why <code>pbrt</code> doesn't do it?</p>

CC BY-SA 4.0
2021-01-07T07:02:43.170Z
Spectral power distribution resulting from light's interaction with an object needs the spd for D65 and the reflectance/transmittance spd of the object, that is probably why `mitsuba` is multiplying spectral intensities with D65. See McCluney, 1994, Introduction to Radiometry, p. 371 - 372
Kaan E.
<raytracing><color><spectral>
Reddish tint with spectral renderer
Kirill Dmitrenko
# Reddish tint with spectral renderer

(Asked by: username_0 on 2019-07-10)

I'm trying to implement a spectral path tracer and comparing results from my program with renders of the same scene done with `pbrt` and `mitsuba`. The scene is just some spheres in a box with one point light. All the surfaces have simple Lambertian BRDFs. The light has "uniform" spectral intensity (i.e., every wavelength has same power as others), same holds for surface reflectances. When I try to render the [scene](https://gist.github.com/dmikis/3c66718d27fa672219d618a96c95f7ff#file-mitsuba-xml) in `mitsuba` I get a "grayscale" image, as expected:

[![Mitsuba render](https://i.sstatic.net/xxBsY.png)](https://i.sstatic.net/xxBsY.png)

However, if `pbrt`'s used to render the [same scene](https://gist.github.com/dmikis/3c66718d27fa672219d618a96c95f7ff#file-pbrt-pbrt), result image has a reddish tint:

[![enter image description here](https://i.sstatic.net/XhqUA.png)](https://i.sstatic.net/XhqUA.png)

With my program I get similar result:

[![enter image description here](https://i.sstatic.net/u8SyF.png)](https://i.sstatic.net/u8SyF.png)

After some digging through source code, I believe difference lies in `mitsuba` [multiplying](https://github.com/mitsuba-renderer/mitsuba/blob/master/src/librender/scenehandler.cpp#L592) spectral intensities by D65 spectrum.

Is it reasonable to expect the image of the described scene to be "in grayscale"? If so, do light intensity spectra indeed are required to be multiplied by D65 spectrum? Again, if so, why `pbrt` doesn't do it?

**Tags:** raytracing, color, spectral

> **Comments:**
> **username_1**: Spectral power distribution resulting from light's interaction with an object needs the spd for D65 and the reflectance/transmittance spd of the object, that is probably why `mitsuba` is multiplying spectral intensities with D65. See McCluney, 1994, Introduction to Radiometry, p. 371 - 372  

---

## 1 answers

### Answer by username_2 on 2020-01-07. Score: 0 | Accepted answer

> Is it reasonable to expect the image of the described scene to be "in grayscale"? If so, do light intensity spectra indeed are required to be multiplied by D65 spectrum?

My expectation from a physically-based spectral rendered is that it would

1. compute the physical spectra
2. use the CIE color matching functions to relate that to a quantified color space (eg CIEXYZ)
3. convert that into the destination color space.

D65 shall not appear anywhere till step 3, and only if we actually render into sRGB (or similar).

A flat spectra translates to `XYZ = (0.33, 0.33, 0.33)`, which is `RGB = (1.20, 0.95, 0.91)` prior to gamma compression. So the "red tint" is the expected result following the above procedure.

Don't know why Mitsuba would have such a 'feature'.


---

