Jump to content
  • Advertisement
Sign in to follow this  
piluve

Bloom,gamma correction, tone mapping , lens flares, proper order?

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello guys, hope you are doing well.

 

This week I'll start working on postprocessing for my demo scene and I would like to add some effects like bloom or lens flares. I've been reading some blogs and information related with this effects and most of this sources say that you should apply this effects in a specific order. 

This is what I understand of each effect:

 

+ HDR: basic render targets stores color in the range of 0-255 (0-1), many scenes will generate colors beyond this mark for example specular highlights. We can use floating point render targets so values wont be clamped.

+ Bloom: Takes bright parts of the image, blurs them and adds to the final scene (it gives a cool glare effect). It works well with HDR as the bright values can be bigger than 1.

+ Lens flares: Its an effect that happens when the light interacts with the lens of a camera.

+ Tone mapping: transforms the HDR values to the expected LDR values.

+ Gamma correction: adjust the color curve so it matches with the monitor.

 

In my engine, I'm using a forward rendering pipeline. At the end of the frame, I have a framebuffer with all the stuff rendered that frame.

This is how I would do the postprocessing:

Bloom->Lens flares->tone mapping->gamma correction

(All of the steps are using floating point textures)

 

What do you think?

Thanks!

Share this post


Link to post
Share on other sites
Advertisement

 

Bloom: Takes bright parts of the image, blurs them and adds to the final scene

IMHO, it should be the whole image, not just the bright parts. The versions of bloom that appeared before HDR, you had to use some kind of threshold value to extract only bright parts, but that makes no physical sense. Bloom is the light being blurred by imperfections in the lens (either your eye, or smudges/etc on the camera lens... ), and it's impossible to construct a lens that will let through X number of photons perfectly, and then blur all other photons. Natural lighting effects are additive and multiplicative, but thresholding is a subtractive (unnatural) effect. In my HDR pipeline, I just multiply the scene by a small value, such as 1%, instead of thresholding -- e.g. 1% of light refracts through the smudges taking blurry paths to the sensor, and 99% take a direct path. Changing that multiplier will change how smudged or imperfect your lens is.
However, after doing this, the end result is similar - you only notice the bloom effect on bright areas :D

Gamma correction: adjust the color curve so it matches with the monitor

You should do tone-mapping and output gamma correction at the same time. You never want to go from one 8-bit colour space to another 8-bit colour space, because doing so will lose information in the process and you don't have enough precision to spare at only 8-bits. So when you go from 16-bit HDR down to LDR in the tone-mapper and are about to output the results to an 8-bit buffer, that's the perfect time to convert to the output colour space.

As well as adjusting the output curve of your tone-mapper, you also have to adjust your input textures. Your textures are (hopefully) being authored by an artist on an sRGB monitor, so they're visualizing those 0-255 values in the sRGB colour space (which is approximately the same as gamma-2.2). In your shaders, you need to make sure that this texture data is converted from sRGB/gamma-2.2 to linear-RGB/gamma-1.0 before you do any lighting calculations with it. You can do that in your shader with code, or use the HW accelerated sRGB decoding (e.g. the *_SRGB texture formats in D3D, or the sampler state in GL).

 

Hey!

I like your approach for the bloom, it seems more natural that way.

For the gamma correction, I should only apply it when I sample an albedo texture, right?

Edited by piluve

Share this post


Link to post
Share on other sites
You can use the SRGB texture format to have the hardware conversion for you.
About the post process :

A few prerequisites should be met to make sure you get the best HDR experience out of a game:

  1. Make sure your rendering pipeline supports PBR and floating point surface formats right until the end of the frame.
  2. Remove all clamping or saturating operations from shaders that run after the tone mapping pass.
  3. Ideally move all of your post-processing effects to run before tone mapping happens.
  4. Switch over a tone mapper that properly understands output display luminance. We’ve found an ACES derived pipeline to work well.

Source : https://developer.nvidia.com/implementing-hdr-rise-tomb-raider

Edited by Alundra

Share this post


Link to post
Share on other sites

 

You can use the SRGB texture format to have the hardware conversion for you.
About the post process :

A few prerequisites should be met to make sure you get the best HDR experience out of a game:

  1. Make sure your rendering pipeline supports PBR and floating point surface formats right until the end of the frame.
  2. Remove all clamping or saturating operations from shaders that run after the tone mapping pass.
  3. Ideally move all of your post-processing effects to run before tone mapping happens.
  4. Switch over a tone mapper that properly understands output display luminance. We’ve found an ACES derived pipeline to work well.

Source : https://developer.nvidia.com/implementing-hdr-rise-tomb-raider

 

Hello, I'll check how Opengl handles sRGB textures and thanks for that article its really informative!

Share this post


Link to post
Share on other sites

 

Bloom: Takes bright parts of the image, blurs them and adds to the final scene

IMHO, it should be the whole image, not just the bright parts. The versions of bloom that appeared before HDR, you had to use some kind of threshold value to extract only bright parts, but that makes no physical sense. Bloom is the light being blurred by imperfections in the lens (either your eye, or smudges/etc on the camera lens... ), and it's impossible to construct a lens that will let through X number of photons perfectly, and then blur all other photons. Natural lighting effects are additive and multiplicative, but thresholding is a subtractive (unnatural) effect. In my HDR pipeline, I just multiply the scene by a small value, such as 1%, instead of thresholding -- e.g. 1% of light refracts through the smudges taking blurry paths to the sensor, and 99% take a direct path. Changing that multiplier will change how smudged or imperfect your lens is.
However, after doing this, the end result is similar - you only notice the bloom effect on bright areas :D

 

That's quite interesting. What puzzles me  is should result of this multiplication and further blurring be stored in HDR format(ex. 16F) and then compose with HDR result(to not lose informations) or is it correct to do tonemap after multiplication and store result in SDR format? (To improve performance)

Edited by Armus

Share this post


Link to post
Share on other sites

That's quite interesting. What puzzles me  is should result of this multiplication and further blurring be stored in HDR format(ex. 16F) and then compose with HDR result(to not lose informations) or is it correct to do tonemap after multiplication and store result in SDR format? (To improve performance)
Yeah all lighting calculations should be done in unbounded (HDR) linear formats. Some games use 10/11 bit colours though, so that they can fit into a 32bit texture for performance reasons.

Some games also do what you mention, and do bloom in non-HDR (perhaps after tone-mapping) for performance reasons too...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!