Thread: Brightness compensation for display monitors

No, I'm not having problems with my display or anything. All is working correctly.

I am working on antialiasing lines and curves. There is a point along a line of single pixel width,
where the line is rendered by two pixels of 1/2 intensity each. This occurs where the line passes
between the two pixels; where the line passes directly through a pixel center, the pixel is at full
intensity. The problem is that the two half intensity pixels are not as bright as the single full intensity
pixel. So you get a line that periodically varies in brightness along it's length.

The reason for this is the nonlinearity of the pixel value to perceived brightness curve of LCD displays.
Video cameras (and most light sensitive and light producing devices, I suspect) also have a nonlinearity.
The function for this curve, and it's correction, is normally called gamma.

Display adaptors are often supplied with utilities for adjusting the gamma for the red, green, and blue
intensities. Monitors also usually have a utility for adusting the colors in one way or another, though
not necessarily the actual gamma.

I can always adjust my monitor for an optimum display, or make the corrections in my program for an
optimum display. But I don't have access to many other displays to test that things look acceptably good
on all of them.

So I guess my question is actually several questions:

Is it common for PC users to adjust their displays for optimum colors and contrast?

Is it common for monitor manufacturers to incorporate gamma compensation in the monitor itself?

Is there a gamma type compensation curve in general use within programs?

And so then, where is the best place, if any, to apply a gamma type correction? Within my program?

I don't want to correct things within my program, for my own display, only to make things look worse
everywhere else.

-

O_o

1): Yes. You can find various implementations in the wild.
2): Yes. You can find various implementations in the wild.
3): Nope. Every display is different, and few people have the time, equipment, and eyesight to expend the effort.
4): Yes. Video cards and drivers often also provide some adjustable behavior.
5): Yes. Several. You can find these by searching for "gamma correction" followed by operating system/software.
6): What you are trying to do? How are you trying to do it?

As for the general theme of the questions, use generic defaults and provide a means of configuring the "scheme" to fit the monitor which the user may use if they so choose to change the "scheme".

Soma

You're getting into a complex area with this question. The fundamental problem is how to reproduce color intensities in a way that gives the intended impression to the viewer. There are a number of non-linearities in the system. The most important non-linearity is actually within the human visual system. Another big non-linearity occurs in the response of the display device. The non-linearity of the human visual system is mostly fixed from person to person. It can vary significantly from one display to another.

The high grade solution is to carry full color profile information through all stages of the imaging process. This is really the only way to ensure that the visual appearance is as it was intended on a given device. Unfortunately there is no way of verifying that the color profile in use at each step of the chain is actually the correct profile, i.e. things may not be properly calibrated. For printed material the process is even more complicated because it has to account for the likely illumination conditions.

The ideal situation would be a properly calibrated monitor and a video card which can correctly interpret color profile information, as well as a color profile describing the image signal you are generating. Some of this is under your control but a lot of it is not.

For your specific case where a linear stimulus doesn't look right, the best you can probably do is apply your own gamma correction and tune it until you like the results. It will look different on other displays, no real getting around that.

Both my monitor and display [...] program window, etc.

O_o

Everything you've said is a rehash of what you've already said which is a description of your question.

I asked about your problem.

What are you doing drawing "lines and curves" "by hand"?

Are you writing a game? Are your writing a SVG viewer? Are you just learning theory?

If this is still your fractal viewer, I'd say leave the gamma correction to the display and video card drivers because near perfect reproduction across diverse hardware isn't a selling point of fractals.

If you are doing something where near perfect reproduction is a target, you should consider investing the time to provide a means for "calibrating" your software.

So is it safe to assume that most users will have their display gammas set to "flat" (uncorrected)?

No.

Of course, that is also irrelevant.

Why?

Would it still be good to provde a utility for optimizing the display, anyway?

Because I'm not going to adjust my display for your software.

I have equipment which I've used to calibrate my monitor.

I have equipment and my own software which I've used to find a point of balance between my good monitors and my good printers so that while both are "off" they are mutually consistant.

I am not going to change that for you or your software.

If for whatever reason you do want to provide gamma correction for your software, learn the algorithms to bake adjustments into your rendering algorithms so that the user may fine tune your software to their display.

If you have the extra time to also provide a utility to help optimize the display, have incredibly knowledge of the issues, understand the relationships between various displays, and have access to numbers published by various standards bodies feel free to provide such a utility. If any of these don't fit, you aren't the person for writing that "optimizing" software.

Soma

My question is "should I do that"? Are enough displays out there that are uncompensated?

O_o

I fear I did not make my point clear.

That possibility is irrelevant.

My development monitor is specifically tuned, yet your software may not look as good as it might.

My television is specifically tuned, but calibrated for the games I play which often have poor rendering for high contrasts so your software may look like crap.

My tablet has a great display, but factory--as in poorly--calibrated, yet despite such calibration your software may look great.

The variability in technologies, purpose, and manufacturing runs leaves even properly gamma compensated displays wonky in some areas.

The only question, assuming you are willing, is one of reproduction quality. If you feel what you are doing would benefit by offering gamma correction so that the view presented by your software is accurately reproduced as you've designed, the answer is providing a means to bake adjustments into rendering.

Soma

My question is "should I do that"? Are enough displays out there that are uncompensated?

O_o

I fear I did not make my point clear.

That possibility is irrelevant.

My development monitor is specifically tuned, yet your software may not look as good as it might.

My television is specifically tuned, but calibrated for the games I play which often have poor rendering for high contrasts so your software may look like crap.

My tablet has a great display, but factory--as in poorly--calibrated, yet despite such calibration your software may look great.

The variability in technologies, purpose, and manufacturing runs leaves even properly gamma compensated displays wonky in some areas.

The only question, assuming you are willing, is one of reproduction quality. If you feel what you are doing would benefit by offering gamma correction so that the view presented by your software is accurately reproduced as you've designed, the answer is providing a means to bake adjustments into rendering.

Soma

I may have misunderstood what you meant by "baked in".

O_o

You did, but fear not I could have better explained.

I use "bake" the way you might use "deserialized cache".

I understood that to mean that any corrections were being done in the line rendering process itself, and not as a separate display adjustment.

Correct. You only have one real place to do both gamma correction and anti-aliasing, and the place for those processes is while rendering your primitives before the final "pixel" is "set".

And I also understood that to mean a fixed adjustment, not something that would adapt to the system running the program.

Incorrect. I am not suggesting "static"--what you've called "fixed"--adjustments.

I am suggesting an algorithm which uses adjustments.

I am suggesting that the adjusted values be "baked".

However, I am suggesting an approach that "bakes" the values for a given environment before the rendering process allowing you to keep good performance while allowing the user to adapt the gamma correction to the hardware they have available.

If your designs--or the designs created by the program--legitimately benefit from accurate reproduction, you have little other choice.

If "baking in" is as I thought, then I understand that it is not going to give good results on all displays.

I'm sorry for the misunderstanding, but I would not suggest what you have understood.

The adjustments you make with "static" values may actually be worse for any given monitor.

If you do not wish to allow--Let us continue by calling them "dynamic" instead of "baked".-- "dynamic" adjustments, you should prefer to make no adjustments relying on the "dynamic" adjustments offered by hardware/drivers if the user so desires to tune for your software. Yes. The approach has problems, but "static" adjustments carry the same problems and requires you to expend considerable effort implementing capable algorithms.

[Edit]
An example of "baking":

I allow users (One of the my many "hobby" projects is a SVG/printer widget with a great many adjustments with the aim of "near perfect" reproduction.) to specify various color corrections in several ways. One of the available adjustments may be expressed with a cubic Bézier curve. Sampling a cubic Bézier curve to determine gamma correction for every "pixel" while accounting for every primitive in a 600 DPI rendering would be insane. I allow the cubic Bézier curve because you may easily express slight adjustments to common curves. Under the hood, the implementation uses the same "code path" as for the provided 4,8,12,16 bit correction arrays. The implementation simply "bakes" the complex "values" into something the algorithms may quickly consume.

I hope this description helps regardless your choice.
[/Edit]

Soma