Re: Profile verification in PatchTool
Re: Profile verification in PatchTool
- Subject: Re: Profile verification in PatchTool
- From: "dpascale" <email@hidden>
- Date: Mon, 5 May 2008 12:00:17 -0400
Hello Marco,
Monitor profile validation procedures that use RGB lists send the RGB
numbers to the display directly, *as is*, without conversion and without
assigning any profile to them.
You always have to assume something if you want to "compare" your measured
data for validation. This is what you also say next:
In this scenario, assigning the monitor profile to the RGB reference data
is
only required
This is the required assumption for your example.
>in order to produce a list of *reference Lab data* (the Lab
values that the profile expects from those RGB numbers) -- which are later
compared to a list of Lab values measured off the monitor with the
colorimeter. The difference between reference (expected) values and
measured
(actual) values provides the final DeltaE values.
Simply stated, the purpose is to check how close the results of the
monitor
profile's A2B tables are to the actual measured values (if the monitor
profile is LUT-based).
Here you describe a Device space to PCS transform (A2B). What do you do with
the PCS data for display in order to measure it?
You need to assign a destination profile.
If you assign the same profile as your assumption (the monitor profile), you
are simply sending the RGB directly to the display, without color
management, in device space. So this is what you want!
In this procedure there is no conversion of the RGB reference data to the
monitor profile. The active monitor profile is automatically "assigned",
in
a manner of speaking, to the RGB numbers at the OS level,
Only if the source and destination profiles are the same.
but the RGB data are *not* converted to the active monitor profile from
another profile (say,
sRGB).
The only time "untagged" RGB (no assigned RGB space) is used in PatchTool is
in the QuickTest procedure (this is not a file opened by the user), where
you then assign a source profile to the RGB, and a destination profile for
measurements, so it is not untagged for long. As mentioned, if the source
and destination are the same, it does not matter if tagged or untagged when
it is sent to the screen.
In ALL cases where you opened an RGB color list (assuming you opened a file
with only RGB data, if not, the program will use any device independant data
in the file , i.e. XYZ, Lab, etc), the RGB is tagged by one of five standard
RGB spaces you select while opening the file. However, there is a way to
define your own RGB list and send it "untagged" for measurements:
1- Define an RGB list.
2- Open it and assign a space, lets say GenericRGB.
3- This will be converted in XYZ D65 internally, and converted to XYZ D50
for the PCS when doing the measurements.
4- Select the built-in GenericRGB as the destination profile.
5- Do a display check using the opened file
What happens here is since you use the same source (when opening) and
destination, you are in effect sending "untagged" RGB to the display.
This can be confirmed by opening the RAW measurements file which contains
the actual RGB values sent to the monitor after being processed by the
destination profile.
In the above example you are not checking the monitor profile since we are
using GenericRGB. If you select your monitor profile instead of the
GenericRGB space of step-4, you are then checking the B2A table of your
profile, or how colors in your images will look like when displayed on your
calibrated monitor.
For these reasons, I fail to understand the purpose of *converting* the
RGB
reference data from an assigned working space (like sRGB, for example) to
the monitor profile when performing a profile validation routine. In this
light, it seems redundant, an unnecessary extra step that is not taken by
RGB-list-based monitor profile validation routines.
PatchTool always needs a space for RGB; it WILL NOT consider RGB untagged.
However, this is not a problem when using the same source and destination
space as shown above.
Regards,
Danny
email@hidden
www.babelcolor.com
_______________________________________________
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