[argyllcms] Re: Question regarding White Point and spotread
- From: "Brad Funkhouser" <brad.funkhouser@xxxxxxxxxxx>
- To: <argyllcms@xxxxxxxxxxxxx>
- Date: Mon, 03 Nov 2014 17:19:03 -0600
Robert,
This is some rambling, but you might find it helpful because I think we've
gone through a lot of the same thought processes and struggles when it comes
to the difference between absolute and relative colorimetric.
I think for us laymen without color science backgrounds, the usual
descriptions of absolute and relative colorimetric intents, though accurate,
actually create tremendous confusion. From camera space to working space,
it wasn't until Graeme eloquently described the difference to me that I
think I got it. The PM5, InCamera & SilverFast input profiles I'd been
using didn't make the same distinction between absolute and relative that
Argyll makes, so it was very confusing to me for a long time. From working
space to printer space, ColorThink Pro's 3d graphing ability that shows the
color conversions as vectors helped me tremendously.
Understanding the difference was also made much harder by the fact that some
CMMs like Adobe Ace and LCM ignore the defined D65 white points of AdobeRGB
and sRGB working spaces and do a hidden conversion to D50 in some directions
but not others. When trying to understand out how absolute works through
experimentation, not knowing about those hidden conversions was a major
problem. Experimenting with Argyll's cctiff and trying BetaRGB as a working
space (which IS D50) versus AdobeRGB finally helped clear up that confusion.
When going from a working space into a printer space, relative colorimetric
with BPC is probably shifting a lot more colors than you think, even ones
inside the printer's gamut. A lot of light colors are getting pushed down
to make room for the whole area between the working space L100 and paper
white to get shifted into gamut. BPC does the same with dark colors,
pushing a lot of them up to make room for bringing in the whole area between
the working space L0 and the paper/ink black point to get shifted into
gamut. Depending on the paper white and black points, you can end up with
almost all colors getting shifted to some extent. That's different from
what usually gets described.
For me, the most fundamental task for understanding color management starts
with absolute intent: to take a defined color, and, through the use of a
good printer profile, know whether or not I even have a shot at reproducing
that color accurately, and, if so, have the profile send values to the
printer to get a very good match to that color WITHOUT ANY TRIAL AND ERROR.
That is absolute colorimetric intent -- the in-gamut case. It's really not
confusing. However, I think we laymen initially get totally tripped up by
what happens to a working space white going absolute into a printer space,
which is VERY confusing at first. It's outside the printer's gamut, so it
gets converted to the absolutely closest possible spot on the printer's
gamut, which is NOT usually paper white, it's usually a little bit below and
to the side of the paper white. The 3d graphing vectors show this really
well.
Once you see what's really going on with absolute and relative from a
working space to a printer space, you get ideas. For example, creating a
luminosity mask in working space to isolate all pixels very near or above
paper white and shifting just those pixels towards the working space RGB
value for paper white. Then when doing a subsequent absolute conversion to
printer space, everything that's in gamut gets mapped absolutely with no
shifting at all while everything near or above paper white gets converted to
be very close to or exactly paper white. Similar strategies can be used for
out of gamut dark colors. You can have very fine control of all the
shifting and clipping if you want it.
But until we really see whats going on, we give up on even trying to
understand absolute because it seems both confusing and useless, and we
resort to relative colorimetric, but without realizing how much it actually
shifts colors when going from a working space to a printer space. Or we
rely on perceptual mappings, which can be very useful but can also seem to
be all over the place. And so the whole thing can be a bit frustrating.
- Brad
-----Original Message-----
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of robert@xxxxxxxxxxxxxxxxxx
Sent: Monday, November 03, 2014 12:47 PM
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Question regarding White Point and spotread
Hi Brad,
Many thanks for taking the time to try to help me figure this out!!
What you are suggesting makes me stop and think what I'm trying to achieve.
Basically, I would like to be able to specify an RGB color, or range of
colors, in the print space and verify how closely my printer achieves this.
The reason I say an RGB color in the print (or destination) space, is that
this guarantees that the color will be in gamut.
So the first attempt I made was to specify a color (say RGB 120,80,60) in
the destination space (Canson Baryta in this case), check its Lab value,
print it, and using spotread find out what the Lab value of the printed
color is. Of course I don't expect the figures to be exactly the same (a
dE00 uncertainty of around 0.6 would seem reasonable, to account for the
instrument, rounding and interpolation errors etc) - but the error I got was
1.6 if I recall, which seems too big.
This made me think that the probable additional error was due to the fact
that spotread does not compensate for the paper white.
I then looked at using fakeread and colverify (which can compensate for
paper white) and these do appear to give much tighter results.
I'm not sure that I want to use Absolute Colorimetric as I don't use this in
my normal printing (only Relative Colorimetric or Perceptual ... but I
wouldn't attempt this sort of test with Perceptual because I would expect
all the color values to be changed).
BUT ... if you are trying to show that a known in-gamut color/s is printed
accurately (enough), verified by spotread/chartread, then perhaps you should
print it with no color management, scan it, and then compare the values to
the target tiff file with AbsCol assigned as you suggest. Perhaps doing it
this way you are automatically compensating for the paper white? To be
honest I can't get my head around this :).
I really think this whole discussion needs input from someone like Graham.
Unfortunately there's only one Graham out there!
Robert
-----Original Message-----
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of Brad Funkhouser
Sent: 03 November 2014 14:22
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Question regarding White Point and spotread
Robert,
I'm interested in what you're doing, but I'm a little lost in the details.
To help clarify, here's an alternate version of what I think you're wanting
to accomplish.
========================================
You have an existing printer profile (CansonBaryta) built from a large patch
count target.
To physically check that profile now and in the future you create a smaller
(100 patch count) test target.
You print the test target with no color management using exactly the same
printer workflow as used when you built the CansonBaryta profile.
You measure the test target and get a ti3 file with XYZ values for those RGB
device printer values (having chartread also include D50 Lab values in the
ti3 can be helpful for the following spot check).
If you bring the test target TIFF file into Photoshop, assign it the
CansonBaryta profile and set color conversion options to Absolute, then the
Lab values in the info palette for each patch should closely match the
measured D50 Lab values in the ti3. They shouldn't be too far off from the
dE ranges that colprof reported when it originally built the CansonBaryta
profile from the large patch count target. This lets you do spot checks,
but in order to get data across all 100 patches, you need the whole list of
expected XYZ values.
Using Excel, extract just the printer device RGB list from either the ti1,
ti2, or ti3 files. Those device RGB values are the same in all three files.
Run that list in batch mode through the CansonBaryta profile using icclu to
get absolute expected XYZ values. Using Excel, put the RGB values list side
by side with the expected XYZ values list in a test target "expected
results" ti3 file and use colverify to see the dEs of the expected results
versus the measured results. They shoudn't be too far off from what colprof
reported when it built the profile.
In the future, print the test target again, measure it, and compare the new
ti3 against the initial measurement ti3. Those dEs will encompass
everything that has changed over time: paper batch, ink batches, printer
aging, printer firmware changes, color management engine changes,
measurement device aging, etc. etc.
If those differences are beyond your tolerances, do the large patch count
target profiling process again and replace the old profile.
==========================================
Let me know how closely this matches what you're wanting to accomplish.
There's probably a more elegant way to do this than what I've described, and
I'm interested in learning what that is.
Thanks.
- Brad
-----Original Message-----
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of robert@xxxxxxxxxxxxxxxxxx
Sent: Sunday, November 02, 2014 5:09 PM
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Question regarding White Point and spotread
The whole thing is confusing, to be honest!
I?m just going to write down my explanation of what I think happens in the
commands I have below with the hope that someone will verify that this is
correct, or correct it if I have it wrong.
A. Producing and scanning target.
A.1 targen makes the .ti1 file that has the RGB values
A.2 printtarg uses the RGB values in the .ti1 file to produce a tiff file
with no profile attached. It also produces a .ti2 file that has the spot
color location information.
A.3 cctiff assigns a profile to the tiff file. To do this it looks up the
AToB1 table to get the Lab values then looks up the BtoA1 table to get the
RGB values. The effect is that the Lab values of in-gamut colors will not be
changed while the Lab values of out-of-gamut colors will be brought to the
nearest in-gamut colors (using the mapping intent specified).
A.3 The tiff file is printed with no color management (it already has the
print profile embedded)
A.4 The target is scanned, producing the D50 Lab values in a .ti3 file (the
iPFTest.ti3 file in my command)
B. Producing the simulated scanned target data
B.1 targen makes the .ti1 file that has the RGB values
B.2 fakeread takes the .ti1 RGB values and converts the values to Lab. To do
this it looks up the AtoB1 relative colorimetric table to get the Lab values
corresponding to the RGB values (it could also use the AtoB3 absolute table
which is the default, but in my command I specify relative). This results in
a .ti3 file (the iPFRef.ti3 file in my command)
C. Comparing the test.ti3 to the reference.ti3
C.1 colverify normalises the Lab values in the .ti3 files produced in A and
B above to XYZ white. I assume it does this by knowing that sample #1 in
both files is white.
C.2 colverify then does a straightforward comparison of the Lab values in
the two files.
So, is this right, or is it wrong?
If it's right, then, going back to my original question, the missing thing
in spotread would seem to be the normalisation to XYZ white ... which would
account for the dE error.
Robert
________________________________________
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of Brad Funkhouser
Sent: 02 November 2014 20:55
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Question regarding White Point and spotread
Robert,
I think I see why I was confused.
I'm bringing art from a camera into BetaRGB as absolute colors in standard
D50. If all of the artwork's colors are in-gamut for a printer space, then
I can simply convert to that space using Absolute Colorimetric and I'll get
a match to the original art when viewed under D50 light. There's no
shifting of colors due to the difference between BetaRGB white and paper
white in this absolute in-gamut case. The D50 colors are converted into
printer space as accurately as they can be.
So my mind naturally thinks of Lab values as D50. I have Photoshop
conversion set to Absolute in color settings so the info palette Lab values
I see are D50, and my i1pro measurements of printer patches and camera
target patches are always D50 Lab.
When some of an artwork's D50 colors are outside the gamut of a printer
space, I have a variety of ways to bring them inside the space depending on
what colors are outside and to what extent.
So I think I see why I was confused about your wanting to compensate
spotread Lab values for paper white. We're looking at how to use Lab from
different perspectives. I'm always thinking in terms of absolute colors and
D50 Lab is my standard. I know what all my paper whites and blacks are in
terms of D50 Lab, but I don't ever change Lab in my mind to be those
different printer spaces. Doing that would be confusing to me.
- Brad
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of robert@xxxxxxxxxxxxxxxxxx
Sent: Sunday, November 02, 2014 12:33 PM
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Question regarding White Point and spotread
Hi, yes, if I use Absolute rather than Relative the Lab value changes (but
stays the same in Relative ? providing, of course, that the color is
in-gamut).
The reason for this, I think, is that since the white point is not shifted
in Absolute, all the colors will get shifted, even those that are in-gamut.
For example, if I take a color with Lab value of 50, -8, 48 and convert it
with AbsCol the values change to 51, -8, 51 so the print will be more
yellow. As the spotread on the paper white gave 97.74, 0.2, -0.59 this
makes sense (L is increased, a is presumably decreased but we?re not seeing
it because the figure is rounded, and b is increased).
Actually, I think the way that AbsCol is described (that is that the white
point is not shifted) is very confusing to common mortals like me. What
really happens is that the destination white is matched to the source white.
If the conversion is from working space to print, all colors will be shifted
towards yellow if the working space white is yellower than the print white,
as in this case.
I have to say it surprises me a bit to find this out for the Canson Baryta
because I would have said that it is a yellowish paper. But it does have
some OBAs, and perhaps that?s throwing out the readings as I didn?t profile
with OBA compensation.
>> but when that setting is changed to "Absolute Colorimetric", the reported
Lab value in the info box changes to 87 -12 78. If I printed that color
and measured with spotread, I would expect to get a close match to the
Absolute Colorimetric value.
I think if you print the AbsCol values and compare the spotread to the
RelCol value ? well, you will to some extent be compensating for the paper
white, but you?re likely to screw up the colors, so I can?t see it working.
I still think that it is probably necessary to compensate the spotread value
for the paper white. After all, the profile does compensate for the paper
white ? but spotread has no way of doing this, so it?s reading is almost
bound to be wrong (unless the working space white happened to be identical
to the paper white, which is very unlikely).
With colverify you can normalise the file whites to XYZ, so presumably if
you print a test target, use fakeread and then compare the fakeread values
to the chartread values the whites will ?align? and the comparisons should
be valid.
This is the colverify test that (I understand was suggested by Graham):
1. targen -v -d2 -G -f100 iPFTest
2. copy iPFTest.ti1 iPFRef.ti1
3. printtarg -v -r -ii1 -a1.0 -T300 -M6 -pA4 iPFTest
4. cctiff -v -ir -e iPF6400_Canson_Baryta iPFTest.tif iPFTestO.tif
5. move /Y iPFTestO.tif iPFTest.tif
Pause Print iPFTest.tif using no color management.
6. chartread iPFTest
7. fakeread -v -Ir iPF6400_Canson_Baryta iPFRef
Pause The test results will be in iPFValidate.txt
8. colverify -v2 -N -k -s -w -x -L iPF6400_Canson_Baryta iPFRef.ti3
iPFTest.ti3 >iPFValidate.txt
Line 1: First of all we create a target with RGB values ? which is fine,
providing these are printed as is, with no color management.
Line 3: The target is created. Still fine.
Line 4: We now convert the target through the profile using RelCol.
Line 6: We read the printed target using Chartread (this is equivalent to
using spotread, so there is no white point compensation at this stage)
Line 7: We get the Lab values of the target passed through the profile.
This is equivalent to using xicclu, I think.
Line 8: colverify only gives a valid comparison between the simulated target
and the scanned target because of the ?N flag, which normalises the whites.
If what I?m saying here is correct (which would be quite a fluke ?), then we
need to do the equivalent of the ?N to the spotread data AND to the rendered
image data before comparing them.
A few days ago I suggested an ArgyllWiki to Graham (which I hope he will
pick up on), precisely for questions like these, which are not answered in
the Argyll documentation and which really need a color expert to give an
answer / solution to. At this point I don?t even know if the command lines
I have above are correct or not.
Robert
________________________________________
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of Brad Funkhouser
Sent: 02 November 2014 15:15
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Question regarding White Point and spotread
With a conversion into printer space using relative colorimetric with BPC, I
wouldn't expect the Lab value to be the same after the conversion (unless
the paper white exactly matched D50 L100 0 0 and the paper/ink black exactly
matched D50 L0 0 0).
At one point I was really confused by the following... Photoshop's info box
data on the Lab value of a color changes depending on how "Color
Settings/Conversion Options" is set.
I filled an image with 90 -14 87 Lab value (in mode Lab color) then
converted to a printer space using relative colorimetric with BPC. When the
"Color Settings/Conversion Options" is set to "Relative Colorimetric with
BPC" the Lab value reported in the info box is still 90 -14 87, but when
that setting is changed to "Absolute Colorimetric", the reported Lab value
in the info box changes to 87 -12 78. If I printed that color and measured
with spotread, I would expect to get a close match to the Absolute
Colorimetric value.
Once converted to printer space, does your reported Lab value change with
these two different Conversion Option settings?
I'm still back on CS2, so yours might be different.
Thanks.
- Brad
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of robert@xxxxxxxxxxxxxxxxxx
Sent: Sunday, November 02, 2014 7:41 AM
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Question regarding White Point and spotread
I?ve repeated the spotread using the scanning rig and the results are pretty
much the same.
If I do repeated tests after setting a reference, the dE94 starts off at
around .005 and creeps up to around .02 over 15 or so readings. Moving the
instrument changes the reading up to .25 max (over a 3cm square. Changing
to the reflective read adaptor (without recalibrating) doesn?t seem to
change things much (still around 0.3 max).
Going back to my original question: could the error I?m seeing have to do
with the white point? If I measure the paper white using spotread I get a
value of 97.74, 0.2, -0.59, whereas xicclu gives 100.000000, -0.000062,
0.000060 for RGB of 1,1,1 (or a dELab of about 2.3).
Robert
________________________________________
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of Brad Funkhouser
Sent: 02 November 2014 12:54
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Question regarding White Point and spotread
Have you spotread the patch 10 to 15 times in succession, to see your
measurement variability as the lamp heats up? Also move the read point
around on the patch to mitigate small differences in direct reflections
caused by texture? And even a tiny difference in instrument height above
the patch will change luminosity reading. Is your spotread setup truly
identical to strip reading of original target? Are you pressing down more,
or less for different readings, etc.
When I experimented with all these factors with i1pro, I was (wrongly)
expecting near perfection, and was surprised by the degree of variability.
- Brad
On Nov 2, 2014, at 3:59 AM, <robert@xxxxxxxxxxxxxxxxxx> wrote:
Hi Brad,
Between print and profiling I left the print overnight (minimum 16 hours).
After the spot test I left a couple of hours. I?ve just redone the
measurement (so about 16 hours again) and the values are now:
88.01, -13.56, 87.23 (so a bit worse).
BTW ? this may (or may not) be relevant: the profile was made using
i1Profiler (with 2584 patches) and not Argyll.
Robert
________________________________________
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of Brad Funkhouser
Sent: 02 November 2014 00:59
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Question regarding White Point and spotread
Curious... how long did the inks dry between print and measurement of the
profiling target? And between print and measurement of the spot color test?
Thanks.
- Brad
On Nov 1, 2014, at 4:31 PM, <robert@xxxxxxxxxxxxxxxxxx> wrote:
I wonder if you would be kind enough to clarify something for me?
I?m trying to do a spot color test from a document through to print, and
this is what I?m doing (using Photoshop and Argyll):
1. The spot color has a Lab value of 90, -14, 87 in Photoshop.
2. I convert the document to the print destination space (relative
colorimetric with BPC).
3. After conversion, the spot color is RGB 240, 247, 52 (or 0.941176,
0.968627, 0.203922). The Lab value from Photoshop is still 90, -14, 87, as
expected.
4. xicclu (rel. col.), with the RGB colors above through the profile
(forwards), gives Lab 90.33650, -14.520704, 87.115660. I assume that
Photoshop is effectively doing the same as xicclu but is rounding the
values.
5. I also tried fakeread (rel.col) which gives me exactly the same Lab
values as xicclu.
6. I print the image with no color management.
7. spotread gives me Lab values of 88.987, -13.637, 87.268. This is a dE-Lab
of about 1.6 compared to the xicclu reading.
The dE-Lab error seems too high as I have only just calibrated the printer
(iPF6400) and profiled the paper (Canson Baryta, so good paper).
colverify has an option to normalise each file?s readings to white XYZ, but
xicclu, fakeread and spotread have no such adjustment.
I would have thought that the paper white would need to be taken into
account in comparing the spotread value to the image Lab value. Should the
paper white be measured and the spotread value normalised? If so, how
should this be done?
I appreciate your help.
Robert
Other related posts:
