<p>It's fine to use photometric units as an overall scale for setting light brightnesses. However, there's a technical subtlety you should be aware of. I'll quote from <a href="http://www.reedbeta.com/blog/2014/08/17/radiometry-versus-photometry/" rel="noreferrer">a blog post I wrote on the subject last year</a>:</p>
<blockquote>
<p>With RGB images, it’s important to recognize that our display devices behave more radiometrically than photometrically. A red pixel value of 255, and a green pixel value of 255, both result in about equal amounts of <em>radiant</em> flux (watts) being generated by a pixel on a screen—<em>not</em> equal amounts of luminous flux. By the same token, digital cameras capture pixel values that correspond to radiant flux, not luminous flux.</p>
<p>That’s why we need to use luma coefficients when converting images to grayscale, or calculating the brightness of a pixel, to get a perceptually accurate result; and it also means that rendering RGB images proceeds more naturally in radiometric units than in photometric ones.</p>
</blockquote>
<p>In other words, the wavelength dependence of photometric units is different to what you might be expecting. In ordinary RGB color spaces, white is (1, 1, 1) and has a roughly flat radiometric spectrum; but in a supposed &quot;photometric RGB&quot;, (1, 1, 1) would not be white; it would be a purpleish color, with less energy in the green range and more in the red and blue ranges. A similar problem would afflict spectral renderers trying to measure all their bins in wavelength-dependent photometric units, but even worse, as the radiance needed to generate a given luminance <em>diverges</em> toward either end of the visible spectrum, where the human luminous efficiency function goes to zero.</p>
<p>So, if you wish to use photometric units, IMO it's better to &quot;cheat&quot; a bit and not use <em>true</em> wavelength-dependent photometric units, but just use some fixed wavelength (such as 555 nm green, which is the peak of the human luminous efficiency function), or perhaps an average over the spectrum, as a reference unit, and apply that single unit to measure all wavelengths. This will get you in less trouble when importing RGB colors and spectra from other sources, and when generating them as outputs.</p>

CC BY-SA 3.0
2016-02-03T07:55:00.923Z
2016-02-03T07:55:00.923Z
2020-06-18T08:32:12.800Z
Nathan Reed
<p>In traditional rendering, it is typical to do all the calculations with radiometric units, either as full spectral rendering, or component-wise (XYZ, RGB, etc).</p>

<p>However, as modern rendering adds more physically based models, it's convenient for artists to be able to specify values in the more familiar photometric units, for example, intensity of a light in lumens. </p>

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

<p>In order to keep the pipeline all in one type of unit, you can do one of the following:</p>

<ol>
<li>Convert photometric units to radiometric units using <a href="https://en.wikipedia.org/wiki/Luminous_efficacy" rel="noreferrer">luminous efficacy</a></li>
<li>Keep the entire render pipeline in photometric units

<ul>
<li>Sébastian Lagarde presents this idea very well in the course notes of his Siggraph 2014 presentation <a href="http://www.frostbite.com/2014/11/moving-frostbite-to-pbr/" rel="noreferrer">Moving Frostbite to PBR</a></li>
</ul></li>
</ol>

<p>My questions then are these:</p>

<ol>
<li>Are there any disadvantages to rendering exclusively in photometric units? 

<ul>
<li>As far as I can tell, photometric units are just radiometric units biased to the human eye. Considering that we will view the final image with our eye, I don't see this as a problem.</li>
</ul></li>
<li>Frostbite is a RGB component-wise engine. Would a spectral renderer have any additional disadvantages by rendering exclusively in photometric units?</li>
</ol>

<pbr><render><photometric>
Rendering in radiometric units or photometric?
RichieSams
# Rendering in radiometric units or photometric?

(Asked by: username_0 on 2016-02-02)

In traditional rendering, it is typical to do all the calculations with radiometric units, either as full spectral rendering, or component-wise (XYZ, RGB, etc).

However, as modern rendering adds more physically based models, it's convenient for artists to be able to specify values in the more familiar photometric units, for example, intensity of a light in lumens.

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

In order to keep the pipeline all in one type of unit, you can do one of the following:

1. Convert photometric units to radiometric units using [luminous efficacy](https://en.wikipedia.org/wiki/Luminous_efficacy)
2. Keep the entire render pipeline in photometric units
   * Sébastian Lagarde presents this idea very well in the course notes of his Siggraph 2014 presentation [Moving Frostbite to PBR](http://www.frostbite.com/2014/11/moving-frostbite-to-pbr/)

My questions then are these:

1. Are there any disadvantages to rendering exclusively in photometric units?
   * As far as I can tell, photometric units are just radiometric units biased to the human eye. Considering that we will view the final image with our eye, I don't see this as a problem.
2. Frostbite is a RGB component-wise engine. Would a spectral renderer have any additional disadvantages by rendering exclusively in photometric units?

**Tags:** pbr, render, photometric


---

## 1 answers

### Answer by username_1 on 2016-02-03. Score: 10 | Accepted answer

It's fine to use photometric units as an overall scale for setting light brightnesses. However, there's a technical subtlety you should be aware of. I'll quote from [a blog post I wrote on the subject last year](http://www.reedbeta.com/blog/2014/08/17/radiometry-versus-photometry/):

> With RGB images, it’s important to recognize that our display devices behave more radiometrically than photometrically. A red pixel value of 255, and a green pixel value of 255, both result in about equal amounts of *radiant* flux (watts) being generated by a pixel on a screen—*not* equal amounts of luminous flux. By the same token, digital cameras capture pixel values that correspond to radiant flux, not luminous flux.
>
> That’s why we need to use luma coefficients when converting images to grayscale, or calculating the brightness of a pixel, to get a perceptually accurate result; and it also means that rendering RGB images proceeds more naturally in radiometric units than in photometric ones.

In other words, the wavelength dependence of photometric units is different to what you might be expecting. In ordinary RGB color spaces, white is (1, 1, 1) and has a roughly flat radiometric spectrum; but in a supposed "photometric RGB", (1, 1, 1) would not be white; it would be a purpleish color, with less energy in the green range and more in the red and blue ranges. A similar problem would afflict spectral renderers trying to measure all their bins in wavelength-dependent photometric units, but even worse, as the radiance needed to generate a given luminance *diverges* toward either end of the visible spectrum, where the human luminous efficiency function goes to zero.

So, if you wish to use photometric units, IMO it's better to "cheat" a bit and not use *true* wavelength-dependent photometric units, but just use some fixed wavelength (such as 555 nm green, which is the peak of the human luminous efficiency function), or perhaps an average over the spectrum, as a reference unit, and apply that single unit to measure all wavelengths. This will get you in less trouble when importing RGB colors and spectra from other sources, and when generating them as outputs.


---

