Argyll print profile black point color shift with ColorMunki: FIXED in v1.6.1

[NeroMetalliko]

Hello,

I have an Epson R3000 and a ColorMunki photo.
I'm trying to optimize my printing performances on Hahnemuehle Photo Rag Baryta 315 (PK).
For this purpose I liked to build a custom profile using the X-Rite software provided with the Colormunki (50+50 patches) and another made using Argyll (840 patches, including 64 grays).
Then I wanted to compare the Hahnemuehle canned profile vs the X-Rite vs the Argyll ones.

From the 3D gamut volume point of view the Argyll one was clearly superior, the X-Rite being only slightly bigger than the canned one (which is the smallest).

But there is a strange thing I have noticed regarding the Argyll profile.
looking carefully at the 3D gamut volume bottom vertex I see that the max density point (blackest) is shifted in a* and b* instead of being on the gray axis and this fact is confirmed looking with profile inspector in the tags:

Argyll icc Media black point XYZ: 0.0032349, 0.0038757, 0.0000153; Lab: 3,5, -2,03, 6,01
X-Rite icc Media black point XYZ: 0.0054626, 0.0056458, 0.0045624; Lab: 5,1, 0,07, 0,18
Hahnemuehle icc Media black point is not written in the profile tags, but looking at the curves of relative colorimetric and at the 3D Gamut I can confirm that the black point is reasonably on the neutral gray axis.

So, it seems that the max density is reached with a deep color and not a deep gray in the Argyll icc,  and I suspect the gray axis was somewhat "bent" to the black extreme in order to get max density but loosing the hue neutrality for the black point.

Currently, if I print a grey step wedge using this Argyll icc with relative colorimetric and BPC ON, I see that starting from L* below 30 there is a roll of the a* and b* in the deep shadows and the black is definitely a deep purple.
No problem if I print the same wedge using the Hahnemuehle canned profile.

my Argyll workflow was the following (profile named 4xA4):
- targen -v -d2 -G -B8 -e8 -g64 -f840 4xA4
- printtarg -v -iCM -h -T360 -p210x297 4xA4
- chartread -v -H -B -T0.4 4xA4
- colprof -v -qh -i D50 -o 1931_2 -S AdobeRGB1998.icc -cmt -dpp 4xA4
- profcheck -v2 -k -i D50 -o 1931_2 -w 4xA4.ti3 4xA4.icm > 4xA4.log

I am on PC, I'm pretty sure I have printed the targets (4 A4 sheets) without any color management engaged, in any case I have made another try using ACPU and double checked to have disengaged color management in the driver settings and the icc results are identical (blackpoint shifted).
In addition I have tried to make a manual spot reading in ColorPicker of different black patches across the sheets.
I get results of Lab in the range: 4,8 0,1 0,9
and these are reasonably black, not purple, so I can confirm that the target sheets are printed OK.

EDIT: a black patch printed with the Argyll icc using relative colorimetric and BPC ON is Lab: 4,7 2,6 -7,9 so it is definitely purple, but is not like the black point inside the icc tags which was, as written above, Lab: 3,5, -2,03, 6,01 so not really purple but colored in the opposite way for a* and b*...  

Looking at the various options in Argyll "colprof" I can see that there is something related to the white point, but really nothing related to the black point, so I don't know how to fix this.

In attachment you can find the .ti1 .ti2 .ti3 and .log files.

Any advice will be greatly appreciated,
many thanks in advance for the attention,
ciao,

Andrea

[Czornyj]

CMP is not the best sensor to scan such amount of patches. It's getting inconsistent results when gets heated from hand during long scanning session.

[NeroMetalliko]

Hello,
thanks for the answer,
I have never experienced any issue with the CMP, a shift exist for sure but is probably not of this degree of magnitude...

In any case the first black patch read was D15, this means at the end of only 5 rows scanned, and in the .ti3 file I see:
597 "D15" 0.00000 0.00000 0.00000 0.299921 0.374499 0.00000

the latest black is located at AX14 (in the middle of the latest sheet) and look like this in the .ti3 file
4 "AX14" 0.00000 0.00000 0.00000 0.317900 0.369727 0.00000

EDIT:
in the .log file I see the following for the D15 and AX14 patches:
[0.595041] 597 @ D15: 0.000000 0.000000 0.000000 -> 3.506873 -2.048885 6.029440 should be 3.382839 -2.470152 5.832482
[0.669964] 4 @ AX14: 0.000000 0.000000 0.000000 -> 3.506873 -2.048885 6.029440 should be 3.339734 -1.558346 5.758162

