1

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.

Scott Krehbiel
  • 11
  • 2
  • 1
    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. – gandalf3 Jun 09 '15 at 18:39
  • 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. – Scott Krehbiel Jun 09 '15 at 19:38
  • 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. – TARDIS Maker Jun 09 '15 at 19:46
  • SSS is typically quite noisy, but it's possible there is a bug. You might try posting a report on the tracker – gandalf3 Jun 09 '15 at 19:52
  • 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. – Scott Krehbiel Jun 12 '15 at 17:06

0 Answers0