Re: Monitor profile verification [was: Eye One Pro for monitor calibration? [was: Re: NEC 2690 SpectraView]]
Re: Monitor profile verification [was: Eye One Pro for monitor calibration? [was: Re: NEC 2690 SpectraView]]
- Subject: Re: Monitor profile verification [was: Eye One Pro for monitor calibration? [was: Re: NEC 2690 SpectraView]]
- From: Marco Ugolini <email@hidden>
- Date: Sun, 02 Dec 2007 23:05:32 -0800
- Thread-topic: Monitor profile verification [was: Eye One Pro for monitor calibration? [was: Re: NEC 2690 SpectraView]]
In a message dated 12/2/07 5:49 AM, Terry Wyse wrote:
> Thinking...thinking...oh yea, I'm not sure this is exactly right.
>
> Please correct me if I'm wrong, but I assumed it was L*a*b* numbers
> that were sent through the monitor profile, converted to RGB, sent to
> the display and then measured with the colorimeter/spectro with the
> resulting L*a*b* values compared back to the original L*a*b*.
Hi Terry.
What is sent to the monitor are *always RGB numbers*. What differs is how
those RGB numbers are determined. This varies from one software to the next,
but the choice seems to be between these two methods:
1) "L*a*b*-first"
Monaco Optix appears to do what you describe -- it starts from a list of
L*a*b* values, *converts* them to the active monitor profile to obtain the
RGB numbers which it then sends to the display, measures the colorimetric
values off the screen, then it calculates how much the measurements differ
from the original L*a*b* values.
2) "RGB-first"
On the other hand, basICColor display, for example (and EyeOne Match, I
believe) sends RGB numbers *directly* to the screen, calculates their
expected colorimetric values by *assigning* the active monitor profile, then
compares those expected values to the measured ones.
Either way, what is sent to display are *always* RGB numbers -- whether it
be a *fixed* list or one obtained by converting the expected L*a*b* values
to the active monitor profile. So, in "RGB-first" the RGB list never changes
but the expected reference L*a*b* values vary from one profile to another;
in "L*a*b*-first", the L*a*b* reference list never changes but the RGB
values sent to the display vary from one profile to another.
One way or the other one always ends up with a colorimetric *reference* set
and a colorimetric *measured* set. In either case, the validation procedure
calculates the color difference between the two.
> I'm pretty sure this is the case with Monaco PROFILER's and OPTIX
> monitor+profile evaluation routine because I'm looking at the
> reference file they use for monitor evaluation (Macbeth ColorChecker)
> and it's a list of L*a*b* values.
True, but the essence of the procedure doesn't change. One way or the other,
a set of *RGB* numbers (not L*a*b*) is sent to the display, then the
appearance of each patch is measured.
> Of course, I assume other monitor verification tools could do just the
> opposite.
Yes, different packages use one or the other. It seems to me that most of
them use the "RGB-first" route, though.
Marco
_______________________________________________
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