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

A small correction about the test
Sorry, I explained it badly: the test does not need a strip of 24 patches. A small turned chart of 4 strips with 6 patches each is enough. Print it, set i1Profiler to another grid (for example 5x5 or 12x2), and try to scan one printed strip of 6. If you find the time, that would tell us whether i1Profiler's strip mode lets a wrong grid through.

If I have interpreted your instructions correctly, the workflow would be as follows:

Step1. Prepare the Chart in ChromIQ
- Start with a CC24 chart using a 6 × 4 layout in ChromIQ.
- Set up the chart in the Beta tab, with Spacers set to None.
- Apply ChromIQ s turned algorithm and export the resulting .txf file.

Step 2. Generate and Print the Chart
- Change Spacers to Black & White or Coloured.
- Generate the chart.
- Print the chart using ChromIQ s Print Chart function.

Step 3. Import into i1Profiler
- Import the exported .txf file into i1Profiler.
- The chart should appear in a 4 × 6 layout in i1Profiler.

Step 4. Perform the Measurements in i1Profiler

For completeness, I 'll test the following three configurations:

1. Import the .txf file and retain the original 4 × 6 layout.
2. Import the .txf file and change the layout to 5 × 5.
3. Import the .txf file and change the layout to 12 × 2.

Each measurement should contain all 24 patches in the resulting .mxf file.

Important: i1Profiler must successfully measure and save all 24 patches. An incomplete measurement cannot be saved into an .mxf file.

Do you agree with the proposed workflow outlined above?

Note: I don't see any differences compared with the files I previously sent you.

I think I may not have made myself clear:
i1Profiler only allows an .mxf file to be saved after all 24 patches have been successfully measured. If even one patch is missing, the measurement cannot be saved as an .mxf file.
 
Last edited:
@jctay thank you, that was a good find, and your numbers made it easy to follow. Yes, there is a clear pattern, and it is all i1Profiler's own layout rule:

  • Columns: i1Profiler puts as many patches across as the paper width allows. It needs 31 mm of margin plus the patches, so with 8.5 mm patches 12 columns need 133.0 mm and 13 columns need 141.5 mm (31 + 13 x 8.5). That is exactly your 141.4 / 141.5 switch. It also cuts anything you type down to 0.1 mm, so 141.49 still counts as 141.4.
  • Rows and pages: the paper height must hold 35 mm plus the rows, rounded up to a whole millimetre: 171 mm for 16 rows, 163 mm for 15 rows. That is your 170.9 / 171.0 switch, and it is why rounding to whole numbers shows the pattern. The "Size: 13.3 x 17.1 cm" in the chart header is exactly that smallest page.
  • Rows 9 to 16 are not missing: when the rows do not fit, i1Profiler uses as few pages as it can and shares the rows out evenly, so 16 rows become 8 + 8. Your screenshot says "Page 1 of 2", and rows 9 to 16 are on page 2. A slightly smaller page that would hold 10 rows still gives 8 + 8.

Does this affect ChromIQ's charts? No. ChromIQ never sets the paper width on one of these switch points. For your chart the .txf asks for 137.25 mm, which is in the middle between 133.0 (12 columns) and 141.5 (13 columns), so there are more than 4 mm of room either way. The paper height is 210 mm, far more than the 171 mm needed. Your .txf files are not outdated: ChromIQ 4.3.30 writes exactly the same settings for your chart. We also checked about 28,000 other chart sizes, and none ends up close enough to a switch point for rounding to change the column count.

If the paper size is changed in i1Profiler and it ends up with 13 columns, the import of that measurement is refused with a message about the grid, so a wrong grid cannot slip into a profile. Spreading the same 12 columns over two pages is fine and is accepted.

One correction to an earlier post of mine: I wrote that i1Profiler chooses the rows first. It is really the other way round: it takes as many columns as the paper width allows, then the rows it needs, and then evens out the columns. For 24 patches on 2 rows that still gives 12 columns, so the example stays true.

