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

[jctay]

Project: CP1500-600p

I copied CP1500-600p-i1profiler-turned-i1Pro3.txf from the ChromIQ Exports folder to i1Profiler, printed the corresponding target chart, and then measured it using i1Profiler.

CP1500-600p-turned-i1Pro3.mxf
CHROMIQ_I1P_GRID "columns=12 rows=50 pages=1 patches=600 located=600 misplaced=0"

Next, I adjusted the paper media dimensions and split the measurement chart across five pages.

CP1500-600p-turned-i1Pro3A.mxf
CHROMIQ_I1P_GRID "columns=12 rows=10 pages=5 patches=600 located=600 misplaced=0"

The issue is as follows:
I am unable to import CP1500-600p-turned-i1Pro3A.mxf into ChromIQ Measurement.
However, CP1500-600p-turned-i1Pro3.mxf imports without any issues.

Ask AI:
Refer to Warning-CP1500-600p-turned-i1Pro3A.png. ChromIQ does not accept CP1500-600p-turned-i1Pro3A.mxf. I believe the resulting layouts from both files should be identical.

AI reply:
Yes, both .ti3 files are correct. Every patch carries the right RGB and the right measurement, so either one is fine for building a profile. They differ only in patch order and location labels.

How I checked: I worked out XYZ from each patch’s spectrum in the .mxf (D50, 2° observer) and matched every .ti3 row back to its patch. I then compared the .ti3 RGB with the RGB i1Profiler stored for that same page, row and column.

i1Pro3 (1 page, 12×50)
i1Pro3A (5 pages, 12×10)

Where they differ:
i1Pro3: ChromIQ re-sorted this file into its own chart order (sample 1 is RGB 0,0,0) using CP1500-600p-i1profiler-turned.json. The SAMPLE_LOC labels give the printed position, with the 12 columns counted in mirror order to match the turned print. For example, “AN8” is row 14, column 5 in i1Profiler’s grid. That’s consistent across all 600 patches.
i1Pro3A: This one stays in i1Profiler’s own order, with plain labels “1” to “600”. It has no turned-order pairing, so the reorder seems to have been applied only to the single-page file.


The same RGB values in the two files differ by at most 0.83 in XYZ (average about 0.1). That’s normal variation between two measuring runs, so both files describe the same chart.

ChromIQ took the M2 data. The .mxf files also contain M0 and M1, so if you meant to use M0, that’s a ChromIQ setting to change, not a fault in either file.

This doesn’t explain why both .mxf files fail to convert. Do you want me to run the converter on them next and find where it breaks?


You’re right: the two layouts are the same. The 5-page file is the single-page chart cut into five stacks of 10 rows. Page 1 is rows 1–10, page 2 is rows 11–20, and so on, with the same 12 columns throughout. So ChromIQ’s warning is too cautious for this file.

What I checked, joining the pages back up (row = (page − 1) × 10 + row on that page):

RGB: all 600 RGB values in the 5-page file match the single-page file at the same position.
Measurements: they agree with your single-page run to within 0.1 XYZ on average, and 0.83 at most (on a near-white patch). That’s normal variation between two runs of the same sheet.
Page order: if pages 2 and 3 had been read out of order, the readings would be off by about 12 XYZ on average. So the data does show you carried on down the sheet in order, even though ChromIQ says nothing in the file can show that.

Fix for ChromIQ: when the column count matches and rows per page × pages equals the expected 50 rows, join the pages using that formula instead of refusing the file. To guard against a wrong strip or page order, the readings should be checked against a trusted measurement of the same sheet. A single-page file can have the same reading mistakes, so this isn’t a risk peculiar to paged charts.

New file: I wrote CP1500-600p-turned-i1Pro3A-ChromIQ-joined.ti3 to your folder. It has the 5-page readings in exactly the same order and with the same labels as CP1500-600p-turned-i1Pro3-ChromIQ.ti3 (sample 1 = “AN8”, RGB 0,0,0, and so on). The two files now differ only in the XYZ readings and the grid line in the header. I didn’t touch your existing files.

Your existing CP1500-600p-turned-i1Pro3A-ChromIQ.ti3 wasn’t run through the turned-chart reordering. It’s in i1Profiler’s order with plain “1”–“600” labels, which is why its layout differed from the single-page file.

 

[jctay]

1-page vs 5-page

 

[itsab1989]

@jctay thank you for measuring the same sheet twice, once on one page and once on five, and for the screenshots of i1Profiler's rows. That made it easy to check, and you were right: ChromIQ refused your 5-page measurement wrongly.

What we found in your two files

