Printer Profile Validation: M1 vs. M2 and ΔE2000 Evaluation

[itsab1989]

ChromIQ: i1Pro Test Button Integration for Measurement Retry

Current Behaviour:
When a measurement error occurs and a rescan is required, the user must click the Retry button on the screen to resume the measurement process.

Suggestion:
Allow the user to operate the i1Pro's physical Test Button to handle the retry process:
. Press the i1Pro Test Button once to select Retry.
. Press the Test Button a second time to proceed with the rescan.

This would simplify the workflow and reduce the need to interact with the on-screen controls during measurement.

The idea was inspired by i1Profiler.

Sounds like a good suggestion. I will see whether this is possible.

 

[know]

However, during verification, I spent considerably more time than expected taking measurements because the i1Pro repeatedly failed to read certain strips.

Hi again @jctay ,
@itsab1989 has analysed your logs and it turns out that it is your 192 patch chart that is the problem. The spacers are far too thick compared to the rest of the patch, and thus too many samples (of the 400 samples per second sampling frequency of the i1Pro3) land on the spacer, mistaking spacers for patches. This causes the reading errors you frequently had, which probably was worse when you were sliding slowly. This is the most likely error. Try reducing the spacer thickness to half or a third of what is shown on the images you gave earlier. Else use one of the preset charts, which do not have this issue.

Let us know if this solved the misreading problem...

Cheers,
Knut

 

[itsab1989]

Claude is currently working on some things. If everything works as expected the next beta should have the feature you have requested (pressing the device button to retry). I will report back when everything is done.

Edit:

Update is out:
https://github.com/itsab1989/ChromIQ/releases/tag/v4.3.8

 

[jctay]

Hi again @jctay ,
@itsab1989 has analysed your logs and it turns out that it is your 192 patch chart that is the problem. The spacers are far too thick compared to the rest of the patch, and thus too many samples (of the 400 samples per second sampling frequency of the i1Pro3) land on the spacer, mistaking spacers for patches. This causes the reading errors you frequently had, which probably was worse when you were sliding slowly. This is the most likely error. Try reducing the spacer thickness to half or a third of what is shown on the images you gave earlier. Else use one of the preset charts, which do not have this issue.

Let us know if this solved the misreading problem...

Cheers,
Knut

I’ve taken steps to address the issues causing the measurement errors. Thank you for pointing them out.


ChromIQ v4.3.8

The latest release represents a significant improvement! The addition of the retry function is a big plus for the measurement workflow.

Measuring the verification target required only two retries this time. I’ll share more screenshots as soon as they’re ready.

 

[itsab1989]

I’ve taken steps to address the issues causing the measurement errors. Thank you for pointing them out.


ChromIQ v4.3.8

The latest release represents a significant improvement! The addition of the retry function is a big plus for the measurement workflow.

Measuring the verification target required only two retries this time. I’ll share more screenshots as soon as they’re ready.

View attachment 19467

Nice to hear that! And thanks for suggesting this feature. I remember thinking of something similar when I measured a chart and had issues myself. But I had my focus on something else at that point and simply forgot about this. So thanks for bringing this up!

 

[jctay]

ChromIQ Profile Verification

In my previous test, I selected the Preset patches instead of generating the verification patches entirely in Profile Gamut mode. As a result, the chart included highly saturated patches.

1. Patch Distribution: Verification Patches vs. Profiling Target Patches

2. Full colour check · Judged against ISO 12647-72016 values

3. Validation print check (ISO 12647-8) · Judged against ISO 12647-82021 values

 

[know]

2. Full colour check · Judged against ISO 12647-72016 values

@jctay
Thanks for sharing.... it looks very nice. Your printer give very good output

Note 3 in the report results say that you don't have good enough neutral grey data for it to be judged. This is probably due to the 192 patch chart you used for verification, which does not have a very good neutral and near-neutral patch set. (Edit: I changed these first paragraphs. I first referred to the 572 patch profiling chart relating to the report's grey metrics, which is wrong, because it is the 192 patch chart that is used for the verification that is judged by the report)