Your test plan
Yes, that is the test, thank you for writing it out so carefully. Just two small changes, and a little background.

Two small changes
  • Please export the .txf after you have generated the chart with the spacers you will print (Black & White or Coloured), from that same chart. Then the file and the printed sheet are sure to belong together. Changing the spacers after the export changes the layout of the sheet, and the strips could end up different from what the .txf describes.
  • Configuration 1 (4 × 6 kept as it is) is the check that everything works. The interesting ones are 2 and 3, and there the most useful thing is not the saved file but what i1Profiler does at the moment you scan: when it shows rows of 5 (or 12) and you scan one printed strip of 6, does it accept the scan, refuse it, or ask you to scan again? A screenshot or the exact wording of any message would help a lot.

Why this is different from your earlier files
Your earlier files were measured once, on the right grid, and only saved again afterwards under other page layouts. i1Profiler then moved the finished readings to the new pages correctly, so they were all fine. This time the grid is wrong while you measure, so i1Profiler has to decide where the scanned patches go. That is the one case ChromIQ's grid check is meant for, and the one we cannot test ourselves without a printer and an instrument.

About the complete file
You were clear, and I understand: i1Profiler only saves an .mxf when all 24 patches have a reading. That is exactly what worries us. If i1Profiler accepts a strip of 6 into a row of 5, the file can still end up with 24 readings, complete and saveable, but with some readings on the wrong patches. So:
  • If i1Profiler refuses the scans in configurations 2 and 3, please tell us, that alone answers the question, and the risk is much smaller than we assumed.
  • If it accepts them and you can save all 24, please send us those .mxf files. We can then compare the readings with your 4 × 6 file and see straight away whether any reading sits on the wrong patch.

Thanks again for your time!
 
@jctay thank you, that was a good find, and your numbers made it easy to follow. Yes, there is a clear pattern, and it is all i1Profiler's own layout rule:

  • Columns: i1Profiler puts as many patches across as the paper width allows. It needs 31 mm of margin plus the patches, so with 8.5 mm patches 12 columns need 133.0 mm and 13 columns need 141.5 mm (31 + 13 x 8.5). That is exactly your 141.4 / 141.5 switch. It also cuts anything you type down to 0.1 mm, so 141.49 still counts as 141.4.
  • Rows and pages: the paper height must hold 35 mm plus the rows, rounded up to a whole millimetre: 171 mm for 16 rows, 163 mm for 15 rows. That is your 170.9 / 171.0 switch, and it is why rounding to whole numbers shows the pattern. The "Size: 13.3 x 17.1 cm" in the chart header is exactly that smallest page.
  • Rows 9 to 16 are not missing: when the rows do not fit, i1Profiler uses as few pages as it can and shares the rows out evenly, so 16 rows become 8 + 8. Your screenshot says "Page 1 of 2", and rows 9 to 16 are on page 2. A slightly smaller page that would hold 10 rows still gives 8 + 8.

Does this affect ChromIQ's charts? No. ChromIQ never sets the paper width on one of these switch points. For your chart the .txf asks for 137.25 mm, which is in the middle between 133.0 (12 columns) and 141.5 (13 columns), so there are more than 4 mm of room either way. The paper height is 210 mm, far more than the 171 mm needed. Your .txf files are not outdated: ChromIQ 4.3.30 writes exactly the same settings for your chart. We also checked about 28,000 other chart sizes, and none ends up close enough to a switch point for rounding to change the column count.

If the paper size is changed in i1Profiler and it ends up with 13 columns, the import of that measurement is refused with a message about the grid, so a wrong grid cannot slip into a profile. Spreading the same 12 columns over two pages is fine and is accepted.

One correction to an earlier post of mine: I wrote that i1Profiler chooses the rows first. It is really the other way round: it takes as many columns as the paper width allows, then the rows it needs, and then evens out the columns. For 24 patches on 2 rows that still gives 12 columns, so the example stays true.

Your test plan
Yes, that is the test, thank you for writing it out so carefully. Just two small changes, and a little background.

