Eizo ColorNavigator gamma non-effective

[Clark]

Hi guys, I am running an Eizo CG277 from a MacPro 2013 cylinder, on the latest version of El Capitan.

I am experiencing a problem with the Colornavigator software, whereby it seems unable to make a change to the gamma being displayed.

I am creating display profiles using the Eizo's in-built colorimeter and it's Colornavigator app driver. I want to be able to control the gamma and try slightly different settings to see if it matches more closely the density of my prints, but I started to wonder if the profiles I'm creating were actually any different.

So I tried making profiles with highly differing gamma settings (1.8 - 2.6) and discovered that the display gamma is not being visibly changed.

However, if I exit the Colornavigator app and go into Mac OS's System Preferences, I can select these profiles (the same ones mentioned above, made with Colornavigator) and System Preferences is able to implement gamma settings. The gamma change is clearly visible when switching from one profile to the next, as I would expect it to be.

Can anyone shed some luminosity on what is happening here? Is this a known issue?

(edited to be clearer in my description)

[Czornyj]

That’s just color managemet. It displays images using TRC of color space that they were rendered to, no matter what is the TRC of the display.

[Clark]

Hi Czornyj, sorry but your reply makes no sense to me.   

[Czornyj]

Hi Czornyj, sorry but your reply makes no sense to me.   

To put it simply - the color management module in applications such as PS, LR etc. checks the gamma value of the editing color space like sRGB, Adobe RGB, ProPhoto. Then it checks the gamma value of the display, that is written into monitor profile. If the gamma value is different, the color management module changes the RGB values of displayed colors to match the gamma of the editing space. So if - for example - the image is rendered to Adobe RGB that has the TRC gamma 2,2 it will be displayed as if the display was calibrated to gamma 2,2 - no matter if it's calibrated to gamma 2,6 or 1,8. You will only see the difference if you turn color management off (like choosing View>Proof Setup>Monitor RGB in PS)

[digitaldog]

Hi Czornyj, sorry but your reply makes no sense to me.   

In ICC aware applications it doesn't really matter the TRC of the display, especially for those working in high a bit video path.

[Doug Gray]

Hi guys, I am running an Eizo CG277 from a MacPro 2013 cylinder, on the latest version of El Capitan.

I am experiencing a problem with the Colornavigator software, whereby it seems unable to make a change to the gamma being displayed.

I am creating display profiles using the Eizo's in-built colorimeter and it's Colornavigator app driver. I want to be able to control the gamma and try slightly different settings to see if it matches more closely the density of my prints, but I started to wonder if the profiles I'm creating were actually any different.

So I tried making profiles with highly differing gamma settings (1.8 - 2.6) and discovered that the display gamma is not being visibly changed.

However, if I exit the Colornavigator app and go into Mac OS's System Preferences, I can select these profiles (the same ones mentioned above, made with Colornavigator) and System Preferences is able to implement gamma settings. The gamma change is clearly visible when switching from one profile to the next, as I would expect it to be.

Can anyone shed some luminosity on what is happening here? Is this a known issue?

(edited to be clearer in my description)

Clark,

What you are seeing is totally correct behavior but confusing when first encountered because the setting is combined with two other settings that do affect the display. The settings for color temperature and luminance (in cd/sq^m) make very visible differences in all applications whether color managed or not. But gamma doesn't and should never alter appearance in color managed applications. One of the unfortunate side affects of combining it with luminance and color temperature settings is that it is normal, even intuitive, to think it should make some sort of visible difference like the others clearly do. But all it changes is how unmanaged applications are displayed.

Gamma is settable largely as an artifact from decades ago when monitors were driven by analog voltage levels which varied with manufacturers. Setting the gamma was a way to nail down the system response, including the monitor, so that unmanaged images (and they were all unmanaged long ago) would display the same on different monitors.

[Clark]

Hey Doug, thanks a lot for the information. I learn a lot of new things every time I post here

I am still a bit puzzled though.

It seems to me that gamma is still used by applications (such as my display's profiling software) as a valid and universally understood means to describe "tonal response".

This gamma setting definitely is] written into the profile and is effective when selecting the respective profile from Mac OS X System Preferences. The gamma in all apps responds accordingly. What is happening here?

[Simon Garrett]

Gamma encoding - applying a non-linear tone correction - is technical kludge, as others have said. 

The overall tone curve of the system - from camera sensor to screen or print is (or should be) linear.  If it were not so, then the screen or print image would not look the same as the original scene.  It's nothing to do with our eyes having a non-linear response similar to 2.2 gamma.  That's true, but the same non-linear eyes see the original scene and the screen or print.

Non linear encoding is used for two reasons:
- to counter non-linearity in old CRT screens (that is, to cancel out that non-linearity)
- to provide more perceptually-uniform encoding in low bit-rate encoding (e.g. 8-bit jpegs).  This is because our eyes are non-linear, and can distinguish more levels at the black end.  Linear encoding at 8-bits results in banding at the black end, whereas a gamma curve effectively allocates more levels at the black end.  However, that non-linear encoding is removed before display.

Of course, we may apply a non-linear tone curve for creative reasons (e.g. to increase contrast), but that's not what we're talking about here. 

Because a colour-management system is trying all the time to ensure linear end-to-end reponse, if you alter the gamma of a monitor, and provide a corresponding profile, the colour management system will use the profile to cancel out the gamma of the monitor, so you won't see any difference, whatever the gamma.

