Thursday, May 3, 2012

Race Conditions

I implemented global luminance estimation, which is required by MLT to weight samples correctly.  Previously, I had just guessed a value for the scene, which was responsible for the overly-bright images of late (I had moved the camera and not adjusted the estimate to reflect the new scene).

Conceptually, the absolute easiest way to implement this is to just keep a global variable that stores the cumulative luminance as well as the sample count, and have each thread update the variables correspondingly when a new sample is taken.  Of course, the immediate objection is that you've got >100 readers/writers all vying for control of these variables at once.  Epic race condition.

Just like any other good CS140 student, I avoided the path involving race conditions without even stopping to think and try it.  Instead, I implemented a per-thread luminance estimate.  Not surprisingly, I got a lot more fireflies than previously, since each thread doesn't necessarily have a good estimate until many, many samples are taken.  Although the image looked good in terms of luminance, it just wouldn't cut it - the fireflies took too long to subside.

So I tried the stupid thing.  And you know what?  It worked.  Race conditions and all.


Finally we get to see the ship at a different angle without the crazy overbright of the previous images.  And no fireflies (I mean, if you consider that all of the samples are being used, that's going to give a pretty awesome luminance estimate!)

PS ~ Forgot to mention that luminance samples should only be recorded when a large step is taken - mutated steps don't reflect the real luminance average!

No comments:

Post a Comment