Bloom with threshold

[Lord Crc]

Hi,

I've been taking a few stabs at implementing thresholding for bloom, as requested in issue #631.

The straight forward method is to apply a threshold before blurring and then add this to the base image weighted by bloom amount. This however adds energy and isn't very physical.

The correct method is to use a sharp, almost delta-like, but very wide filter, ie with long non-zero lobe(s). This then has to be used with a very large radius. No thresholding is involved, instead one would use the bloom radius to control this. This method is also easy to implement but is horribly slow, unless we use FFT I guess which would be somewhat more involved.

I've managed to make a slightly hackish method using variable-width filters where the filter width is determined based on the ratio between the pixel Y and the threshold Y (as determined as a fraction of the maximum Y). The hackish part is that the method for selecting the filter width is fairly arbitrary. So far this seems to work well for thresholds above 0.4, but can lead to artifacts when using lower thresholds. May be related to my code though. It's also fast since only a small fraction of the pixels are filtered using wide filters. However it needs more testing.

I'd like some feedback as to what we should go for. If we go the FFT route (if possible) then the FFT library/routines can be used for other things, I recall there were some mantis tasks which would also need FFT.

I've attached some images using my "hack". The bloom amount was set very high to emphasize the effect.

[Abel]

I'll have to pass on the technical discussion but that first image is looking great!

[Carbonflux]

I agree, this is a great result, its hard to put my finger on exactly what is better, but a lot more details are preserved.

I agree also that the first render looks great, the metal looks rich and "glowing."



just curious, Is it possible to do FFTs in the gpu?

[tomb]

Hi,

I've been taking a few stabs at implementing thresholding for bloom, as requested in issue #631.

The straight forward method is to apply a threshold before blurring and then add this to the base image weighted by bloom amount. This however adds energy and isn't very physical.

The correct method is to use a sharp, almost delta-like, but very wide filter, ie with long non-zero lobe(s). This then has to be used with a very large radius. No thresholding is involved, instead one would use the bloom radius to control this. This method is also easy to implement but is horribly slow, unless we use FFT I guess which would be somewhat more involved.

I've managed to make a slightly hackish method using variable-width filters where the filter width is determined based on the ratio between the pixel Y and the threshold Y (as determined as a fraction of the maximum Y). The hackish part is that the method for selecting the filter width is fairly arbitrary. So far this seems to work well for thresholds above 0.4, but can lead to artifacts when using lower thresholds. May be related to my code though. It's also fast since only a small fraction of the pixels are filtered using wide filters. However it needs more testing.

I'd like some feedback as to what we should go for. If we go the FFT route (if possible) then the FFT library/routines can be used for other things, I recall there were some mantis tasks which would also need FFT.

I've attached some images using my "hack". The bloom amount was set very high to emphasize the effect.

Looks very nice With FFT we could add a diffraction glare function too (for example based on Glare Generation Based on Wave Optics (http://nae-lab.org/~kaki/paper/PG2004/K ... 4Glare.pdf, http://nae-lab.org/~kaki/paper/PG2004/K ... Presen.pdf)). I implemented this paper several years ago and I think I still have the code somewhere. It's pretty straight forward to implement and should fit the imaging pipeline well.

T

[moure]

Looks very nice With FFT we could add a diffraction glare function too (for example based on Glare Generation Based on Wave Optics (http://nae-lab.org/~kaki/paper/PG2004/K ... 4Glare.pdf, http://nae-lab.org/~kaki/paper/PG2004/K ... Presen.pdf)). I implemented this paper several years ago and I think I still have the code somewhere. It's pretty straight forward to implement and should fit the imaging pipeline well.

that would be great tomp, cant wait for it

[jeanphi]

Hi,

Great result Lord Crc, and tomb you have a nice idea, that's a long requested feature. Additionally FFT is doable on GPU, I guess it must have been one of the first things tested with GPGPU given how often they are used in numerical computation.

Jeanphi

[Lord Crc]

If we add my method, I think it would be wise to add a "bloom method" selector. This way it would be backwards compatible, old flms would use old bloom method, and users have a choice for "low threshold" situations.

[SATtva]

Or, maybe, if a user sets threshold below 0.4 or 0.3, we should silently fall back to the old bloom method? I'm just a bit worried of the number of knobs, we already have plenty of them.

[jeanphi]

Hi,

I agree with SATtva, Lux already tends to look like a plane cockpit. We should really aim for artist friendliness at the interface level.

Jeanphi

[Lord Crc]

Fair enough, I'll try to find some good values so the crossover isn't too discontinuous.