• Both have the same 12 columns. In the 5-page file, i1Profiler shared the 50 rows out over 5 pages of 10.
• Inside the file, i1Profiler starts the row numbers again at 0 on every page. On screen it carries on counting ("row 11 on page 2", as your screenshots show), and the rows on earlier pages plus the row on the page give exactly the same place as in your 1-page file.
• Counted that way, every one of the 600 patches sits in the same cell as in the 1-page file, with the same RGB values.
• The readings of your two runs differ by 0.1 XYZ on average and 0.83 at most, which is normal between two readings of the same sheet. As a check, swapping pages 2 and 3 would have made them differ by about 12 on average.

What was wrong
ChromIQ's message said that i1Profiler numbered its rows page by page, starting again at row 1, so the rows it showed would not match the strips on the sheet. That was not true: i1Profiler counts on from page to page, and every row is still one strip of the printed sheet. I also wrote in my 4.3.19 post that a chart cut over several pages gets refused because of this. I'm sorry, that was wrong too.

What ChromIQ 4.3.21 does

• It imports such a measurement and files it exactly like the 1-page one: the same patch order, the same patch names, the same RGB values. Your real 5-page file imports, and all 600 patches are filed in the same order, with the same names and RGB values, as in your 1-page import; only the readings differ, as they should between two runs.
• It reads how many rows are on each page from the file itself, so it does not matter how i1Profiler shares the rows out.
• It still refuses a file with another number of columns, or with any patch that is not in its place when the rows are counted on across the pages. The message then says what is wrong and what to do.
• Step 5 of the how-to note now says that i1Profiler may spread the rows over several pages, that this is fine as long as it keeps the columns and the patch width, and that you simply carry on down the same sheet.

Download: https://github.com/itsab1989/ChromIQ/releases/tag/v4.3.21

Until you update, your 1-page measurement is the one to use. Thanks again for the careful testing!

 

[jctay]

@jctay thank you for measuring the same sheet twice, once on one page and once on five, and for the screenshots of i1Profiler's rows. That made it easy to check, and you were right: ChromIQ refused your 5-page measurement wrongly.

What we found in your two files

• Both have the same 12 columns. In the 5-page file, i1Profiler shared the 50 rows out over 5 pages of 10.
• Inside the file, i1Profiler starts the row numbers again at 0 on every page. On screen it carries on counting ("row 11 on page 2", as your screenshots show), and the rows on earlier pages plus the row on the page give exactly the same place as in your 1-page file.
• Counted that way, every one of the 600 patches sits in the same cell as in the 1-page file, with the same RGB values.
• The readings of your two runs differ by 0.1 XYZ on average and 0.83 at most, which is normal between two readings of the same sheet. As a check, swapping pages 2 and 3 would have made them differ by about 12 on average.

What was wrong
ChromIQ's message said that i1Profiler numbered its rows page by page, starting again at row 1, so the rows it showed would not match the strips on the sheet. That was not true: i1Profiler counts on from page to page, and every row is still one strip of the printed sheet. I also wrote in my 4.3.19 post that a chart cut over several pages gets refused because of this. I'm sorry, that was wrong too.

What ChromIQ 4.3.21 does

• It imports such a measurement and files it exactly like the 1-page one: the same patch order, the same patch names, the same RGB values. Your real 5-page file imports, and all 600 patches are filed in the same order, with the same names and RGB values, as in your 1-page import; only the readings differ, as they should between two runs.
• It reads how many rows are on each page from the file itself, so it does not matter how i1Profiler shares the rows out.
• It still refuses a file with another number of columns, or with any patch that is not in its place when the rows are counted on across the pages. The message then says what is wrong and what to do.
• Step 5 of the how-to note now says that i1Profiler may spread the rows over several pages, that this is fine as long as it keeps the columns and the patch width, and that you simply carry on down the same sheet.

Download: https://github.com/itsab1989/ChromIQ/releases/tag/v4.3.21

Until you update, your 1-page measurement is the one to use. Thanks again for the careful testing!

Thank you.


ChromIQ-Windows-x64_v4.3.21 fixed it!

 

[jctay]

mxf_ti3_RoundTrip Converter

Standard vs. Full Conversion
MXF files converted from TI3 using a standard conversion are incompatible with i1Profiler. To work properly, you must use a Full conversion, as i1Profiler requires spectral data to be embedded in the MXF file.

TI3: STD vs Full

mxf_ti3_RoundTrip Converter

ZIP

Files converted via the ChromIQ Toolbox i1Profiler TI3 converter:
CP1500-600p-turned-i1Pro3(ChromIQ).ti3
CP1500-600p-turned-i1Pro3A(ChromIQ).ti3

Files converted with mxf_ti3_RoundTrip converter:
CP1500-600p-turned-i1Pro3-ti3_M0.ti3
CP1500-600p-turned-i1Pro3-ti3_M1.ti3
CP1500-600p-turned-i1Pro3-ti3_M2.ti3