Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 10 of 10

Thread: Brightness/Contrast

  1. #1

    Brightness/Contrast

    Hi,
    I tried to find an answer to some "contrast" question but I couldn't, because no one anwered on this Forum
    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

    Thanks.

  2. #2
    Member Regular Contributor
    Join Date
    Nov 2000
    Location
    Belmont, CA
    Posts
    254

    Re: Brightness/Contrast

    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

  3. #3

    Re: Brightness/Contrast

    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?

  4. #4
    Member Regular Contributor
    Join Date
    Nov 2000
    Location
    Belmont, CA
    Posts
    254

    Re: Brightness/Contrast

    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

  5. #5
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    2,704

    Re: Brightness/Contrast

    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).
    "If you can't afford to do something right,
    you'd better make sure you can afford to do it wrong!"

  6. #6
    Member Regular Contributor
    Join Date
    Mar 2002
    Location
    Vancouver
    Posts
    314

    Re: Brightness/Contrast

    XF86VidModeSetGamma for X.

  7. #7

    Re: Brightness/Contrast

    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.

  8. #8
    Senior Member OpenGL Pro
    Join Date
    Feb 2002
    Location
    Bonn, Germany
    Posts
    1,652

    Re: Brightness/Contrast

    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.

  9. #9
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    2,704

    Re: Brightness/Contrast

    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 ;-)
    "If you can't afford to do something right,
    you'd better make sure you can afford to do it wrong!"

  10. #10
    Junior Member Newbie
    Join Date
    Oct 2009
    Posts
    21

    Re: Brightness/Contrast

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •