# Small question about Bloom RT formats

This topic is 1958 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

When doing the whole bloom process do the render targets have to be FP16 like the original light accumulation target ?
Do I perform the brightpass and gaussian blur with FP16 format buffer ?
I realize I need to keep it in HDR until the tonemapping is performed, right ?

##### Share on other sites
There's no right way to do Bloom because it's basically an hack, so you do it anyway you want to achieve the result you want ;)

In my opinion using FP16 render targets in the bright/blur passes produces better results because you might get some color information during the blur that would be clipped in the bright pass if you used 8-bit render targets. Edited by TiagoCosta

##### Share on other sites
[quote name='TiagoCosta' timestamp='1346954150' post='4977288']
There's no right way to do Bloom because it's basically an hack
[/quote]
Bloom is no hack. It's actually just a part of the flares lenses produce. Because no glass is perfect a really small amount of light always gets refracted onto nearby pixels. Normal distribution (aka gaussian filter) doesn't produce the most physically correct results though. An exponential distribution is better suited for Bloom, but it's not separable thus being not well suited for a realtime application. You can approximate an exponential distribution by using multiple gaussians though which is what they are doing in CryEngine 3 and Unreal Engine 4.
Also it doesn't really make any sense to implement a bright pass to subtract a certain amount of light so that only the bright light gets blurred. That's often a sign that the engine is not actually High Dynamic Range. Light always scatters onto surrounding pixels, just a tiny amount of it, but it's completely independent of its brightness. So a proper exponential filter and maybe a multiplicative factor should be about it.

BTT: If you want to have High Dynamic Range Rendering, you should keep the Bloom in High Dynamic Range and later perform Tone Mapping to resolve it to Low Dynamic Range. Also there's no need for an actual bright pass. Just do that in the Bloom Pass to save Bandwidth.

Also a cool trick is to use a R10G10B10A2 resource as a backbuffer. Most monitors can actually display this when the application runs in full screen. So you can actually have a higher dynamic range than the usual B8G8R8A8 backbuffer. Edited by CryZe

##### Share on other sites
A R10G10B10A2 backbuffer won't give you any extra dynamic range, it will just give you more precision for the standard displayable range. Either way there's no guarantee that the display won't just convert it to something else when it outputs. Edited by MJP

##### Share on other sites
[quote name='CryZe' timestamp='1346956985' post='4977319']
Also a cool trick is to use a R10G10B10A2 resource as a backbuffer. Most monitors can actually display this when the application runs in full screen.[/quote]
Most consumer monitors (cheap TN and IPS panels) have 6-bit colour depth, and achieve 8-bit equivalence via dithering. Even mid-range IPS panels are only 8-bit (plus 2-bit dither).

Basically, if you are spending less than $1,000 per monitor, you aren't getting a truly 10-bit panel. And even in the over$1,000 range, you have to be pretty selective to find the panels specifically aimed at graphics professionals.

And that's ignoring the fact that a DVI cable only carries 8-bit colour, so you are limited to monitors that offer DisplayPort or full HDMI 1.3 support (and a graphics card to match)...