Re: Profile verification in PatchTool
Re: Profile verification in PatchTool
- Subject: Re: Profile verification in PatchTool
- From: Roger Breton <email@hidden>
- Date: Mon, 05 May 2008 08:11:30 -0400
Hi Marco, Danny,
I'm going to play the devil's advocate.
Suppose I open an CMYK / Lab list, like GRACoL2006_C1. What I understand
PatchTool does then is to ignore the CMYK side of the equation and strictly
use the Lab values as starting point in the process. The gist of the
procedure which follows is the following: how accurately can these Lab
values be displayed on the host monitor using its profile?
I suspect that this part of PatchTool workflow is designed strictly for
testing the B2Ax (PCS to Device) direction of a monitor profile. That's why
we're asked which RI to use when opening any CMYK or RGB list that does not
have associated Lab values.
Let's see if this makes sense.
Suppose I open an RGB list that does not have associated Lab values, like
you described. Then, on the one hand, I understand your point completely,
the user could want to test the A2Bx (Device to PCS) direction of the
monitor profile.
And, as you indicated, that does not seem to be what PatchTool seems to be
doing when prompting for RGB profile.
In my view, why PatchTool requires an ICC profile at that stage is because,
in the next stage, it will want to associated the list of RGB device values
you opened to their equivalent Lab values, because, at that point, for the
purpose of testing, the RGB values will be thrown away : only Lab will be
used as the Source for the monitor profile conversion that will take place.
It makes sense to me. I'll get later to what I think you have in mind but,
for the moment, please bear with me.
It's interesting to note in passing that many (if not most?) monitor
profiling packages seem to test only the Device to PCS direction.
Take Eizo ColorNavigator, for example. After going through calibrating and
profiling, it goes through a pre-defined list of RGB values, send them on to
the video RAM, untouched, and gathers their resultant "color values" in XYZ,
xyY or Lab form, and report on the variance to the user.
It seems to me that this is the prevaling "paradigm" in verifying monitor
profiles -- they all do this.
We get measured Lab that we now have to compare to, to, to, what, the source
RGB values? No... You know it does not arbeit this way! So, of course, the
RGB values sent to the monitor have to converted somewhere into some Lab
values otherwise we'll never be able to calculate deltaEs.
So what does ColorNavigator do (and the others packages)?
They take those test RGB values and process them through the A2B table of
the monitor profile, to obtain Lab values.
What I think PatchTool does is to jump the gun in asking the user, at the
onset, to choose one of the pre-defined RGB profile to interpret the
colorimetry of the opened RGB list. So that, the RGB values can readily be
converted to XYZ (I think that's what Danny indicated), behind the scene,
and later to Lab, to compute DeltaEs.
What I think you're asking is why not have the choice of the monitor profile
itself as the Source, why keep it among the list of predefined RGB profiles
(sRGB, AdobeRGB, Colormatch, ProPhoto, ...)?
A question only Danny can answer.
I guess there is nothing, in principle, that could prevent PatchTool for
offering the active monitor profile in the list of Source at the time of
opening an "orphan" list of RGB device values (with no associated Lab
values), if the user explicitely would prefer to use that for interpreting
the colorimetry of the RGB list.
But I think the case can be made that, for the purpose of testing the
performance of monitor profiles, because this is what we want to get to,
after all, it does not matter as much as we would think it does, what the
source of the Lab figures is : monitor or independent RGB working space. All
that matters, I think, is that a list of values is sent to the monitor
profile, for display, the profile does its thing to convert from RGB to RGB,
the instrument collects the result, and PatchTool reports on the variance
between expected and actual. Either we're happy with the results or we're
not. In one case, we pat ourselves for having made all the right decisions
(monitor, instrument, software). In the other case, well, it's time to hit
the coffee machine and start all over...
Have a nice day!
Roger Breton
_______________________________________________
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