(In any case I have tried to make another icc using a target made only of a single A4 sheet and the results are similar).

So, yes, there was a little shift but not so much to justify what is happened in the icc black point (imho).
Please, let me know what you think.

EDIT2:
I have tried to re-read with chartread the 2 rows containing D15 and AX14 black patches with an ambient temperature fresh ColorMunki and these are the .ti3 re-readings:
597 "D15" 0.00000 0.00000 0.00000 0.339547 0.401799 0.00000
4 "AX14" 0.00000 0.00000 0.00000 0.322224 0.387617 0.00000  

Keeping in mind that the inks are settled for few days from the first read and that I have not had particular care for the sheets (so some little deterioration on the surface may be occurred in the black patches), I can see that the results are very similar to the previous ones.
This time the ColorMunki was perfectly cold and I made the measurements in less than a minute.
The same two patches re-measured now in ColorPicker spot gives me the following readings:
D15 Lab: 4,9 0,2 0,3
AX14 Lab: 4,7 0,1 0,7
All these numbers are consistent with the already done measurements so, after seeing that, I can reasonably exclude any measurement error or temperature shift issue.

Given these readings I still wonder why Argyll decided to adopt a  Lab: 3.506873 -2.048885 6.029440 Media Black Point.


Any further suggestion is welcome.
Thanks.

Andrea

[Czornyj]

Could you provide the measurement file?

[NeroMetalliko]

Hello,
thanks for your support, it's really appreciated.

The full measurements file (4xA4.ti3) is attached in the first post with all the others (.ti and .log), you need to be logged on to see it and download it.
In this way you are able to freely experiment with colprof options and build different profiles based on my same measurements.

Let me know if you find something I missed...

Thanks,
ciao.

Andrea

[NeroMetalliko]

VERY IMPORTANT UPDATE:

OK, there is definitely something weird in the way Argyll "chartread" read the blacks with the CM.

- I have engaged the -L option in chartread to provide even the measured Lab values in the .ti3 output file.
- Then I have re-read the AX row, which contains some colors and 2 (of the 8 ) black patches: AX1 and AX14
- The resulting output file is visible in attachment renamed as "AXrow.ti3.txt"
Looking at the AX1 and AX14 exported Lab values in the ti3 file I see the following:

SAMPLE_ID SAMPLE_LOC RGB_R RGB_G RGB_B XYZ_X XYZ_Y XYZ_Z LAB_L LAB_A LAB_B
439 "AX1" 0.00000 0.00000 0.00000 0.371180 0.434830 0.00000 3.92780 -1.94164 6.77208
4 "AX14" 0.00000 0.00000 0.00000 0.345434 0.412786 0.00000 3.72868 -2.12301 6.42876

So this is the culprit: it seems that the blacks are read in wrong way by chartread.


At this point I launched X-Rite ColorPicker and I re-read the same AX row in strip mode from there.
The resulting measurements are visible in the attached "AXrow.CM.txt" file

   Color Name      L      A      B
AX1   Black         4.942697   0.079788   0.736019
AX14   Black         4.772324   0.008032   0.807869

Here we are: ColorPicker got the right values.
Now, I have used ColorPicker consistently for 9 months over a lot of test during my B&W linearization development and I'm 100% sure it is right,
in addition these readings are consistent with the correct icc produced by X-Rite software and with the Hahnemuehle one (both with a correct black point), so, I have no doubts.

Looking at the other colors of the row between the Argyll chartread and the Colorpicker  it seems that all the remaining 13 colors are reasonably matching but the blacks are completely different.

Please, let me know what do you think.
Any suggestion regarding how to fix this black chartread misreadings are welcome.
Many thanks in advance,
Ciao.

Andrea
 

[NeroMetalliko]

Any suggestion regarding how to fix this black chartread misreadings are welcome.

OK, I'm quoting myself here.
I have tried disengaging the -H flag in chartread and re-read the AX row.
The results are visible in "4Ax4_AXrow(no-H).ti3.txt" attachment.

SAMPLE_ID SAMPLE_LOC RGB_R RGB_G RGB_B XYZ_X XYZ_Y XYZ_Z LAB_L LAB_A LAB
439 "AX1" 0.00000 0.00000 0.00000 0.425937 0.440441 0.144015 3.97849 0.0510300 4.14046
4 "AX14" 0.00000 0.00000 0.00000 0.398379 0.411552 0.106255 3.71753 0.0630325 4.40346