Two small changes
  • Please export the .txf after you have generated the chart with the spacers you will print (Black & White or Coloured), from that same chart. Then the file and the printed sheet are sure to belong together. Changing the spacers after the export changes the layout of the sheet, and the strips could end up different from what the .txf describes.
  • Configuration 1 (4 × 6 kept as it is) is the check that everything works. The interesting ones are 2 and 3, and there the most useful thing is not the saved file but what i1Profiler does at the moment you scan: when it shows rows of 5 (or 12) and you scan one printed strip of 6, does it accept the scan, refuse it, or ask you to scan again? A screenshot or the exact wording of any message would help a lot.

Why this is different from your earlier files
Your earlier files were measured once, on the right grid, and only saved again afterwards under other page layouts. i1Profiler then moved the finished readings to the new pages correctly, so they were all fine. This time the grid is wrong while you measure, so i1Profiler has to decide where the scanned patches go. That is the one case ChromIQ's grid check is meant for, and the one we cannot test ourselves without a printer and an instrument.

About the complete file
You were clear, and I understand: i1Profiler only saves an .mxf when all 24 patches have a reading. That is exactly what worries us. If i1Profiler accepts a strip of 6 into a row of 5, the file can still end up with 24 readings, complete and saveable, but with some readings on the wrong patches. So:
  • If i1Profiler refuses the scans in configurations 2 and 3, please tell us, that alone answers the question, and the risk is much smaller than we assumed.
  • If it accepts them and you can save all 24, please send us those .mxf files. We can then compare the readings with your 4 × 6 file and see straight away whether any reading sits on the wrong patch.

Thanks again for your time!
Well explained. Thank you for the clarification.

Work flow:
""
1. Import the .txf file and retain the original 4 × 6 layout.
2. Import the .txf file and change the layout to 5 × 5.
3. Import the .txf file and change the layout to 12 × 2.
Each measurement should contain all 24 patches in the resulting .mxf file.""

Sorry, I just realized that Steps 2 and 3 in my workflow are obviously not feasible. I believe you understand why.
 
After I dropped a hint to ChatGPT:
"You're right. You cannot perform actual measurements in 5 × 5 or 12 × 2 layouts without corresponding physical printouts."


Gemin:
"If testing alternative grid layouts (like 12 × 2), you must generate a target layout natively built for 12 columns and 2 rows from the start, rather than trying to remap a 6 × 4 target post-export".


Claude:
"Why 5×5 and 12×2 fail: the layout is fixed once ChromIQ prints the chart. Changing the layout in i1Profiler only changes what i1Profiler expects to read. It doesn’t change the paper."
 
My main question is: Does ChromIQ provide a way to compare two sets of spectral measurements to evaluate measurement repeatability and consistency?
Hi @jctay ,
I imagine that several of the metrics that are calculated from measurements of a verification run when using the Measurement Report tool could be used as measures for repeatability and consistency.

One could ask claude which of the metrics would qualify best for this purpose.

All the metrics used are found under
Preferences --> Reports tab --> "Report Limits..." button:
1794354258897.png


Specifically, you have the two metrics under the heading "Repeatability, Measured by ChromIQ":
1794354379836.png

The first one "Maximum dE00, repeat patches on on sheet" does look at patches that are the same on a verification chart measured. The help info also gives a description of what you can do to measure this, i.e. to make sure the test chart measured have repeat patches of the same color:
1794354539822.png


However, I believe the other average and maximum metrics below also give an indicator of accuracy and repeatability, although these are across all patches of a chart measured, but still give valuable information:
1794354716700.png


Is this what you were looking for? or did you have another idea?

Cheers,
Knut
 
Last edited:
Hi @jctay ,
I imagine that several of the metrics that are calculated from measurements of a verification run when using the Measurement Report tool could be used as measures for repeatability and consistency.

One could ask claude which of the metrics would qualify best for this purpose.

All the metrics used are found under
Preferences --> Reports tab --> "Report Limits..." button:
View attachment 19871

