Re: Eizo CG 21 and Eye-One
Re: Eizo CG 21 and Eye-One
- Subject: Re: Eizo CG 21 and Eye-One
- From: Chris Murphy <email@hidden>
- Date: Sat, 23 Apr 2005 15:54:49 -0600
On Apr 23, 2005, at 1:22 PM, Roger Breton wrote:
It's a question of method rather than whether it is or is not done
internally.
Well it is not done internally, as far as I can see, and that makes a
difference to me.
What makes you think it's not internal? It certainly isn't being done
in the video card, yet the display is rather nicely gray balanced.
It is done internally but the methods differ.
Please discuss your testing methodology. Here it, on this Eizo, it's
not
happening as you describe it.
Using version 3.01 of the Color Navigator software (the v2 software was
next to useless), the profile that's produced is pure matrix + TRC. The
vcgt tag is clear. The display is gray balanced, so it must be done
internal to the display. I have one machine where I get horribly
magenta cast displays if they aren't forced to gray and both the
Artisan and the Eizo + Color Navigator (or ColorEyes or basICColor
Display) produce profiles with a linear vcgt tag, and identical TRCs.
Plus, there's at least one white paper on the Eizo products explaining
some of this. So insofar as I can tell, it's done internal to the
display. It just isn't iterative.
Theoretically
if you set white and black point for each channel correctly, the same
gamma for each channel should produce gray (assuming the primaries are
properly paired up to do that).
That theory is more applicable to CRT -- and even then. LCD's notorious
non-linearity prevents this happy state of events from happening, in my
real-world experience.
a.) It's not any more or less applicable to CRT's, because it's a
function of additive color. LCD's emit light just like CRT's do. This
isn't a question of spectra.
b.) In this context I'm rather unconcerned with any natural
non-linearity of this particular flat panel because it's being forced
internally to a consistent tone response by the software packages
mentioned. That's the whole point of using one of these three packages
and why I wouldn't use any of the other packages that can't communicate
with these displays directly.
The basICColor and ColorEyes gray
balance method is iterative, and allows for separate tone correction
for each channel.
The basICcolor Display method is the ONLY true, hardware gray balance
method
I ever came across in all the pieces of software I used for the
purposes of
calibrating displays. It seeks to set RGB values from light to dark
that not
only yield the desired gamma but also the desired chromaticities. That
has
never happen automatically in all the monitors I ever calibrated by
merely
setting the gamma. But I doubt your experience to be very different to
mine.
With the exception of Color Navigator, I agree. I see no evidence, yet
plenty to the contrary, that indicates Color Navigator is either a.)
unsuccessfully gray balancing the display, or b.) gray balancing it
outside of the display itself (i.e. in the video card).
I won't see it in a
non-color managed gradient, but will see it in a color managed one,
when using table-based profiles, but not in matrix-based ones.
That's another issue. Is that a function of "imperfect" measurements?
Or
device's actual behavior differing from predicted behaviors? Or, more
likely, is that a function of incomplete mathematical color modeling?
Some
unforeseen intervening variable? Or all of the above? I wish I knew.
A profile is most accurate where there are measurements, and least
accurate somewhere in between those measurements were the CMM is
responsible for guessing. It's a case where more accurate in some areas
leads to less smoothness elsewhere. You don't get anything for free. A
matrix based profile is fairly immune to both inaccuracy and lack of
smoothness when the display is well behaved, and the profile describes
actual behavior of the display (quality of the measurement data, even
if there isn't much of it).
I can see how the secondary colors would be more accurate with a
table-based profile, so if that's more important to you than smooth
neutrals, then that's the way to go. Otherwise, stick with
matrix-based
display profiles.
I use LUT-based profile on this Eizo and I don't see how I could be
happier
with matrix/shaper profiles. And, yes, perhaps against all odds, I get
what
appears to me as smooth neutrals.
I'm not suggesting there is a right and wrong. I'm pointing out the
differences between the two, and why you might use one versus the
other, rather than the mantra "table-based display profiles are
better". The Artisan proved table based profiles aren't necessary to
get accuracy and smoothness.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
-------------------------------------------------------------
Co-author "Real World Color Management, 2nd Edition"
Published by PeachPit Press (ISBN 0-321-26722-2)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden