Monitor exhausted?

[Hening Bettermann]

Hi!

When I display Bruce Lindblooms synthetic ColorChecker on my Eizo CG243W through my fresh calibration profile, the Mac Digital Color Meter shows an overweight of the red channel. The middle grey field reads RGB 51-49-47, the white field 231-227-217. The target is black 0.2, gamma 1, 5500 K, 100 cd, calibrated with a Spyder3 and the ColorNavigator software.

I was alerted to check this because I needed large amounts of negative tint (-15) to make the blue sky fit to my memory in Iridient.

The monitor shows a usage time of about 3600 hours. Do I need a new monitor?

Thank you for your comment.

[digitaldog]

The Mac Digital Color Meter is useless for providing any info about the display calibration and profile. The values it provides are often a joke!





Remember this?
http://forum.luminous-landscape.com/index.php?topic=55782.msg454025#msg454025

[Hening Bettermann]

Hi Andrew,

thank you for your reply, and for keeping track of my own threads :-)

In that thread, I learned from Scott Martin that the Mac Digital Color Meter shows the values AFTER conversion - but that is what I exspect now. Can my Eizo produce enough blue?

I discover first now, that the Eizo Color Navigator software has an Advanced tab, that allows manual adjustment of the White point, the R, G and B values stated as percentages. I see that in the existing profile, R is 100%, G 94.29% and B 76.38%. So maybe it is not the monitor whose blue channel is exhausted - it could be adjusted upward.

However, I would need some sort of measuring device for the result on screen, wouldn't I?
If the DCM is not reliable for the purpose - is there a tool that is? I remember that you don't trust the internal validation of the profiling software either - "it's a feel-good-button".

BTW that thread you link to was in preparation of my first (and hitherto only) 'printing raid', which was a full success - my prints (from the print service) do not look too dark :-)

[Tim Lookingbill]

I was alerted to check this because I needed large amounts of negative tint (-15) to make the blue sky fit to my memory in Iridient.

A blue sky at any given day using any type of polarizing filter will reproduce just fine within any Raw converter and convert just fine to even sRGB. You're memory should not be the defining factor in questioning your display profile. I'ld also say your editing skills are in question as well.

Apple's Digital ColorMeter is only useful for CIELab readouts which match up just fine to Photoshop's Info Palette set to Lab in color managed previews.

The ADCM is also useful in isolating colors to check adaptation induced perception hue errors against a neutral reference when editing images like pastels that appear too pinkish or violet when they're not as in skin tone highlights and sunset lit white rocks. The Lab readouts can also be used to check to make sure Pantone colors are correct according to published data when viewing in color managed vs nonCM web browsers.

[Tim Lookingbill]

And I just remembered a color issue with Iridient Developer from the distant past in that its color engine compared to Adobe's is a bit on the "mature" side in reproducing deep saturated colors that don't really appear in nature. This is why landscape photographers like using Iridient Developer.

[Hening Bettermann]

Hi Tim

> Your memory should not be the defining factor in questioning your display profile.

Indeed not. That's why I tried to check with the synthetic ColorChecker and the ADCM, and found myself confirmed. Until Andrew said that the ADCM was unreliable. Now what I can extract from your postings is that you find it reliable if the readout is set to Lab.

Here is the white patch of the synthetic CC in different readouts:
The PhotoLine values should be the values before conversion to screen profile, in that they stay the same if I move the target to another monitor.

PhotoLine RGB:      238-238-234    Δ R/B = 1.6%
ADCM RGB:      227-225-217    Δ R/B = 3.9%
PhotoLine Lab:           L 95, a 0, b 2
ADCM Lab:       L 89.542, a -0.344, b 4.192

I'm not familiar with using Lab, but as far as I can see, the screen image is in fact less blue than the target by about 2 units (PL does not display decimals here, and ADCM not percentages).

So it looks to me that if I can not find a tool like the ADCM with reliable readout in RGB values, I would need to adjust the white point of the monitor profile in RGB %, then check in Lab. Somewhat fiddly, but should be possible.
 

[Hening Bettermann]

Hm, I have now adjusted the White Point of the profile manually, but the Lab readout of the Color Meter is *exactly* the same. What am I missing??

[Tim Lookingbill]

