Bug #240

Spectrum to RGB inconsistency

Added by Jens Olsson about 11 years ago. Updated about 11 years ago.

Status:ClosedStart date:02/12/2014
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-Estimated time:4.00 hours
Target version:-

Description

Hi,
I've been seeing quite noticeable color hue differences comparing between 3-band and multispectral Mitsuba. I spent today trying to nail down what the differences are, here are my findings:

1. Some of the samples use <spectrum ... value="1.0"/> for light sources. These light sources will render as white in 3-band, but a shift towards red in multi-spectral. My conclusion is that for a multi-spectral rendering, it should be set to D65 spectrum to match the 3-band behaviour. This is probably a documentation issue, but it has really bugged me and cost time that the demo scenes render out quite differently in some cases. It is possible that a <spectrum ... value="1.0"/> could be directly converted to a D65 for illuminants, but maybe just being clear in documentation that you need to avoid such simple initialization of light sources for multispectral. (see attachment for screenshots of what the denim scene looks like)
2. For a very simple scene with diffuse material <spectrum ... value="1.0"/>, and D65 spectrum for light source, the result is correct in CPU rendering, but still noticeably color shifted in OpenGL rendering. I only managed to get both renderers consistent by converting material spectrum to linearRGB with a combined CIE 10/D65 weight function. I left illuminant spectrum conversion as is. It was nontrivial to create a fix since the linearRGB call is called from a location without context on whether we are converting a material or illuminant spectrum. As to whether it is correct to weight by combined weight function or not, I took inspiration from the following page as well as optprop-library for matlab:

http://personalpages.manchester.ac.uk/staff/david.foster/Tutorial_HSI2RGB/Tutorial_HSI2RGB.html

3. Just to confuse some more, I noticed the point lights in the irawan samples specifies spectrum properties named "radiance" instead of the correct "intensity", leading them to be ignored.

Cheers,
Jens

denim_color_differences.zip (1.05 MB) Jens Olsson, 02/12/2014 02:48 pm

3band_singleone.png (30.2 KB) Jens Olsson, 02/13/2014 06:51 am

3band_lotsofones.png (50.8 KB) Jens Olsson, 02/13/2014 06:51 am

spectrum-1s.zip (1.75 KB) Jens Olsson, 02/13/2014 12:45 pm

doc.pdf (405 KB) Wenzel Jakob, 02/13/2014 05:41 pm

History

#1 Updated by Wenzel Jakob about 11 years ago

  • Status changed from New to Feedback

Hi Jens,

I think it's to be expected that there will be some differences between RGB and spectral renderings even in fairly trivial cases. For instance, it's not at all clear how to convert RGB reflectance values into color spectra. Some heuristics are used for this at the moment that will definitely cause some differences. I myself almost never use the spectral feature, so this has not bothered me much so far. I'm all ears if you have some suggestions for improving this part of Mitsuba -- but I probably won't have much time to work on this by myself.

3) is fixed now.

Wenzel

#2 Updated by Jens Olsson about 11 years ago

Hi Wenzel,
Thanks for the quick update. Agreed, we do expect slightly different results, but what I was concerned about is that <spectrum ... values="1.0"/> and <spectrum ... filename="lotsof1s.spd"/> gives different results even in the 3-band version of Mitsuba (see attached images). From the documentation, I got the feeling that this produces a uniform, continuous spectra:

"A useful shortcut to get a completely uniform spectrum, it is to provide only a single value"

And I guess it does in an RGB sense, but not in a spectrum sense! So, minor nitpicking aside, I know what to watch out for now, and it's definitely more on the side of documentation than anything needing fixing.

Cheers,
Jens

#3 Updated by Wenzel Jakob about 11 years ago

Hi Jens,

weird! That definitely sounds like a bug... Can you sne me your SPD file and the XML scene which made this image?

Wenzel

#4 Updated by Wenzel Jakob about 11 years ago

also, I will need to know your compilation flags, particularly SPECTRUM_SAMPLES.

#5 Updated by Jens Olsson about 11 years ago

Scene is attached. This behaviour is vanilla Mitsuba 0.4.5 from your site. I've only tried it with my 47-band for spectral otherwise, and there both are identical. Is the single value just copied straight over to each band? Could explain why there's a difference in the RGB version.

Cheers,
Jens

#6 Updated by Wenzel Jakob about 11 years ago

thanks -- just to clarify, you compiled Mitsuba with -DSPECTRUM_SAMPLES=47?

#7 Updated by Jens Olsson about 11 years ago

Yes,
Just remember that you won't see the problem there :-D

Cheers,
Jens

#8 Updated by Jens Olsson about 11 years ago

And to clarify,
the output of 47-band Mitsuba matches the one where you feed multiple 1s to 3-band Mitsuba.

Cheers,
Jens

#9 Updated by Wenzel Jakob about 11 years ago

aaaaah, now I get it. So the difference you were experiencing happens just in standard RGB mode?

Right -- in that case, <spectrum value="1"/> will create a RGB vector [1,1,1]. On the other hand, an external file with a discretized constant spectrum will be transformed to RGB via the CIE curves, resulting in a different value. Kind of stupid when I come to think of it now.. Unfortunately I'm sure that there are now many scenes out there which assume this behavior.

Maybe there is a way to make everyone happy though: In the next release of Mitsuba, I could add an "intent" attribute for single-valued spectrum tags.

So for light sources, you could write
<spectrum name="radiance" intent="illuminant" value="1"/>
to give a multiple of a D65 spectrum with a resulting luminance of 1.

And for BRDF reflectance you'd simply write
<spectrum name="radiance" intent="reflectance" value="1"/>
to match the old behavior.

It could be made even a bit smarter so that intent="intensity" is the default inside <emitter> declarations. Old mitsuba scenes from a prior version would use intent="reflectance" everywhere by default so that they don't change.

Does that sound reasonable to you?
Wenzel

#10 Updated by Jens Olsson about 11 years ago

Yes, that sounds like a very good approach, matching the rgb-to-spectrum intents nicely. Sounds like that setup would allow one to setup all the demo scenes for instance so that they render pretty much identical on both 3-band and multispectral rendering. Scene description consistency is a big plus in my book, the less headaches to worry about the better!

Thanks for the quick help!
Jens

#11 Updated by Wenzel Jakob about 11 years ago

Hi Jens,

I have committed this change to the public repository (see the attached PDF file for the updated documentation).

Please let me know if this fixes the issue on your end. Note that you will still see some differences in the OpenGL preview, but that is hard to fix: for that rendering path it's necessary to convert reflectance spectra to RGB to do rendering in that color space -- that means that a uniform 0.5 reflector will have a reddish tint as far as OpenGL is concerned.

Wenzel

#12 Updated by Jens Olsson about 11 years ago

Hi Wenzel,
Documentation looks great, exactly what I was asking for. I'll try the code on Monday when I'm back at work.

Have a great weekend,
Jens

#13 Updated by Jens Olsson about 11 years ago

Fix works great here, the irawan samples render very similar between 3-band and 47-band.
There's a bonus line in spectrum.cpp, line:72 that breaks > 3 band builds:

Spectrum Spectrum::CIE_D65;

Thanks!
Jens

#14 Updated by Wenzel Jakob about 11 years ago

  • Status changed from Feedback to Closed

Hi Jens,

great, I'm closing this ticket then. I think the compilation issue you mention has been fixed by Edgar in the meantime (I did not see the superfluous CIE_D65 variable in the current revision).

Wenzel

Also available in: Atom PDF