Specifically, you have the two metrics under the heading "Repeatability, Measured by ChromIQ":
View attachment 19872
The first one "Maximum dE00, repeat patches on on sheet" does look at patches that are the same on a verification chart measured. The help info also gives a description of what you can do to measure this, i.e. to make sure the test chart measured have repeat patches of the same color:
View attachment 19873

However, I believe the other average and maximum metrics below also give an indicator of accuracy and repeatability, although these are across all patches of a chart measured, but still give valuable information:
View attachment 19874

Is this what you were looking for? or did you have another idea?

Cheers,
Knut
Thank you.

Measurement Repeatability Assessment

Just throwing my two cents in.

Several names have been proposed, such as:
- Replicate measurement check
- Scan-to-scan repeatability check


Claude offers a straightforward, practical approach that aligns perfectly with what I had in mind.
- Export both color sets as CGATS files.
- Calculate the ΔE00 color difference for each patch between Set A and Set B.
- Use BabelColor PatchTool by selecting its Compare function to perform the analysis.

Flag the outliers
- A fixed threshold, e.g. ΔE00 > 1.0 for a scanned i1Pro chart.
- If your paper and instrument are very consistent, you can tighten it to about 0.5.

Decide which set is wrong
Two sets only tell you where they disagree, not which one is correct. Take a third reading of the flagged patches and keep the two that agree. Or, for a smooth ramp, judge which value fits its neighbours.
 
@jctay you are right, and thank you for pointing it out. Once a chart is printed, its layout is fixed on the paper, so measuring it on a 5 × 5 or 12 × 2 grid in i1Profiler could not work the way I had described it. Sorry for the detour, and thanks for thinking it through so carefully.

ChromIQ 4.3.31 is out today, and two things in it came straight from your posts: your re-saved i1Profiler files now import, and your idea of comparing readings is built in.
Download: https://github.com/itsab1989/ChromIQ/releases/tag/v4.3.31

1. Re-saved i1Profiler files are now checked by their colours
When a turned i1Profiler measurement was saved on a different grid from the one the how-to note asks for, ChromIQ no longer refuses it for that alone. It compares the colours the instrument measured with the colours your chart should have on every patch:
  • If they clearly match, the measurement is imported, and a message tells you that the grid in i1Profiler had changed and that the colours were checked.
  • If they clearly do not match, or ChromIQ cannot tell (for example on a small chart, a chart whose patches are sorted by colour, or one made of very similar colours), the file is refused as before. The message says which of the two it was, and how to fix it without measuring again.
Your own files now pass: the ColorChecker 24 saved on the other grids, and the 624-patch chart saved on 18 and 52 pages, import with exactly the same values as the file saved on the right grid. There is no setting to switch on and no "accept anyway" button.

To be honest about the limit: this checks that the readings belong to the patches as a whole. A local slip inside one strip can still get through, exactly as it can on the correct grid.

2. Your repeatability idea: "Other readings"
Open Tools > Inspect a measurement (the Measurement info window). Under Other readings you can now add one or several other readings of the same chart, up to nine: ChromIQ .ti3 files, CGATS text files, or i1Profiler files (.mxf, .cxf and the CGATS text exports, also with decimal commas). ChromIQ first checks that the files really hold the same chart, and refuses a file of another chart instead of comparing the wrong patches. Then it shows:
  • the average, median, 95th percentile and largest ΔE00 between the readings;
  • a tolerance you choose (0.5, 1.0, 2.0 or your own value), with the number of patches above it;
  • the patches with the largest differences, and a summary for every strip, so a strip that slipped stands out;
  • with three or more readings: a repeatability figure, the reading that stands apart when one clearly does (all the others agree within your tolerance), or that the readings fall into groups.
The same reading added twice is refused, so one file cannot outvote the others. And just as you said about taking a third reading: a reading that stands apart is strong evidence, but not proof, because two readings can share an error. The window says so too. It never changes a file or a profile.

Knut's pointer to the Measurement Report rows is still the right tool for watching a printer over time. This new one is for comparing readings of one chart directly.