Hm, I have now adjusted the White Point of the profile manually, but the Lab readout of the Color Meter is *exactly* the same. What am I missing??

You don't say by how much you changed it. I've found Photoshop's Info Palette Lab readouts barely change applying slight edits to color managed previews in Photoshop. Also it was stated in the past by Eric Chan that you can be off by as much as 5 points in any L, a, b, channel and not see a difference in a CC chart after applying a freshly made DNG camera profile to the image.

And I thought your original issue was with a particular sky blue, not off white neutrals that are suppose to emulate 5500K white light.

With that statement from Eric Chan on Lab tolerances I don't see how being split hair accurate with the color of white light is going to stop you from getting screen to print matches. If you feel you can't trust your display and its profile due to this level of accuracy, you need to be talking to the folks who built your display.

[Hening Bettermann]

Hi Tim,

thanks for your reply.

I tried different adjustments, also quite gross ones, with no change. And then, I tried a profile target with gamma 2.2 rather than the 1.0 I started with - and now the ADCM Lab readouts, if rounded to the nearest integer, are exactly the same as those of PhotoLine!

And now I am confused on a new question: Why does the gamma make it? It must be that the synthetic CC is calculated that way? Which I find surprising.

Indeed my original problem was the color of sky blue. And I thought there might be something wrong with the monitor profile, and tried to check that. Now it seems the monitor profile's fault was the gamma I chose for it.

So it seems the problem is solved. Thanks for your help!

[Tim Lookingbill]

Hi Tim,

thanks for your reply.

I tried different adjustments, also quite gross ones, with no change. And then, I tried a profile target with gamma 2.2 rather than the 1.0 I started with - and now the ADCM Lab readouts, if rounded to the nearest integer, are exactly the same as those of PhotoLine!

And now I am confused on a new question: Why does the gamma make it? It must be that the synthetic CC is calculated that way? Which I find surprising.

Indeed my original problem was the color of sky blue. And I thought there might be something wrong with the monitor profile, and tried to check that. Now it seems the monitor profile's fault was the gamma I chose for it.

So it seems the problem is solved. Thanks for your help!

That part about the gamma change is interesting. I'm having to assume the reason you chose a gamma 1 tagged/embedded in the actual ICC profile was to build a null (flat diagonal) VCGT tag that reflects the gamma chosen in the hardware of your Eizo. You are using hardware LUTs inside the Eizo electronics to do what usually is required in the OS video card with displays that don't have hardware LUTs. Right?

Maybe there's a TRC tag in the ICC profile that shouldn't be there due to some miscommunication between hardware and software. Or another thought crossed my mind is that black point may not be well enough defined between profile and hardware in order for a gamma 1 to find bottom between hardware and the ICC profile.

It's getting too complicated to sort out but at least you solved your problem. I'm just not sure if it's an approach thorough enough to sort out possible bugs that might bite you down the road.

[D Fosse]

I've no idea why Hening would choose linear gamma for a display profile, but it's certainly so far off the unit's native response that I'm not surprised there was odd behavior.

Whether in the monitor LUT or the video card, it's still an extreme adjustment. "Bypassing" the video card is not the issue here, this isn't how it's done. ColorNavigator doesn't write anything in the gamma table tag anyway, it's empty and doesn't do anything.

But ColorNavigator does write an icc profile that reflects this unusual behavior. It has to, because color managed apps now have to convert from a 2.2/1.8 source color space into a 1.0 display color space.

