RenderToolbox / RenderToolbox3

Matlab toolbox for managing graphics rendering for psychophysics
Other
5 stars 2 forks source link

[CLOSED] What physical units do renderers write to image files? #9

Closed benjamin-heasly closed 9 years ago

benjamin-heasly commented 9 years ago

Issue by benjamin-heasly Thursday Feb 14, 2013 at 22:48 GMT Originally opened as https://github.com/DavidBrainard/RenderToolbox3/issues/8


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 commented 9 years ago

Comment by benjamin-heasly Thursday Feb 21, 2013 at 17:33 GMT


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 commented 9 years ago

Comment by benjamin-heasly Thursday Feb 21, 2013 at 17:46 GMT


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...

benjamin-heasly commented 9 years ago

Comment by DavidBrainard Wednesday Mar 06, 2013 at 21:15 GMT


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 commented 9 years ago

Comment by benjamin-heasly Thursday Mar 07, 2013 at 17:29 GMT


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 commented 9 years ago

Comment by benjamin-heasly Thursday Mar 07, 2013 at 17:29 GMT


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

benjamin-heasly commented 9 years ago

Comment by benjamin-heasly Thursday Mar 07, 2013 at 20:29 GMT


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