Jump to content
  • Advertisement
Sign in to follow this  
areddevil

HDR float pixel issue

This topic is 3661 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

Hi! I'm trying to implement a simple IBL scene but i have some problems with flickering pixels. they are barely noticable in the original rendering but when I run the scene through a blur filter they become more obvious. Blurred image currently I render the scene to a texture (using FBO) which I then use as input to the blur filter (fragment shader). the texture that is attached to the FBO has the following setup
glTexImage2D(GL_TEXTURE_2D, 0,GL_RGBA16F_ARB, width, height, 0, GL_RGBA, GL_FLOAT, NULL);

I'm running this on a 7600GT card and know that it supports floating point textures (according to GLEW) and beacuse the tonemapoperation works perfectly. so I'm wondering why the pixels are flickering and is there a way to fix that?

Share this post


Link to post
Share on other sites
Advertisement
I'm not sure because I didn't see your program in motion, but based on the description it could simply be an aliasing problem ?
Aliasing

Maybe the blur is based on the low resolution version of your image and some of the details of your image become too high frequency so that they are not visible at every frame (or "jump" from pixel to pixel) and so cause flicker.

What you can do is apply some antialiasing before blurring.
For example supersampling : say if your blur texture is 512x512, render to some higher resolution like 1024x1024, downsample by taking the average of 4 samples in 512x512. You can also apply a larger kernel (say 16x16 with some gaussian distribution), because you're using HDR then a bright spot will likely cause saturation within a pixel and using a larger kernel filter will reduce the impact of that "saturation" (avoiding the "jump from pixel to pixel" situation). Ideally for the movement to be totally smooth initial resolution should be infinite and kernel cover the whole screen (or you can limit the brightness by scaling it down) but we know it's not possible, so try to find a spot that satisfies you at the right level of performance.

LeGreg

Share this post


Link to post
Share on other sites
hellooo!

Quote:

I'm not sure because I didn't see your program in motion, but based on the description it could simply be an aliasing problem ?


yes there is some aliasing but that is not my main concern at this point.
I was probably a bit unclear regarding the issue. what I meant was that some blocks of pixels become completely white while others become completely black. I have now realized that this is due to overflow (+inf, -inf) but i don't know how to solve this problem.
overflow issue (blurred image)
I should also mention that black pixels only appear around the edge of the objects because of some refraction vector issue (i guess).
I have tried clamping the values but as you can imagine that does not give any good results.
How do people handle this problem?

Share this post


Link to post
Share on other sites
Underflow or NaNs ? ("special numbers" in float representation).

NaN if used in a calculation will propagate. One very typical way to get a NaN : have a very large number become +inf due to the limit of fp16 (65k max !) then that +inf get multiplied by zero. Zero*inf = Not a number. Other case involve square rooting (computed by taking x * invsqrt(x)) if x is zero invsqrt is inf and 0*inf, well.

For the overbright white pixels you have to expect that. So I don't think it's a bug "per se" unless it causes some aliasing problems that cause flickering see my post above. If you hit the case where one very big number becomes +inf (if larger than 65k in fp16 representation) you could simply scale your values down to bring them below that max value, you have plenty of range available below 1.0 too to preserve precision.

But of course it might be something else depending on what you do in your computations..

LeGreg

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!