This is something better:
L* is not changed.
a* is correctly near 0 (previously was -2)
b* is still 4 (previously was 6,7), and this is not so good as it should be (less than 1)

Then I have tried engaging -p for single patch read in chartread and re-read patches AX1 and AX14
The results are visible in "4Ax4_AXblacks(no-H_-p).ti3.txt" attachment.

SAMPLE_ID SAMPLE_LOC RGB_R RGB_G RGB_B XYZ_X XYZ_Y XYZ_Z LAB_L LAB_A LAB
439 "AX1" 0.00000 0.00000 0.00000 0.501539 0.523516 0.360842 4.72890 -0.130638 1.34060
4 "AX14" 0.00000 0.00000 0.00000 0.473103 0.494490 0.330598 4.46671 -0.148756 1.45954  

This is definitely better:
L* is near the Colorpicker values of 4.7.
a* is correctly near 0
b* is near 1,4 and this is not perfect but still acceptable or at least not so wrong

CONCLUSIONS:
In my setup, with my ColorMunki, Argyll (v1.6.0) "chartread" is not reliable in strip mode regarding the blacks readings.

If the -H (high resolution spectrum mode) option is engaged the results are even worst, so I warn the Colormunki users to disengage the -H  option at least.
 
Acceptable blacks reading are possible only using the single patch -p (spot) reading mode, and not going in strip mode (and even in this case it seems that the b* reading is not perfect).

Please, don't tell me something like "buy an i1Pro2", because in reality the little colorMunki work perfectly for blacks reading even in strip mode, if used with their x-Rite software, so it is not an hardware limitation, it is a problem in the way chartread and Argyll drivers are interpreting the ColorMunki data.

But there is something more to add.

I own a i1DisplayPro which I use for display calibration.
After all of this I have tried to calibrate my screen using Argyll+dispcalgui
with the i1DisplayPro and then with the ColorMunki.
Do you want to know what was the results?
The screen profile made with the i1Displaypro was perfect (I have always used the colorimeter for the screen),
but the screen profile made using the ColorMunki was somewhat screwed in the blacks showing a purple cast!

So, this is a confirmation that the problem is in the coupling Argyll+Colormunki.

The Colormunki used with X-Rite software is good and reliable, if used with Argyll there could be big problems in the blacks readings (for print and for screen too).
The i1DisplayPro is perfect for screen even using Argyll+dispcalgui.


So, the bottom line is that I think I'm screwed now.
I don't care to avoid the use of the CM for screen, I always used the I1DisplayPro for this, but for the print profiles, reading 1000 patches one by one is a real pain and I don't know if I will go for it.
This is sad, because I have to stick with the limited CM software for the printer, and I'm not happy because I think that Argyll could produce higher quality profiles.

Obviously my above conclusion are limited to my explained experience, it could be nice if someone else could be able to replicate the issue and share the results.

I'm very curious if similar issues could be observed even using the more performing i1Pro2, because it will be really disappointing if the case.

In any case, I hope all this stuff will be appreciated and could be useful for other ColorMunki + Argyll users, because I think this could be a real problem, or at least something to keep under consideration.

Please, let me know your opinion/experience, it will be welcome.
Thanks for the attention for now.
Ciao.

Andrea

[Czornyj]

I'm afraid I was right, long scanning makes the instrument warmer, which induces higher noise and crashes shadows. In case of X-Rite software it only takes few quick scans, so there's no such an issue. Try using small target to check if you will also get wrong black readings in strip mode.

[NeroMetalliko]

I'm afraid I was right, long scanning makes the instrument warmer, which induces higher noise and crashes shadows. In case of X-Rite software it only takes few quick scans, so there's no such an issue. Try using small target to check if you will also get wrong black readings in strip mode.

Hello,
thanks for the answer,
maybe, due to my bad English, I was not able to well explain all my test and the related final findings.

What I have observed and illustrated clearly demonstrated that the main issue has nothing to do with thermal drift noise or whatever.

The problem is that there is something wrong in the "chartread" code. It is a pure software issue.
In strip mode Chartread is not able to correctly read black patches with (at least my) Colormunki.
In single patch (spot) mode Chartread is better performing but still not perfect.
In both modes the optional -H (high resolution) flag produces evident worst results, if used.

The exact same physical single row (AX in the above examples),
read alone, one time using Chartread, and read alone one time using X-rite ColorPicker,
both in strip mode, at the same speed, using the same small amount of time (total ON time less than 30 sec from the instant I plug the CM in the USB port)
are showing a wrong black reading for Chartread and a correct black reading for ColorPicker.
(look at the data I have previously attached).

