<p>It looks like you're clamping all your samples to 0-1 in line 215. Apply clamping only when displaying the image, not when accumulating samples.</p>

CC BY-SA 4.0
2019-01-11T20:14:39.137Z
Ok I think i get what you are telling me. So basically the color obtained on any pass can be greater than 1. And this extra information is lost when i clamp. I don't think it'd make such a great deal as the main problem is still averagin with samples giving 0 color. But anyway, how are you supposed to handle that in a progressive PT?
gallickgunner
CC BY-SA 4.0
2019-01-13T09:47:18.377Z
In a progressive path tracer you'd still need to store the total value and number of samples so far per pixel, otherwise there is no way to calculate the average when you take new samples. You'd only clamp it for display purposes
trichoplax is on Codidact now
CC BY-SA 4.0
2019-01-13T10:05:10.303Z
I'll try storing the total color in the w coordinate since I'm using a float4 and pass a single variable for number of iterations to the kernel. Will post resutls shortly.
gallickgunner
CC BY-SA 4.0
2019-01-13T10:13:25.947Z
Ok i totally forgot it's three channels worth of information :s How the heck am I suppose to store 3 channel worth information. That's basically an extra image passed to the kernel just for storing un clamped values?
gallickgunner
CC BY-SA 4.0
2019-01-13T13:58:07.913Z
Many thanks for pointing it our bro. I was at it for days.
gallickgunner
CC BY-SA 4.0
2020-05-16T18:06:45.393Z
To clarify, you never want to clamp values in the pathtracer - the only reason clamping is necessary is to fit the radiance value computed by the pathtracer into a range that will "fit" into an image. Linearly mapping radiance to final image values can also result in darks looking too dark and brights clipping, so you'll want to do some tonemapping to fix that
adrian
CC BY-SA 4.0
2019-01-11T20:04:39.607Z
2019-01-11T20:04:39.607Z
Stefan Werner
<p><a href="https://i.sstatic.net/Jyt1Z.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Jyt1Z.png" alt="enter image description here"></a></p>

<p>So I just thought of comparing the results from a Naive Path tracer and one using Next Event Estimation aka Explicit Direct Light Sampling. However the results from the Naive PT are very dark.</p>

<p>Is this expected? The one with next event estimation produces brighter images like in my <a href="https://computergraphics.stackexchange.com/questions/8444/multiple-importance-sampling-in-path-tracer-produces-dark-images">previous</a> question which was related to MIS</p>

<p>I thought that a Naive PT would produce images with the same brightness but more noise and it would take longer to converge. The main reason for dark images I think is because I'm averaging the colors obtained from the previous run with the next run. On each run I shoot 1 sample per pixel. </p>

<p>This means if I take 20 samples (20 passes) and only 2 samples (<span class="math-container">$S_1$</span> and <span class="math-container">$S_2$</span>) are useful (hit the light in the end) and 18 return 0 since they don't hit the light, I'd be doing, </p>

<p><span class="math-container">$\displaystyle{\frac{S_1 + S_2 + 0*18}{20}}$</span></p>

<p>The brighter colors will surely get averaged out. Moreover they won't converge or in other words they won't get brighter since the number of useless samples surely outweigh the number of useful samples. However in every implementation I could find over the net, people averaged it simply like I did. So is that actually a problem or is it expected?</p>

<p>I stumbled upon <a href="https://computergraphics.stackexchange.com/questions/7915/should-direct-illumination-and-path-tracers-render-the-same-scene-equally-bright?rq=1">this</a> question which is pretty much the same thing OP is asking but in the end they find problem with the raytracer and not the path tracer. I don't understand.</p>

<p>If you guys are interested in the code, <a href="https://github.com/gallickgunner/Helion-Render/blob/master/naivept.cl" rel="nofollow noreferrer">here</a> is my kernel. The main functions to look for are <code>shading()</code> which contains the whole bouncing around portion. <code>EvaluateBRDF</code> simply evaluates the blinn phong model. The averaging out is done in the main kernel <code>evaluatePixelRadiance</code> in the end.</p>

<p>UPDATE:- So I corrected what Stefan pointed out and removed color clamping. I was using an 8bit depth default framebuffer and RBO of 32 bit floating points. So I guess the data gets clamped automatically when blitting to the default framebuffer. And it seems to have solved the issue. I'll update the results shortly.</p>

