<p>The clamping is done for the otherwise-jagged edge along the bright light. For pixels with the edge of the light in them, the radiance in the direction away from the center of the light is a very strong step function from (12,12,12) down to roughly (0.5,0.5,0.5) as you move across the pixel.
This edge is smoothly anti-aliased as long as your pixel values can go up to (12,12,12), but once you clamp the pixels to (1,1,1) the outline of the light edge becomes very jagged (pixelated).</p>

<p>Clamping is technically adding bias but it's a limitation of the file format and display output.</p>

<p>One possible solution that wouldn't introduce bias would be tone-mapping or underexposing the image, such as dividing the radiance values by 12, but that would change the look of the image.</p>

<p>Clamping prior to averaging (and then averaging) the subpixels is effectively the same as down-sampling the clamped subpixel image with a box filter. The subpixels are unbiased (before clamping), but the pixels written out are down-sampled from them after clamping.</p>

<p>As for down-sampling, I don't know if it's biasing but it's the same operation one would do to shrink an image to fit a smaller display, for example. It typically makes images look better but smaller.</p>

<p>You could down-sample before clamping but it would look worse. But either way you will have to clamp when writing the file to PPM format unless you get all the radiance values below 1.</p>

CC BY-SA 4.0
2018-08-23T18:31:31.067Z
**down-sampling the clamped subpixel image with a box filter** is a clever observation explaining the intent behind both the subpixel raster and clamping before averaging.
Matthias
CC BY-SA 4.0
2018-08-23T18:33:58.627Z
**I don't know if it's biasing**, it still remains a bias. You will converge to different radiance images with and without (i.e. pure path tracing) this clamping, since clamping is a non-linear operation.
Matthias
CC BY-SA 4.0
2018-08-24T20:05:30.883Z
I was referring to down-sampling. Down-sampling is optional, clamping is not.
Kevin
CC BY-SA 4.0
2018-08-24T20:39:25.607Z
There is still a final clamping in the `toInt` function.
Matthias
CC BY-SA 4.0
2018-08-23T18:04:10.240Z
2018-08-23T18:04:10.240Z
Kevin
<blockquote>
  <p>This seems, however, completely unrelated since no gamma correction is involved yet at this stage in the code.</p>
</blockquote>

<p>The values are indeed not gamma corrected. Earlier in the presentation (On page 32) you have the toInt function which does the gamma correction. This function is called when the image is written to a file.</p>

<p>Then the clamping itself.
If we have a list of 5 samples.</p>

<pre><code>0.1; 0.4; 0.2; 0.8; 0.6
</code></pre>

<p>It averages to 0.42. However, if one samples becomes very bright.</p>

<pre><code>0.1; 0.4; 8.0; 0.8; 0.6
</code></pre>

<p>The average would become 1.98. That is a lot brighter. Because we take random samples, it could be that these two averages are neighboring pixels. This would cause a few pixels in the entire image to be much brighter than their neighbors. This is called a <strong>firefly</strong>. These fireflies are often not wanted, as they stick out in the image and make it look a lot more noisy. Therefore we want to try and remove these fireflies.</p>

<p>An example image of this can be found in <a href="https://docs.blender.org/manual/en/dev/render/cycles/optimizations/reducing_noise.html#clamp-fireflies" rel="nofollow noreferrer">blender's cycles documentation here</a>. The bright pixels are fireflies and are unwanted.<a href="https://i.sstatic.net/DKQnc.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/DKQnc.jpg" alt="Image with fireflies"></a></p>

<p>There are three ways to remove a firefly.</p>

<ol>
<li>Add more samples. By adding more samples, you get a truer image and that one bright sample would end up with less influence. This does however take longer to render.</li>
<li>Some sort of denoising algorithm. The algorithm could find these fireflies and remove them. However, it will almost always change other parts of the image which is often unwanted, and there is also no room for it in smallpt.</li>
<li>Discarding the bright sample or similar. This bright sample is the culprit of the problem and we could always decide to just ignore it. However, that bright sample is there for a reason and removing it would most of the times not be the greatest idea (it also makes things more complicated). Clamping however would still allow us to somewhat discard the bright sample without actually discarding it and is very simple and easy to implement. We just make it not have such a big influence on the image.</li>
</ol>