The test is repeatable and produces identical results each time.

This is a clear proof that the problem is in the algorithm used by Chartread to read a strip, that has some problem with the blacks and is not so effective as the one used by ColorPicker to read the same blacks on the same strip in the same amount of time starting from the same OFF condition.

I think I will write soon an e-mail to the Argyll author asking for their valuable opinion.

I hope I was able to clarify my findings better this time, and, please, let me know if you think there is something still not clear.
Thanks.
Ciao.

Andrea

 
 

[Czornyj]

Try to describe your problem on ArgyllCMS mailing list:
http://www.argyllcms.com/mailinglist.html

Graeme is very helpful, and if there's a bug in chartread he'll fix it in next release.

[NeroMetalliko]

Try to describe your problem on ArgyllCMS mailing list:
http://www.argyllcms.com/mailinglist.html

Graeme is very helpful, and if there's a bug in chartread he'll fix it in next release.

Hello,
thanks for the answer,
In the meantime I have written an e-mail directly to Graeme, describing shortly the issue and pointing to this thread for more details,
but now I realize that the more correct way to act is the one you have suggested, i.e. the mailing list (which I was not aware of).

Currently I don't know if this could be really a bug or not, maybe there is still something I'm missing...
In any case I think that the Graeme opinion would be decisive.
If I don't get an answer I will subscribe the mailing list and try to post there.

In order to get more feedback on this item I have prepared a specific test easy to perform if someone is willing to contribute.
I have posted all the test details in the other section of the forum only because it require to print a target.
You can find it here:
http://www.luminous-landscape.com/forum/index.php?topic=82171.0

I hope this will be helpful.

Let's wait and see if someone else is able to replicate my findings.

Any further suggestion is welcome.
Thanks again.
Ciao.

Andrea

[NeroMetalliko]

Hello,
after some days of testing different beta versions and the effective work of Graeme Gill
I'm happy to report that the chartread issue I have discovered/illustrated in this thread
was successfully fixed in the new Argyll update v1.6.1 released yesterday,
as visible in the changes log file:


Argyll CMS change log
=====================

Version 1.6.1 (30th September 2013)
-------------
...

*   Fix bug introduced into ColorMunki (spectro) reflective
   measurement that created discrepancies between spot
   and strip measurement mode. Changed short wavelength
   handling to be more like the manufacturers driver in
    duplicating values, reduced reflective strip reading
   scan rate to 55Hz to reduce reflective electrical interference
   error.
...


It was a quite intense work in the past days, but now I can say that I have verified that with this update the performances of chartread in strip mode using ColorMunki are drastically better than in v1.5.0 - v1.6.0 version and slightly better than ever.
The spot/strip mode now is good matching and the overall accuracy/repeatability could be considered on par with the one showed from X-Rite ColorPicker software.

Based on the various test done in these days comparing several chartread releases,
I can add that the -H (high reslolution) mode was not recommended at all with ColorMunki
because the spectrum data was noticeably affected by noise and the overall accuracy/repeatability of the measurements was always a little bit worse
than the one achieved by not engaging the -H flag. This fact was noted in both strip and spot mode (-p flag) but more evidently in strip mode.

NOTE:
currently (v1.6.1) there is still a little bug in chartread because the -H flag is still not correctly working (missing 3nm interval in spectral data output), but it does not seem to harm anymore.
This bug will be fixed in the next v1.6.2 release and I will check if the noise issue will still be there or if Graeme Gill will be able to do its magic again by successfully resolving even this not desired side effect.

In addition I can confirm a slight benefit by using the -T0.4 option:
I have compared readings accuracy/repeatability in strip/spot mode
using -T0.2, -T0.4 and without -T and, even if the difference is small, the best results were obtained by using T0.4 followed by not using -T (-T0,2 was too tight).

Based on all these findings my current (and recommended) command line for chartread print profiles using ColorMunki is:
chartread -v -B -T0.4 'profilename'
 
Note that, as per what is known, this issue was limited only to the ColorMunki spectro.

My humble suggestion is that, if you have made some print profiles using ColorMunki in strip mode with version v1.5.0 to v1.6.0
you should consider to remake the profiles, specially if you have used the -H option.

More details regarding the specific measurements I have done are available in the test thread you can find it here:
http://www.luminous-landscape.com/forum/index.php?topic=82171.0

I have modified the main title of the threads in order to reflect the 'FIXED' status of the issue.

I Hope this will be helpful.

Ciao.

Andrea

[MiSwan]

Andrea,

bel lavoro, complimenti!