What physical units do renderers write to image files?

[benjamin-heasly]

We would like to know what are the physical units that PBRT and Mitsuba write in their output files.

The [[RadianceTest]] and [[ScalingTest]] examples scenes give some insight into the manipulations and parameters that affect the size of output values.

It would be nice to follow some absolute numbers through the rendering process and determine what the units really are. Radiance? Scaled radiance? Etc.

[benjamin-heasly]

We might choose a units convention for things like distances. It might be expedient to choose units that are consistent with renderer black body radiation spectra.

The docs for Mistuba 0.4 say on p25:

Note that attaching a black body spectrum to the intensity property of a emitter introduces physical units into the rendering process of Mitsuba, which is ordinarily a unitless system. Specifically, the black body spectrum has units of power (W) per unit area (m−2) per steradian (sr−1) per unit wavelength (nm−1). If these units are inconsistent with your scene description, you may use the optional scale attribute to adjust them

[benjamin-heasly]

PBRT also defines black body radiation spectra. However, it's not obvious from the scene file docs, text book, or source code if the units are the same as in Mitusba. We could test this...

[DavidBrainard]

I added RTBRadiometricUnits.m to the RadianceTest example. This computes the radiance one should obtain for the diffuser rendered in the RadianceTest example reference scene. It prompts for the intensity that one actually obtains in one waveband of the image and spits out the scale factor that one should multiply the rendered image by (at all wavelengths) to obtain an image where the units are radiance, at least for the diffuse surfaces in the image.

RTBRadiometricUnits has quite a bit of text in it that explains the logic.

We will want to check all this, but I think it would make sense to have this program read in the relevant intensities for both renderers and to store the computed scale factors in some place that that batch render program had access to them. The format for this might allow eventual incorporation of changes in pixel sampling and sampler/integrator parameters as we learn more in ScalingTest.

[benjamin-heasly]

I think we can store renderer-specific scale factors using get/setpref(). If we store them in the "RenderToolbox3" section of get/setpref(), it will be easy for users to use the persistent, default scale factors, or supply temporary, custom scale factors using "hints" structs.

We can write a "run once" utility that users can invoke. It can run the RadiacneTest scene, read output intensities from renderers, pass the intensities to RTBRadiometricUnits, and store the results with setpref(). This would capture any platform-specific scale differences, if any exist. It would also make it easy for current users to add the new scale factors to their existing "pref" values.

[benjamin-heasly]

Issue #25 deals with applying these scale factors after rendering, in BatchRender().

[benjamin-heasly]

6ef28ceb0295ed6fa870fca8e0afb34105554c48 computes scale factors to bring each renderer's outputs into physical radiance units. See Issue #25 .

[DavidBrainard]

I didn't quite do the radiometry correct when I computed the first principles scale factor. I neglected the cos(theta) dependence that should be in lambert's law, and this affects the total light scattered from the point source in the computation. This won't be hard to fix up, but I need to go through it carefully and tidy it up.

[DavidBrainard]

Fixed first principles derivation. I had been neglecting the cos falloff for a Lambertian surface. Now incorporated -- need to divide by just pi, not by 2*pi. Updated code and wiki. This may cause a factor of 2 change in all the images.