I still recommend the built in preset "i1Pro · 100x150mm-600p-4pages-Portrait-w7.5mm" before the 572 patch chart you are using for profiling, due to the superior neutral grey and near-neutral grey coverage that the 600 patch preset uses. You can of corse use the ChromIQ patch editor (tools-->"Edit / Create Chart Patch Set") to create a better patch set for the 572 patch chart you are using, if you prefer its chart layout.

Also,
There is a bug in the report that @itsab1989 should register for a next release...

Right above the line "3. Validation print check (ISO 12647-8) · Judged against ISO 12647-82021 values", the section "Worst Patches" The Expected an Measured Patches are not correct. Measured patches does are not matching the Expected colours. This seems to apply for the report type "Full colour check" with the "Judged against" set to "ISO 12647-7:2016 values" limit set.

@jctay: could you please provide the log file? That would probably help.


I also notice that there is a gap in the ChromIQ set of provided buil-in presets for the 100x150 mm card. the presets jump from 180 patches to 600 patches, so there should be added a 300 patch version for 2 pages. Until that is added, attached is a ready made preset you (or anyone) could use:
"i1Pro-100x150mm-300p-2pages-Portrait-w7.5mm-TC3.00 Equivalent Target (ChromIQ Editor)"

Worth noticing also: this 300 patch preset has more than the required 9x9 columns/rows for the measurement report to judge evenness on the chart. Thus, the two metrics in the reports above

may give results when using this chart. Your 192 patch chart does not seem to fulfil this requirement.

To use the attached preset:
Go to the Manual mode in Create Chart tab, and look at the Presets frame:

Press the folder button next to the gear-button. This opens the folder location where custom presets are stored. Place the two files attached in that folder and restart ChromIQ. The preset will then be available in the "Select presets" pulldown list, at the top, above all the built-in presets.

Thanks

 

[know]

One more observation, which because clear while investigating the report bug on the worst patches:

Expected for patch 36A looks like the Measured placed on 36B.
Expected for patch 36B looks like the Measured placed on 36C.
Expected for patch 36C looks like the Measured placed on 36D
Expected for patch 36D looks like the Measured placed on 36E.
Expected for patch 36E looks like the Measured placed on 36F.
Expected for patch 36F looks like the Measured placed on 36G.
Expected for patch 36G looks like the Measured placed on 36H.
Expected for patch 36H does not have a measured equivalent visible among them.

This indicates what might be the cause of the bug, yes, but it also shows that all the worst patches seem to be coming from the same strip number 36 from the verification measurement of your 192 patch chart. This should normally never happen, unless that strip is a misread with high error. I suggest you re-read that strip of the verification measurement (run type=verification), inspect if there are any highlighted red patches among your measurements ("Show patch values on hover" must be ON), then re-read those if existing, then update the measurement reports you created. Then you can see if things improved a bit.

Cheers,
Knut

 

[jctay]

One more observation, which because clear while investigating the report bug on the worst patches:

Expected for patch 36A looks like the Measured placed on 36B.
Expected for patch 36B looks like the Measured placed on 36C.
Expected for patch 36C looks like the Measured placed on 36D
Expected for patch 36D looks like the Measured placed on 36E.
Expected for patch 36E looks like the Measured placed on 36F.
Expected for patch 36F looks like the Measured placed on 36G.
Expected for patch 36G looks like the Measured placed on 36H.
Expected for patch 36H does not have a measured equivalent visible among them.

This indicates what might be the cause of the bug, yes, but it also shows that all the worst patches seem to be coming from the same strip number 36 from the verification measurement of your 192 patch chart. This should normally never happen, unless that strip is a misread with high error. I suggest you re-read that strip of the verification measurement (run type=verification), inspect if there are any highlighted red patches among your measurements ("Show patch values on hover" must be ON), then re-read those if existing, then update the measurement reports you created. Then you can see if things improved a bit.

Cheers,
Knut

Yes, some strips were read multiple times.

I used only the 576-patch chart, and the verification chart was generated using Profile Gamut mode.

Please find the two attached ZIP files: Logs and Measurement_Report.

 

[jctay]

found strip-36