This example uses the ET-18100 files that pharmacist shared earlier in this thread (post #143), read once in ChromIQ (target_v2.ti3) and once in i1Profiler (target.mxf, M0): 698 patches compared, average 0.32, largest 0.98, none above 1.0.
pic1_double-read.png


And an example with four readings of one of our own charts, where we slipped strip H in reading 3 on purpose. ChromIQ names reading 3, and strip H in it, as the one to read again:
pic2_four-readings-stands-apart.png


The strip summary, and what the window tells you about it:
pic3_by-strip-what-this-tells-you.png


When the readings split two against two (here two of them were changed to look like a second instrument), it does not pick a winner but says that they fall into groups:
pic4_groups.png


3. A note on pharmacist's ET-18100 files
@pharmacist, thank you for sharing these files. They were a great help for testing. As you explained when you shared them, the older target.ti3 is your i1Profiler measurement target.mxf, imported into ChromIQ 4.3.19 and converted, so both hold the same data, while the two v2 files are independent measurements. jctay then worked out that the conversion used M2 (post #144). Our check agrees: target.ti3 differs from the M2 reading in target.mxf by about 0.06 ΔE00 on average, and from the M0 reading by about 1.0. What we would add is that the .ti3 itself does not say under which condition it was made. The other ET-18100 files (target_v2.ti3 and the M0 readings in both .mxf files) agree with each other within about 0.3 on average, and target.ti3 is about 1.0 away from each of them. So next to them it is the one that stands apart, purely because of the measurement condition, and not because anything went wrong.

That is why the window now has a Measurement condition row, which tells you when a file does not name its condition (you can see it in the first picture, because target_v2.ti3 does not name one either), and why readings are best compared under the same condition.

Also in 4.3.31
i1Profiler CGATS text exports written with decimal commas (on a computer set to German, for example) are now imported as well, by the same rule as the .mxf files in 4.3.29. Plus a few fixes, see the release notes.

It would be great if you could try both with your files and tell me what you see.

Thanks again!

Edit: an earlier version of this post called the ET-18100 files jctay's. They are pharmacist's (post linked above). Sorry to both of you for the mix-up.
 
Last edited:
@jctay you are right, and thank you for pointing it out. Once a chart is printed, its layout is fixed on the paper, so measuring it on a 5 × 5 or 12 × 2 grid in i1Profiler could not work the way I had described it. Sorry for the detour, and thanks for thinking it through so carefully.

ChromIQ 4.3.31 is out today, and two things in it came straight from your posts: your re-saved i1Profiler files now import, and your idea of comparing readings is built in.
Download: https://github.com/itsab1989/ChromIQ/releases/tag/v4.3.31

1. Re-saved i1Profiler files are now checked by their colours
When a turned i1Profiler measurement was saved on a different grid from the one the how-to note asks for, ChromIQ no longer refuses it for that alone. It compares the colours the instrument measured with the colours your chart should have on every patch:
  • If they clearly match, the measurement is imported, and a message tells you that the grid in i1Profiler had changed and that the colours were checked.
  • If they clearly do not match, or ChromIQ cannot tell (for example on a small chart, a chart whose patches are sorted by colour, or one made of very similar colours), the file is refused as before. The message says which of the two it was, and how to fix it without measuring again.
Your own files now pass: the ColorChecker 24 saved on the other grids, and the 624-patch chart saved on 18 and 52 pages, import with exactly the same values as the file saved on the right grid. There is no setting to switch on and no "accept anyway" button.

To be honest about the limit: this checks that the readings belong to the patches as a whole. A local slip inside one strip can still get through, exactly as it can on the correct grid.

2. Your repeatability idea: "Other readings"
Open Tools > Inspect a measurement (the Measurement info window). Under Other readings you can now add one or several other readings of the same chart, up to nine: ChromIQ .ti3 files, CGATS text files, or i1Profiler files (.mxf, .cxf and the CGATS text exports, also with decimal commas). ChromIQ first checks that the files really hold the same chart, and refuses a file of another chart instead of comparing the wrong patches. Then it shows:
  • the average, median, 95th percentile and largest ΔE00 between the readings;
  • a tolerance you choose (0.5, 1.0, 2.0 or your own value), with the number of patches above it;
  • the patches with the largest differences, and a summary for every strip, so a strip that slipped stands out;
  • with three or more readings: a repeatability figure, the reading that stands apart when one clearly does (all the others agree within your tolerance), or that the readings fall into groups.
The same reading added twice is refused, so one file cannot outvote the others. And just as you said about taking a third reading: a reading that stands apart is strong evidence, but not proof, because two readings can share an error. The window says so too. It never changes a file or a profile.

Knut's pointer to the Measurement Report rows is still the right tool for watching a printer over time. This new one is for comparing readings of one chart directly.

This example uses the ET-18100 files that pharmacist shared earlier in this thread (post #143), read once in ChromIQ (target_v2.ti3) and once in i1Profiler (target.mxf, M0): 698 patches compared, average 0.32, largest 0.98, none above 1.0.
View attachment 19875

And an example with four readings of one of our own charts, where we slipped strip H in reading 3 on purpose. ChromIQ names reading 3, and strip H in it, as the one to read again:
View attachment 19876

The strip summary, and what the window tells you about it:
View attachment 19877

When the readings split two against two (here two of them were changed to look like a second instrument), it does not pick a winner but says that they fall into groups:
View attachment 19878

3. A note on pharmacist's ET-18100 files
@pharmacist, thank you for sharing these files. They were a great help for testing. As you explained when you shared them, the older target.ti3 is your i1Profiler measurement target.mxf, imported into ChromIQ 4.3.19 and converted, so both hold the same data, while the two v2 files are independent measurements. jctay then worked out that the conversion used M2 (post #144). Our check agrees: target.ti3 differs from the M2 reading in target.mxf by about 0.06 ΔE00 on average, and from the M0 reading by about 1.0. What we would add is that the .ti3 itself does not say under which condition it was made. The other ET-18100 files (target_v2.ti3 and the M0 readings in both .mxf files) agree with each other within about 0.3 on average, and target.ti3 is about 1.0 away from each of them. So next to them it is the one that stands apart, purely because of the measurement condition, and not because anything went wrong.

That is why the window now has a Measurement condition row, which tells you when a file does not name its condition (you can see it in the first picture, because target_v2.ti3 does not name one either), and why readings are best compared under the same condition.

Also in 4.3.31
i1Profiler CGATS text exports written with decimal commas (on a computer set to German, for example) are now imported as well, by the same rule as the .mxf files in 4.3.29. Plus a few fixes, see the release notes.

It would be great if you could try both with your files and tell me what you see.

Thanks again!

Edit: an earlier version of this post called the ET-18100 files jctay's. They are pharmacist's (post linked above). Sorry to both of you for the mix-up.

Thank you so much for your hard work — your ongoing dedication is truly making a difference.

The new function is a solid starting point.

By the way, would it be possible to add drag-and-drop for selecting files?


I definitely recommend gathering input from other sources as well, since my experience might not reflect the typical user's.


First, regarding the measurement issues with ChromIQ...

i1Pro2/3 Scanning ruler Positioning sensor - Linear scale - Zebra strip

[Information gathered from the Internet]

Positioning sensor vs Patch Boundaries detection:
When chartread scans a strip, it determines the patch boundaries from the measurement readings themselves. The instrument takes multiple readings and distributes them among the individual patches. It then checks their consistency and rejects measurements that are considered too inconsistent.
The ruler's position tracking plays no part in this process. This explains why chartread warns that "Moving the instrument too fast or changing speeds may cause a mis-read."

By contrast, a position-driven scanning system would be much less sensitive to scanning speed, as is the case with i1Profiler.

That is definitely worth exploring.



Just a heads-up, I'm planning to spend some time testing out Scanner and Camera Profiling.
 
Back
Top