<p>Clamping is often the choice for most render engines. If you would look at any commercial render engine, or even hobby path tracers, they allow you to clamp the samples. Normally you clamp the individual samples instead of the sub-pixels and more specifically you clamp indirect samples with its own clamping value, but they have about the same effect.</p>

<p>This clamping does change the image as it makes some areas or all darker since it removes energy (by clamping the color values) from the scene. This would become unbiased, yet it is often done (and almost always available in unbiased render engines) simply because it produces visually nicer images, because there are no fireflies and fireflies are generally worse than noise. Often you would not notice any artifacts when clamping, other than the removed fireflies.</p>

<p>In the case of smallpt, clamping it between 0.0 and 1.0 seems to work well for that one scene. However, I do recommend to just tinker with the code and render two images out for yourself, one with clamping and one without.</p>

CC BY-SA 4.0
2018-08-19T06:27:51.427Z
There will, however, be a final clamping on the unbound pixel radiances in the `toInt` method. Though the average of `0.1, 0.4, 8.0, 0.8, 0.6`; 1.98 finally clamps to 1.0, whereas the average of `0.1, 0.4, 1.0 (clamped separately), 0.8, 0.6`; 0.58 finally clamps to itself and is thus more aggressive in this case to avoid fireflies at much lower sample rates. So this indeed works as a back at the cost of bias to remove fireflies due to the high variance at low sample counts.
Matthias
CC BY-SA 4.0
2018-08-19T06:41:07.963Z
It reminds me of a related [Twitter discussion](https://twitter.com/CasualEffects/status/983009137331126272?s=19) originated from the "ray tracing tip of the day" by Morgan McGuire.
Matthias
CC BY-SA 4.0
2018-08-18T22:51:50.560Z
2018-08-19T16:32:11.233Z
2018-08-19T16:32:11.233Z
bram0101
<p>Kevin Beason's <a href="http://www.kevinbeason.com/smallpt/" rel="nofollow noreferrer">smallpt</a> estimates the pixel radiance by accumulating $2\times2$ subpixel radiance estimates using the following expression:</p>

<pre><code>c[i] = c[i] + Vec(clamp(r.x),clamp(r.y),clamp(r.z))*.25;
</code></pre>

<p>Here, <code>c[i]</code> represents the radiance estimate of the pixel with flattened index <code>i</code>, <code>r</code> represents the radiance estimate of one of its four subpixels. As one notices a <code>clamp</code> operation is used to clamp the radiance estimate of each subpixel <strong>separately</strong> to the $[0,1]^3$ range <strong>before</strong> accumulation. But this seems wrong from an unbiased path tracing perspective, since this effectively introduces bias to the radiance estimate of each pixel. So I wonder if I am missing something (e.g., clever trick at the cost of bias), given that Kevin Beason's smallpt is already around and known for nearly ten years?</p>

<p>Apparently, Kevin Beason also added a <a href="https://drive.google.com/file/d/0B8g97JkuSSBwUENiWTJXeGtTOHFmSm51UC01YWtCZw/view" rel="nofollow noreferrer">presentation</a> by David Cline explaining every line. The aforementioned expression is explained as follows:</p>

<blockquote>
  <p>Add the gamma-corrected subpixel color estimate to the Pixel color
  <code>c[i]</code>.</p>
</blockquote>

<p>This seems, however, completely unrelated since no gamma correction is involved yet at this stage in the code. And since exponential functions are non-linear transformations. (Obviously <code>clamp</code> does not involve any exponential functions at all. ;-) )</p>

<p><strong>Reference code</strong>:</p>

<pre><code>for (int y=0; y&lt;h; y++){                       // Loop over image rows 
    fprintf(stderr,"\rRendering (%d spp) %5.2f%%",samps*4,100.*y/(h-1)); 
    for (unsigned short x=0, Xi[3]={0,0,y*y*y}; x&lt;w; x++)   // Loop cols 
        for (int sy=0, i=(h-y-1)*w+x; sy&lt;2; sy++)     // 2x2 subpixel rows 
            for (int sx=0; sx&lt;2; sx++, r=Vec()){        // 2x2 subpixel cols 
                for (int s=0; s&lt;samps; s++){ 
                    double r1=2*erand48(Xi), dx=r1&lt;1 ? sqrt(r1)-1: 1-sqrt(2-r1); 
                    double r2=2*erand48(Xi), dy=r2&lt;1 ? sqrt(r2)-1: 1-sqrt(2-r2); 
                    Vec d = cx*( ( (sx+.5 + dx)/2 + x)/w - .5) + 
                            cy*( ( (sy+.5 + dy)/2 + y)/h - .5) + cam.d; 
                    r = r + radiance(Ray(cam.o+d*140,d.norm()),0,Xi)*(1./samps); 
                } // Camera rays are pushed ^^^^^ forward to start in interior 
                c[i] = c[i] + Vec(clamp(r.x),clamp(r.y),clamp(r.z))*.25; 
            } 
} 
</code></pre>

