Bias is introduced when applying a display transform or clamping before scaling down the image. And there’s nothing wrong with some bias at that stage of the rendering pipeline if it gives a better looking image, actual cameras can also do a bunch of image processing for that reason. We don’t need to imagine being more “physically correct” or “unbiased” to justify it.
Had performed various tests (no clamping used) and no bright pixels were clamped, but merged/averaged to better represent light distribution. Since usually only single bright pixels appear. On the other hand, if clamping is activated, certain (same) light contribution is simply cut off (glass, indirect bounces & all that jazz gets darkened). It’s similar with AA, just down sampling larger image - not ruining the thin red line/ but preserving colors/values, again for more accurate representation.
Did you save the intermediate images as linear OpenEXR files? If not, you applied a display transform and clamping without realizing. William’s test above showed that clamping with the appropriate value can give a similar result in terms of noise (but not aliasing).
I’m handling this by reducing the brightness for camera and sometimes even singular ray (if reflections are bright in the first place), rougher materials get the full value as the aliasing problems disappear in the rougher spread. I’m sure there are situations where supersampling would be the only way to tackle this, but why not render in oversize and gain control over the resize quality later?
Yup 32bpc (lossless) all the way, then transform only after final output is confirmed & approved. Have already wasted too much time on clients ignorance & then fixing, explaining why every detail/bit matters. Especially when standards are in play.
To me it’s simple. Save time, power, memory… save resources - optimize, be more efficient, have an advantage. Automatize & evolve further.
We save milliseconds on clicks, relentlessly coming up with tiny ideas, but rarely stop and look at the broad picture… never considering holistic approach to optimize our processes. “There’s no time to contemplate, no time to experiment.”, but my logic tells me, it’s better & more productive to save 30min. in one go than saving same amount of time over 18.000 clicks (click ~100 milliseconds).
Even in time - caustics are beautiful.
Right, having better antialiasing for bright area lights builtin would be to make it quicker and easier to discover. Note also that with an actual camera you usually get bloom around such bright edges, and doing the same for a render can hide the aliasing too.
There’s no way just averaging linear OpenEXR files will get you a better looking render though. As long whatever you’re doing works for you that’s fine, to add some improvement in Cycles the detailed operations being performed do matter of course.
Well fireflies are correct, theyre only just a less likely route to a lamp, like a shortcut, some extra lightbeam bounce, the question to ask is should after so many samples those for the pixel ‘solution’ be overiden by such a strong result.
-perhaps they should increase with less intensity.
-or more beams width that path should get attentention (as was the case in adaptive sampling)
32bpc (lossless) all the way, then transform only after final output is confirmed & approved. Have already wasted too much time on clients ignorance & then fixing, explaining why every detail/bit matters. Especially when standards are in play.