I don't know much about Macs, but what I think may be happening is that if you alter the profile in system preferences without changing the monitor behaviour, then the profile no longer matches the monitor, so the visible tone performance changes.  If you alter the calibration in ColorNavigator, the software makes sure that the profile matches the monitor.  Change the monitor tone curve and it changes to profile to match, so you don't see a visible change.

Hope that makes sense.

[Doug Gray]

Hey Doug, thanks a lot for the information. I learn a lot of new things every time I post here

I am still a bit puzzled though.

It seems to me that gamma is still used by applications (such as my display's profiling software) as a valid and universally understood means to describe "tonal response".

It's commonly used in other industries to make small adjustments based on viewing parameters. For instance adjusting a movie gamma when switching from to viewing in a dark room.  This is a completely separate function than in photography and printing using ICC profiles where gamma is no more than a way to match monitors and profiles which have the inverse response to each other. Since the Eizo allows you to set the monitor's gamma the installed profile just contains the gamma which is used to invert that of the monitor providing the same color no matter the gamma.

This gamma setting definitely is] written into the profile and is effective when selecting the respective profile from Mac OS X System Preferences. The gamma in all apps responds accordingly. What is happening here?

You have a high end monitor using CN with a built in colorimeter. It's essentially the same as mine (CG318). These work a bit differently than some other monitors where the RGB values are written into the video driver's LUTs. This approach avoids subtle banding where 8 bit RGB values have to jump sometimes to retain the proper response. But overall there is no appearance difference of much significance.

The gamma is written into the profile because it is needed to present the correct RGB values to the monitor. When you set the gamma it's tone curve is written into the monitor's profile and, for these monitors, just maps the RGB values 1 to 1 in the video card to the monitor. The gamma response of the monitor is set to the value you enter when making a new profile in CN. That same gamma is written to the profile so it can produce the desired color. These cancel each other so changing the gamma will have no affect except on non-color managed applications. Images in Lightroom or Photoshop are color managed, the menus and their surround are not.

The main reason a gamma is used at all in modern times is that it reduces visual stepping in shadows with low gamma to account for human vision. You can run an experiment by making a gamma=1 profile then create a gradient from black to dark gray. You will see banding from the black, even with a 10 bit data path. Then switch to a standard higher gamma and the banding will virtually vanish. But when viewing an image the overall look of the image and its tone curve will be unchanged.

[GWGill]

The overall tone curve of the system - from camera sensor to screen or print is (or should be) linear.

This is a common misconception, but it's simply not true. Life would be far simpler if it was, but it doesn't take account of the reality that the viewing conditions around the screen are not the same as the original scene, nor is the display capable of reproducing the same range of stimuli. Even if the latter could be overcome with better technology, the former always exists.

So the reality is that the original scene as "seen" by the camera needs to be modified to account for the viewers different state of adaptation when looking at the screen, as well as taking into account the screens technical limitations. This is the process of rendering scene referred color to output referred color.

[digitaldog]

This is a common misconception, but it's simply not true.

Agreed. Here's a post I've archived from someone in the know about this:

Subject:
Re: [Icc_users] L* workingspaces and L* output calibration
Date Received:
Tuesday, March 11, 2008 8:46:58 PM
Date Sent:
Tuesday, March 11, 2008 8:38:07 PM
From:
Lars Borg <borg@adobe.com>
L* is great if you're making copies. However, in most other
scenarios, L* out is vastly different from L* in.  And when L* out is
different from L* in, an L* encoding is very inappropriate as
illustrated below.


Let me provide an example for video. Let's say you have a Macbeth
chart. On set, the six gray patches would measure around  L* 96, 81,
66, 51, 36, 21.


Assuming the camera is Rec.709 compliant, using a 16-235 digital
encoding, and the camera is set for the exposure of the Macbeth
chart, the video RGB values would be 224,183,145,109,76,46.


On a reference HD TV monitor they should reproduce at L* 95.5, 78.7,
62.2, 45.8, 29.6, 13.6.
If say 2% flare is present on the monitor (for example at home), the
projected values would be different again, here: 96.3, 79.9, 63.8,
48.4, 34.1, 22.5.


As you can see, L* out is clearly not the same as L* in.
Except for copiers, a system gamma greater than 1 is a required
feature for image reproduction systems aiming to please human eyes.
For example, film still photography has a much higher system gamma
than video.


Now, if you want an L* encoding for the video, which set of values
would you use:
96, 81, 66, 51, 36, 21 or
95.5, 78.7, 62.2, 45.8, 29.6, 13.6?
Either is wrong, when used in the wrong context.
If I need to restore the scene colorimetry for visual effects work, I
need 96, 81, 66, 51, 36, 21.
If I need to re-encode the HD TV monitor image for another device,
say a DVD, I need 95.5, 78.7, 62.2, 45.8, 29.6, 13.6.


In this context, using an L* encoding would be utterly confusing due
to the lack of common values for the same patches.  (Like using US
Dollars in Canada.)
Video solves this by not encoding in L*. (Admittedly, video encoding
is still somewhat confusing. Ask Charles Poynton.)


When cameras, video encoders, DVDs, computer displays, TV monitors,
DLPs, printers, etc., are not used for making exact copies, but
rather for the more common purpose of pleasing rendering, the L*
encoding is inappropriate as it will be a main source of confusion.


Are you planning to encode CMYK in L*, too?


Lars