<pathtracing>
smallpt's early clamping
Matthias
# smallpt's early clamping

(Asked by: username_0 on 2018-08-18)

username_1 Beason's [smallpt](http://www.kevinbeason.com/smallpt/) estimates the pixel radiance by accumulating $2\times2$ subpixel radiance estimates using the following expression:

```
c[i] = c[i] + Vec(clamp(r.x),clamp(r.y),clamp(r.z))*.25;

```

Here, `c[i]` represents the radiance estimate of the pixel with flattened index `i`, `r` represents the radiance estimate of one of its four subpixels. As one notices a `clamp` operation is used to clamp the radiance estimate of each subpixel **separately** to the $[0,1]^3$ range **before** accumulation. But this seems wrong from an unbiased path tracing perspective, since this effectively introduces bias to the radiance estimate of each pixel. So I wonder if I am missing something (e.g., clever trick at the cost of bias), given that username_1 Beason's smallpt is already around and known for nearly ten years?

Apparently, username_1 Beason also added a [presentation](https://drive.google.com/file/d/0B8g97JkuSSBwUENiWTJXeGtTOHFmSm51UC01YWtCZw/view) by David Cline explaining every line. The aforementioned expression is explained as follows:

> Add the gamma-corrected subpixel color estimate to the Pixel color
> `c[i]`.

This seems, however, completely unrelated since no gamma correction is involved yet at this stage in the code. And since exponential functions are non-linear transformations. (Obviously `clamp` does not involve any exponential functions at all. ;-) )

**Reference code**:

```
for (int y=0; y<h; y++){                       // Loop over image rows 
    fprintf(stderr,"\rRendering (%d spp) %5.2f%%",samps*4,100.*y/(h-1)); 
    for (unsigned short x=0, Xi[3]={0,0,y*y*y}; x<w; x++)   // Loop cols 
        for (int sy=0, i=(h-y-1)*w+x; sy<2; sy++)     // 2x2 subpixel rows 
            for (int sx=0; sx<2; sx++, r=Vec()){        // 2x2 subpixel cols 
                for (int s=0; s<samps; s++){ 
                    double r1=2*erand48(Xi), dx=r1<1 ? sqrt(r1)-1: 1-sqrt(2-r1); 
                    double r2=2*erand48(Xi), dy=r2<1 ? sqrt(r2)-1: 1-sqrt(2-r2); 
                    Vec d = cx*( ( (sx+.5 + dx)/2 + x)/w - .5) + 
                            cy*( ( (sy+.5 + dy)/2 + y)/h - .5) + cam.d; 
                    r = r + radiance(Ray(cam.o+d*140,d.norm()),0,Xi)*(1./samps); 
                } // Camera rays are pushed ^^^^^ forward to start in interior 
                c[i] = c[i] + Vec(clamp(r.x),clamp(r.y),clamp(r.z))*.25; 
            } 
} 

```

**Tags:** pathtracing


---

## 2 answers

### Answer by username_1 on 2018-08-23. Score: 1 | Accepted answer

The clamping is done for the otherwise-jagged edge along the bright light. For pixels with the edge of the light in them, the radiance in the direction away from the center of the light is a very strong step function from (12,12,12) down to roughly (0.5,0.5,0.5) as you move across the pixel.
This edge is smoothly anti-aliased as long as your pixel values can go up to (12,12,12), but once you clamp the pixels to (1,1,1) the outline of the light edge becomes very jagged (pixelated).

Clamping is technically adding bias but it's a limitation of the file format and display output.

One possible solution that wouldn't introduce bias would be tone-mapping or underexposing the image, such as dividing the radiance values by 12, but that would change the look of the image.

