Even with setting my sampling numbers pretty high (256 diffuse and glossy samples times 16 render passes with branched path tracing) I'm still getting the very hot pixels. I read that this is caused by out-of-range sample values which the render engine never really blends in with other render passes, almost like the pixel has NaN (Not a Number) as a value. Or maybe it's more like a pixel has a value of 400, and no matter how many passes you average it with, it's still going to be really hot.

It seems that an engine should be able to filter out these extreme values, (like a median filter?) but on the other hand I hate doing something like clamping my render values because I need to keep the engine non-biased. (this will eventually be for a research project and it's vital that it be good math and a non-biased render engine. So maybe I'll need to purchase a very good non-biased engine.)

Am I correct that any method for removing outliers would then make it a biased render engine? Biased or not, numeric accuracy in the final image is the goal, so maybe even if it is technically biased with outlier removal, it might still be more accurate?

I'm not looking for techniques, such as "just blur it in Photoshop" but more theory of the rendering engine. Thanks very much for your help.

=== Update: I've found that the bright blue noise (from my emitter sky dome?) comes strictly from the Subsurface Indirect channel. I'll have to read up on subsurface scattering to make sure I'm not doing something stupid, but as strongly as this noise comes through, it makes me wonder if it's a bug in Cycles.

  • 1
    $\begingroup$ AFAIK fireflies are caused by samples which bounce through a improbable path and hit a very bright something (usually indirectly, as lights guide samples directly to themselves with MIS to mitigate this). They stick out because pixels around them never manage to get the lucky set of bounces required to hit the same bright something. I'm not a dev or a rendering expert, but I believe clamping counts as bias. As a possible alternative you might look at Luxrender or Mitsuba. $\endgroup$ – gandalf3 Jun 9 '15 at 18:39
  • $\begingroup$ Thanks gandalf3, that confirms what I had thought. It seems that the ultra-bright pixels are more a bug in the rendering engine theory than in software. Thanks very much for the link to the MIS info - it looks like this is what I will need to focus my attention on. $\endgroup$ – Scott Krehbiel Jun 9 '15 at 19:38
  • $\begingroup$ Try enabling multiple importance sampling in the settings tab in the world settings. I would then set the resolutions (I forget exactly what that slider is called) underneath it, to 1024. This should get rid of a decent amount of your noise. This basically throws more samples at the bright sections. Do you have any SSS in your scene? If you don't, you could probably leave out this pass entirely, but I don't understand why it would be there if you didn't have SSS. $\endgroup$ – TARDIS Maker Jun 9 '15 at 19:46
  • $\begingroup$ SSS is typically quite noisy, but it's possible there is a bug. You might try posting a report on the tracker $\endgroup$ – gandalf3 Jun 9 '15 at 19:52
  • $\begingroup$ After posting it as a bug on the tracker, tracker page I learned that branched path tracing does not work with the indirect Subsurface channel. So my cranking up the Samples for Subsurface did nothing for the indirect ss, leaving it very noisy at only 1 sample per AA pass. The problem was that I should have left the Samples settings relatively low and leaned much more heavily on the AA Samples. $\endgroup$ – Scott Krehbiel Jun 12 '15 at 17:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.