Large errors during printer profile check

[Ivan Tsyba]

Hi

Today I try to use ArgyllCMS 1.6.3 to create profile of RGB printer using
ColorMunki spectrometer. Earlier I used 1.4.0 version and as was mentioned
on this list, I slow down strip reading speed because of reduced scan rate
in 1.6 ArgyllCMS. "Too many patches" errors occurs more frequently than on
1.4.0 but chart was scanned successfully.
Checking of profile that was created from my measurements show large errors:

Profile check complete, errors: max. = 54.739534, avg. = 3.634257, RMS =
7.913384

and after remeasuring of whole chart I got similar result:

Profile check complete, errors: max. = 50.801395, avg. = 2.787503, RMS =
6.151080

After third measuring of this chart using 1.4.0 chartread and colprof I got
completely different results:

Profile check complete, errors: max. = 3.024343, avg. = 0.892335, RMS =
1.033585

So old 1.4.0 give in my case better results than 1.6.3

I do something wrong? I missed something?

Here I post all logs and produced files (1.2 Mb):
https://dl.dropboxusercontent.com/u/28502325/Argyll_logs.zip

[Graeme Gill]

Post by Ivan Tsyba
Profile check complete, errors: max. = 54.739534, avg. = 3.634257, RMS =
7.913384

Something has not lined up properly - there's at least one patch
out of place. Using profcheck -v2 will reveal which patches are not
correctly read.

Post by Ivan Tsyba
Profile check complete, errors: max. = 50.801395, avg. = 2.787503, RMS =
6.151080
After third measuring of this chart using 1.4.0 chartread and colprof I got
Profile check complete, errors: max. = 3.024343, avg. = 0.892335, RMS =
1.033585
So old 1.4.0 give in my case better results than 1.6.3
I do something wrong? I missed something?

Something strange is going on. How have you printed the chart ?

Note that by default chartread will automatically determine what
direction each strip was read. If the chart wasn't arranged to
maximise the direction differences, then this may not work
reliably and the chartread -B flag should be used and
the strips read in the forward direction only.

Post by Ivan Tsyba
https://dl.dropboxusercontent.com/u/28502325/Argyll_logs.zip

Notice that it is the D and perhaps R strip that has not been
read correctly.

Graeme Gill.

[Ivan Tsyba]

Post by Graeme Gill
How have you printed the chart ?

Chart was printed from ACPU on OS X

Post by Graeme Gill
Notice that it is the D and perhaps R strip that has not been read

correctly.
Device was correctly placed with ruler and moved slowly. With 1.4.0
ArgyllCMS I read chart faster with no misreads and got much smaller errors
during profile check. I'm using Ubuntu 13.10.

Maybe newer chartread with ColorMunki give bigger read errors in some
cases? Maybe this is similar problem that was in 1.5 and fixed in 1.6.1:
"Fix ColorMunki reflective measurement accuracy"?
Maybe I can provide more information or perform some tests?

[BC Rider]

Post by Ivan Tsyba

Post by Graeme Gill
How have you printed the chart ?

Chart was printed from ACPU on OS X

Have you measured the actual printed patch size to verify no
unexpected scaling has occurred?

What size are the measured patches (best to measure 10 or
more patches and divide)?

Post by Ivan Tsyba
Maybe newer chartread with ColorMunki give bigger read errors in some
cases?

If you suspect version 1.6.3 then suggest dropping back to 1.6.2 to verify nothing
hasn't been corrupted in v1.6.3. v1.6.2 is well proven and definitely doesn't
have the problems you are encountering.

Could it be a Ubuntu problem? My tests are all assuming Windows 7.

[Ivan Tsyba]

Have you measured the actual printed patch size to verify no unexpected

scaling has occurred?
I use double-sided ruler which have exactly 5 rows width, so there was no
error.

If you suspect version 1.6.3 then suggest dropping back to 1.6.2 to

verify nothing hasn't been corrupted in v1.6.3. v1.6.2 is well proven and
definitely doesn't have the problems you are encountering.
Ok, I will try 1.6.2 chartread soon

Post by Ivan Tsyba

Post by Graeme Gill
How have you printed the chart ?

Chart was printed from ACPU on OS X

Have you measured the actual printed patch size to verify no
unexpected scaling has occurred?
What size are the measured patches (best to measure 10 or
more patches and divide)?

Post by Ivan Tsyba
Maybe newer chartread with ColorMunki give bigger read errors in some
cases?

If you suspect version 1.6.3 then suggest dropping back to 1.6.2 to verify nothing
hasn't been corrupted in v1.6.3. v1.6.2 is well proven and definitely doesn't
have the problems you are encountering.
Could it be a Ubuntu problem? My tests are all assuming Windows 7.

[BC Rider]

Post by BC Rider

Post by Ivan Tsyba
Maybe newer chartread with ColorMunki give bigger read errors in some
cases?

If you suspect version 1.6.3 then suggest dropping back to 1.6.2 to
verify nothing hasn't been corrupted in v1.6.3. v1.6.2 is well proven and definitely
doesn't have the problems you are encountering.
Could it be a Ubuntu problem? My tests are all assuming Windows 7.

I had time so did a comparison of v1.6.2 with v1.6.3.


I downloaded and installed v1.6.3 then rescanned my last target

set (Red River Metallic). Around 1500 patches on a 290cm x 330cm sheet.



I used the same chartread command as before:

- chartread -v -B -L -T0.2 RR_Epson3880_Metallic


During operation Chartread flagged errors three times: Two were due to

"inconsistent results" and one due to "too many patches". All cleared with

a single rescan of the line.



I then compared the sample values in the .ti3 file with those taken a couple months

earlier using v1.6.2. Colverify produced these results:

Verify results:
Total errors: peak = 0.241827, avg = 0.035801
Worst 10% errors: peak = 0.241827, avg = 0.125524
Best 90% errors: peak = 0.082837, avg = 0.025910
avg err X 0.000014, Y 0.000013, Z 0.000012
avg err L* 0.011505, a* 0.016908, b* 0.023820


I then made a new profile and Colprof finale profile check gave these results:

- peak err = 2.481701, avg err = 0.485129, RMS = 0.571661.



Conclusion: The new Chartread (v1.6.3) seems OK. I'm using the Munki with Windows 7, 64 bit.



As an aside, I was surprised the results were so similar given the target set has been

sitting exposed on my side desk for the past couple months and I had to wipe off the dust

and dirt (including a bit of "scrubbing" in one particularly dirty spot).