After some experiments with displaying images in mplay, especially floating point linear, I found that gamma correction is applied before Gain/Contrast/Offset corrections, and I think it's not quite correct, because gamma correction is intended to compensate gamma curves of viewing device.

For example, I'm trying to analize floating point linear image, I set gamma to 2.2 in mplay for my sRGB monitor, and with all other knobs set to default it looks correct.
But when i try to over/underexpose image, it starts to look wrong, because gamma correction is applied before my exposure corrections, so exposure actually corrects and applied gamma curve itself, which is wrong because I want gamma correction to stay at 2.2 anyway without any dependency with gain/contrast or offset knobs.

so what do you think about it?

Offhand, I wouldn't agree gamma in mplay is *primarily* to adjust your monitor's display - it's for altering the gamma of the image. The issue of monitor display is a different one. I see monitor calibration as a separate process - here we use Cinespace for that, it maintains an accurate display, and should you want to alter the gamma of what you're looking at you use that. Mplay offers a quick and dirty way to alter it should you want that, but I'm not sure the order of operations in a viewing program is specifically designed for what you're trying to do. I'd be doing that in a compositor.

Having said that, I'm not sure of the ramifications of altering that - what it might affect(good and bad) in the behaviour of the program.

J.C.

The order of the operations is
Gamma -> Brightness -> Contrast -> Bright Shift

However the UI's layout is
Brightness | Contrast | Bright Shift | Gamma

Regardless of whether gamma should be applied first or last I think the UI's layout should reflect the order of the operations.

JColdrick
Offhand, I wouldn't agree gamma in mplay is *primarily* to adjust your monitor's display - it's for altering the gamma of the image.

The other meaning for the user is the ability to tweak these values by eye to check different tones in image, and here is exact values and order of operations doesn't matter at all, i think.

JColdrick
The issue of monitor display is a different one. I see monitor calibration as a separate process - here we use Cinespace for that, it maintains an accurate display, and should you want to alter the gamma of what you're looking at you use that.

Can't agree with that - I think you are tangle display calibration with output display gamma of display, for the first one, Cinespace is required, but not for the second! It's because Cinespace is working with 8bit image (already sent to display) and linearizing images with it would lead to vizible banding in shadow areas, especailly on dark images, which is completely inacceptable. Mplay, on the other hand, have all floating point information about the image, and can do that preceizely accurate.

JColdrick
Mplay offers a quick and dirty way to alter it should you want that, but I'm not sure the order of operations in a viewing program is specifically designed for what you're trying to do.

For what it designed then? I described my opinion in first quote.

JColdrick
I'd be doing that in a compositor.

That's absolutely true, but doing so for each test render, i.e. loading images to compositor just in order to see it correctly, isn't a very comfortable way IMHO.

Wolfwood
The order of the operations is
Gamma -> Brightness -> Contrast -> Bright Shift

However the UI's layout is
Brightness | Contrast | Bright Shift | Gamma

Regardless of whether gamma should be applied first or last I think the UI's layout should reflect the order of the operations.

Absolutely true.
Maybe it's needed to add a checkbox somewhere in mplay preferences intended to reverse the order of these operations?

You're missing my point. Without colour calibration, you're wasting your time trying to use the gamma control in an image viewer as some sort of end device display control, which was your original comment. I was responding to that. I agree about the GUI order being incorrect, though. I wonder how many people will shriek if it gets moved around to be “correct”?

J.C.

I just like to differ things.
For color calibration, I assume moving all our displays to one standard, for example, sRGB, where gamma curve is fixed at 2.2 value. It's ok because of limited (8-bit) space of videocards and monitors.
Then I need just to map my linear images into sRGB space (with a simple gamma correction), that I want to do in mplay, because of it's floating point data. Is that clear?

BTW, I already have my display calibrated to sRGB standard.