PDA

View Full Version : Brightness/Contrast



Bobo.Bobo
03-31-2004, 12:07 PM
Hi,
I tried to find an answer to some "contrast" question but I couldn't, because no one anwered on this Forum :p
I'm trying to change contrast in realtime while rendering a full screen quad with 4 textures using pixel shader (so I cannot use PS to make contrast, because it's already busy). Do you have any idea how to make it done?
I found something like glModelview(GL_COLOR); and after that to make some operations, but it is very slow, it causes 1/3 slowdown in my program and I don't know why :p

Thanks.

Won
03-31-2004, 05:24 PM
For contrast, you can do a blend with a gray quad (or better, whatever the mean color of your scene is) where the alpha channel is the amount of contrast you want. For brightness, do the same thing with a white quad. Use blendFunc(src_alpha, one_minus_src_alpha).

Unfortunately, I think you can only reduce contrast with this approach because alpha might be getting clamped. There may be some way to get around this with some blending extension.

Assuming you get around the clamping issue, you can perform many different image processing operations just by blending between an image and a processed image; contrast and brightness just happen to be really simple. This was covered in the 3Dlabs GLslang talk. You might want to check out the lecture slides, but it won't help your immediate problem.

-Won

Bobo.Bobo
04-01-2004, 03:40 AM
Thanks.
But I want to increase contrast :)
I know that in graphics control panel I can change the whole screen contrast by driver directly. Do you think that this is possible to make it from my app?

Won
04-01-2004, 04:35 AM
Just look at what other blending modes are available. I'm sure you're clever enough to find one that will work this technique if one exists.

-Won

jwatte
04-01-2004, 02:16 PM
Your windowing system should allow you to change contrast of the monitor. On Windows, it's SetDeviceGammaRamp(). On MacOS and X windows, I have no idea (but I'm pretty sure at least the Mac can do it).

pkaler
04-01-2004, 04:11 PM
XF86VidModeSetGamma for X.

Bobo.Bobo
04-01-2004, 11:43 PM
Thanks! This is exactly what I wanted :)
Now I can change Gamma, Contrast, Brightness, and do whatever I want to do with all colors!
I hope all new drivers and graphics cards supports this function.

zeckensack
04-02-2004, 05:55 AM
Originally posted by Bobo.Bobo:
Thanks! This is exactly what I wanted :)
Now I can change Gamma, Contrast, Brightness, and do whatever I want to do with all colors!
I hope all new drivers and graphics cards supports this function.No offense, but IMO you shouldn't do "whatever you want" if that includes contrast and brightness.

There are two things that really should stay fixed, and that's black level and gain (aka white level). Users can set that stuff on their monitor controls, and once done properly, there really isn't a good reason to change that.

I find it somewhat annoying when I see contrast and brightness controls in commercial app (such as UT2k3, UT2k4, Painkiller, etc), because they just don't work. Monitor controls for this are analog, which is exactly the reason why these do work.

All that application controls here ever achieve are inability to display proper black and/or white, or reduced dynamic range due to saturation of the "gamma ramp" on either end. This can happen because it's a digitalish thing.

Moreover, black level is fundamentally system global. White level is equally global, and depends on user preference, i.e. how bright/how old the monitor is, and how much luminance they can tolerate.

Please think carefully about that.

A real gamma ramp in the true meaning of the word is, of course, a clean thing to use, because it won't affect the system global black and white levels.

Ultimately all artists and developers should work with completely linear display response, so that, say, a texel will only be 0.5 if they intend it to be 50% grey. This can be achieved with gamma alone. End users could then also set their gamma to whatever gives them linear response.
This automatically linearizes blending and texture filtering without any further tricks.

jwatte
04-02-2004, 02:22 PM
Because of the 8-bit resolution thing, I'm pretty sure we're stuck with assuming 2.2 gamma, and thus a 0.5 pixel is not 50% gray.

However, everyone should be using the SAME assumption of 2.2 gamma ;-)

Zildjian
01-18-2010, 10:10 AM
Sorry to dig up this old thread, but given it's pushing six years old now, I think it's long overdue for an update.

Using monitor controls for brightness and contrast is simply impractical in powerwall, CAVE, and other multi display environment. The application will need to set up a cross-display communication system to share average luminance information and auto-adjust brightness and contrast levels to emulate the human eye response to entering a dark or bright environment.

It seems like shader-based brightness and contrast is the only solution to these types of situations. Applications can render to floating point texture, then adjust brightness and contrast in shaders when rendering a fullscreen textured triangle pair. There's no reason why this type of software control wouldn't work, as implied in a previous post.