When choosing display profile gamma, best practice is always to stay as close to native behavior as possible. Not because you'll see any difference, you won't (it's converted), but because the monitor behaves better with as little adjustment as possible.

[Hening Bettermann]

Hi

thanks for your replies.

>I've no idea why Hening would choose linear gamma for a display profile, but it's certainly so far off the unit's native response that I'm not surprised there was odd behavior.

>I'm having to assume the reason you chose a gamma 1 tagged/embedded in the actual ICC profile was to build a null (flat diagonal) VCGT tag that reflects the gamma chosen in the hardware of your Eizo. You are using hardware LUTs inside the Eizo electronics to do what usually is required in the OS video card with displays that don't have hardware LUTs. Right?

My considerations were not as qualified as that. I just tried to keep 'everything' as straightforward and transparent to my simple mind as possible. I thought staying linear all the way would be just that. I remember from this site, I think it was from a post by Bill Janes, that linear images do not look dull on a wide gamut monitor; iow that the gamma is just a historic tool to compensate for the limited tonal range of early/low end monitors. (I enjoy an Eizo CG243W). 
Often, I also choose linear output from the raw converter. In this case however, the image had Iridients default tone curve applied. (no gamma though).

[D Fosse]

Keep it native, that's the most straightforward and transparent you get. That's 2.2.

Gamma, or more correctly tone response curve, is remapped from source color space to display color space anyway. That's why you don't see any difference whatever gamma you calibrate to. Then, the unit itself follows an inverse gamma function, the net result being linear.

The 2.2 figure has been described as an "incredible piece of engineering luck". On one hand gamma encoding optimizes bit information, because human visual perception is non-linear. And the optimal TRC is an approximate 2.2 gamma function.

On the other, CRT monitors natively followed an inverse 2.2 function. So the two worked perfectly together, without any complex engineering required. LCDs are still made with a native 2.2 response.

[digitaldog]

I remember from this site, I think it was from a post by Bill Janes, that linear images do not look dull on a wide gamut monitor; iow that the gamma is just a historic tool to compensate for the limited tonal range of early/low end monitors. (I enjoy an Eizo CG243W). 

Got nothing to do with the TRC (linear or otherwise), certainly with ICC aware applications and tagged data. As D Fosse says, keep it native, there's zero reason to be mucking around with anything else.

[Hening Bettermann]

> Keep it native, that's the most straightforward and transparent you get. That's 2.2.

OK I will :-)

[D Fosse]

It should be noted that the "luck" of 2.2 gamma encoding refers to early days of TV and computer engineering.

It has been argued that today, between high-bit processing and modern color management, one could do away with gamma encoding altogether. I'm not sure that's the case, because there are still 8-bit bottlenecks in the signal chain, like video card output (10-bit video never seemed to make it into the mainstream).

With a linear end-to-end signal path, you'd very likely see a lot more shadow banding on screen. There would be too few bits in the shadows, and too many up in the highlights. That's what gamma encoding does - make all the 256 steps visually equidistant.

It should also be noted that modern displays do not follow an idealized gamma curve. 2.2 is just an averaged approximation. But color management and icc profiles compensate for that, just as it compensates for any other gamma setting. The point about "native" gamma is simply that you don't want to modify the monitor's response any more than you have to.

For a good hardware calibrated unit like the Eizo it's not a major concern (unless you wander too far off). But as Andrew says, there's zero reason for any esoteric settings here anyway. KISS applies here.

[Simon Garrett]

It should be noted that the "luck" of 2.2 gamma encoding refers to early days of TV and computer engineering.

It has been argued that today, between high-bit processing and modern color management, one could do away with gamma encoding altogether. I'm not sure that's the case, because there are still 8-bit bottlenecks in the signal chain, like video card output (10-bit video never seemed to make it into the mainstream).

With a linear end-to-end signal path, you'd very likely see a lot more shadow banding on screen. There would be too few bits in the shadows, and too many up in the highlights. That's what gamma encoding does - make all the 256 steps visually equidistant.

It should also be noted that modern displays do not follow an idealized gamma curve. 2.2 is just an averaged approximation. But color management and icc profiles compensate for that, just as it compensates for any other gamma setting. The point about "native" gamma is simply that you don't want to modify the monitor's response any more than you have to.

For a good hardware calibrated unit like the Eizo it's not a major concern (unless you wander too far off). But as Andrew says, there's zero reason for any esoteric settings here anyway. KISS applies here.

I agree with all that.  With higher bit depth (say 12-bit or more) then for image internal processing and storage, the TRC - linear, gamma of some sort, sRGB's TRC - is pretty much transparent to the user, as colour management makes it work in the background.  But with 8-bit data, a curve equivalent to a power law or exponential is useful to reduce the perceived quantisation noise at low levels.  8-bit jpegs would have a lousy dynamic range without gamma encoding. 

Another place where gamma encoding is useful is for histograms.  Because of our non-linear perception, linear presentation on the x-axis of a histogram would mean most of the image data would be scrunched up in the left of the histogram. 

[Hening Bettermann]

Thanks for your contributions. I keep learning...