Funny thing is: although the screen looks funky a screenshot via the OS results in a normal looking picture....
Not surprised. You can probably do the same with no display hooked up
Do you know if there is an age limit with screens?
I do not as it's based on hours used and the backlight technology among other factors. That's a rather old unit. It should show you the number of hours used within SpectraView.
Anyway I'm looking at my options for a new monitor: might go with the Eizo CG277 or the NEC SpectraView Reference 272. During researching these I notice that Eizo recommends Gamma 2.2 whereas NEC L* in their respective software. Could you enlighten my ignorance?
I love my PA272W and yes, it's going to last a longer time backlit with LEDs (newer GBr LED). Before you dump your unit, I'd give NEC a call, they are usually very good about tech support and might have some other tricks (like smacking it with the back of your hand).
As for Lstar or Gamma, not even worth the debate, in the end, doesn't matter. And I think you
may it backwards (my NEC doesn't do Lstar with SpectraView written in the US) In Europe, for a time, Lstar was a 'big deal' of which no one I'm aware of could explain. There was a debate on the ICC users list years ago, one of the best replies is pasted below from a fellow who knows a lot about the subject!
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