Clamping prior to averaging (and then averaging) the subpixels is effectively the same as down-sampling the clamped subpixel image with a box filter. The subpixels are unbiased (before clamping), but the pixels written out are down-sampled from them after clamping.

As for down-sampling, I don't know if it's biasing but it's the same operation one would do to shrink an image to fit a smaller display, for example. It typically makes images look better but smaller.

You could down-sample before clamping but it would look worse. But either way you will have to clamp when writing the file to PPM format unless you get all the radiance values below 1.

> **Comments:**
> **username_0**: **down-sampling the clamped subpixel image with a box filter** is a clever observation explaining the intent behind both the subpixel raster and clamping before averaging.  
> **username_0**: **I don't know if it's biasing**, it still remains a bias. You will converge to different radiance images with and without (i.e. pure path tracing) this clamping, since clamping is a non-linear operation.  
> **username_1**: I was referring to down-sampling. Down-sampling is optional, clamping is not.  
> **username_0**: There is still a final clamping in the `toInt` function.  

---

### Answer by username_2 on 2018-08-18. Score: 4

> This seems, however, completely unrelated since no gamma correction is involved yet at this stage in the code.

The values are indeed not gamma corrected. Earlier in the presentation (On page 32) you have the toInt function which does the gamma correction. This function is called when the image is written to a file.

Then the clamping itself.
If we have a list of 5 samples.

```
0.1; 0.4; 0.2; 0.8; 0.6

```

It averages to 0.42. However, if one samples becomes very bright.

```
0.1; 0.4; 8.0; 0.8; 0.6

```

The average would become 1.98. That is a lot brighter. Because we take random samples, it could be that these two averages are neighboring pixels. This would cause a few pixels in the entire image to be much brighter than their neighbors. This is called a **firefly**. These fireflies are often not wanted, as they stick out in the image and make it look a lot more noisy. Therefore we want to try and remove these fireflies.

An example image of this can be found in [blender's cycles documentation here](https://docs.blender.org/manual/en/dev/render/cycles/optimizations/reducing_noise.html#clamp-fireflies). The bright pixels are fireflies and are unwanted.[![Image with fireflies](https://i.sstatic.net/DKQnc.jpg)](https://i.sstatic.net/DKQnc.jpg)

There are three ways to remove a firefly.

1. Add more samples. By adding more samples, you get a truer image and that one bright sample would end up with less influence. This does however take longer to render.
2. Some sort of denoising algorithm. The algorithm could find these fireflies and remove them. However, it will almost always change other parts of the image which is often unwanted, and there is also no room for it in smallpt.
3. Discarding the bright sample or similar. This bright sample is the culprit of the problem and we could always decide to just ignore it. However, that bright sample is there for a reason and removing it would most of the times not be the greatest idea (it also makes things more complicated). Clamping however would still allow us to somewhat discard the bright sample without actually discarding it and is very simple and easy to implement. We just make it not have such a big influence on the image.

Clamping is often the choice for most render engines. If you would look at any commercial render engine, or even hobby path tracers, they allow you to clamp the samples. Normally you clamp the individual samples instead of the sub-pixels and more specifically you clamp indirect samples with its own clamping value, but they have about the same effect.

This clamping does change the image as it makes some areas or all darker since it removes energy (by clamping the color values) from the scene. This would become unbiased, yet it is often done (and almost always available in unbiased render engines) simply because it produces visually nicer images, because there are no fireflies and fireflies are generally worse than noise. Often you would not notice any artifacts when clamping, other than the removed fireflies.

In the case of smallpt, clamping it between 0.0 and 1.0 seems to work well for that one scene. However, I do recommend to just tinker with the code and render two images out for yourself, one with clamping and one without.

> **Comments:**
> **username_0**: There will, however, be a final clamping on the unbound pixel radiances in the `toInt` method. Though the average of `0.1, 0.4, 8.0, 0.8, 0.6`; 1.98 finally clamps to 1.0, whereas the average of `0.1, 0.4, 1.0 (clamped separately), 0.8, 0.6`; 0.58 finally clamps to itself and is thus more aggressive in this case to avoid fireflies at much lower sample rates. So this indeed works as a back at the cost of bias to remove fireflies due to the high variance at low sample counts.  
> **username_0**: It reminds me of a related [Twitter discussion](https://twitter.com/CasualEffects/status/983009137331126272?s=19) originated from the "ray tracing tip of the day" by Morgan McGuire.  

---