<p>I think this solved my MIS issue as well, will share results on MIS post soon. Here is the one for naive-PT, 5000 samples in around 10 seconds. And it seems I was not getting fireflies since i was clamping radiance as expected. Good to learn new things :)</p>

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

<pathtracing><sampling>
Naive Path tracer produces much darker images than Explicit light sampling
gallickgunner
# Naive Path tracer produces much darker images than Explicit light sampling

(Asked by: username_0 on 2019-01-11)

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

So I just thought of comparing the results from a Naive Path tracer and one using Next Event Estimation aka Explicit Direct Light Sampling. However the results from the Naive PT are very dark.

Is this expected? The one with next event estimation produces brighter images like in my [previous](https://computergraphics.stackexchange.com/questions/8444/multiple-importance-sampling-in-path-tracer-produces-dark-images) question which was related to MIS

I thought that a Naive PT would produce images with the same brightness but more noise and it would take longer to converge. The main reason for dark images I think is because I'm averaging the colors obtained from the previous run with the next run. On each run I shoot 1 sample per pixel.

This means if I take 20 samples (20 passes) and only 2 samples ($S\_1$ and $S\_2$) are useful (hit the light in the end) and 18 return 0 since they don't hit the light, I'd be doing,

$\displaystyle{\frac{S\_1 + S\_2 + 0\*18}{20}}$

The brighter colors will surely get averaged out. Moreover they won't converge or in other words they won't get brighter since the number of useless samples surely outweigh the number of useful samples. However in every implementation I could find over the net, people averaged it simply like I did. So is that actually a problem or is it expected?

I stumbled upon [this](https://computergraphics.stackexchange.com/questions/7915/should-direct-illumination-and-path-tracers-render-the-same-scene-equally-bright?rq=1) question which is pretty much the same thing OP is asking but in the end they find problem with the raytracer and not the path tracer. I don't understand.

If you guys are interested in the code, [here](https://github.com/username_0/Helion-Render/blob/master/naivept.cl) is my kernel. The main functions to look for are `shading()` which contains the whole bouncing around portion. `EvaluateBRDF` simply evaluates the blinn phong model. The averaging out is done in the main kernel `evaluatePixelRadiance` in the end.

UPDATE:- So I corrected what username_1 pointed out and removed color clamping. I was using an 8bit depth default framebuffer and RBO of 32 bit floating points. So I guess the data gets clamped automatically when blitting to the default framebuffer. And it seems to have solved the issue. I'll update the results shortly.

I think this solved my MIS issue as well, will share results on MIS post soon. Here is the one for naive-PT, 5000 samples in around 10 seconds. And it seems I was not getting fireflies since i was clamping radiance as expected. Good to learn new things :)

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

**Tags:** pathtracing, sampling


---

## 1 answers

### Answer by username_1 on 2019-01-11. Score: 3 | Accepted answer

It looks like you're clamping all your samples to 0-1 in line 215. Apply clamping only when displaying the image, not when accumulating samples.

> **Comments:**
> **username_0**: Ok I think i get what you are telling me. So basically the color obtained on any pass can be greater than 1. And this extra information is lost when i clamp. I don't think it'd make such a great deal as the main problem is still averagin with samples giving 0 color. But anyway, how are you supposed to handle that in a progressive PT?  
> **username_2**: In a progressive path tracer you'd still need to store the total value and number of samples so far per pixel, otherwise there is no way to calculate the average when you take new samples. You'd only clamp it for display purposes  
> **username_0**: I'll try storing the total color in the w coordinate since I'm using a float4 and pass a single variable for number of iterations to the kernel. Will post resutls shortly.  
> **username_0**: Ok i totally forgot it's three channels worth of information :s How the heck am I suppose to store 3 channel worth information. That's basically an extra image passed to the kernel just for storing un clamped values?  
> **username_0**: Many thanks for pointing it our bro. I was at it for days.  
> **username_3**: To clarify, you never want to clamp values in the pathtracer - the only reason clamping is necessary is to fit the radiance value computed by the pathtracer into a range that will "fit" into an image. Linearly mapping radiance to final image values can also result in darks looking too dark and brights clipping, so you'll want to do some tonemapping to fix that  

---

