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

 

[jctay]

mxf_ti3_RoundTrip - v1.2.0


Version 1.2.0 – Chart Settings Preservation

The i1Profiler chart-settings block (xrp:CustomAttributes) is now carried through the round trip.

Previously, .ti3 → .mxf always wrote fixed default values (e.g. MeasurementMode 1, LockWriteProtection True, page size 150 × 100 mm, portrait orientation, and 12 mm patches), regardless of the settings in the source .mxf.

Now, .mxf → .ti3 stores every setting as an MXF_ATTR_ keyword, and .ti3 → .mxf writes them back unchanged, except for the condition and layout values listed above.

The resulting .mxf is also read back to verify that the entire settings block is complete.

The patch sequence and layout are consistent with ChromIQ specifications.

 

[itsab1989]

@jctay thank you for the side-by-side comparison and for attaching both .mxf files with your converter's output. That made it quick to check, and it led to several improvements in ChromIQ 4.3.23.

Why the numbers differ

• Your .mxf holds every patch three times, as spectra measured under M0, M1 and M2, and no ready-made XYZ. Every converter has to choose one condition and work out XYZ itself.
• ChromIQ always took M2 (UV cut) and worked out XYZ with D50 and the 2° observer. Compared with your M2 file, ChromIQ's values agree to about 0.05 ΔE76 on average (0.09 at most), with the same patch order and identical RGB values.
• Your screenshot compares ChromIQ with your M1 file, which is a different condition. On your paper, M1 and M2 differ by about 4.4 ΔE76 on average and up to about 10, because of the optical brighteners. So ChromIQ's numbers were correct M2 values, not wrong ones.
• About the AI answer in your earlier post: there was no ChromIQ setting to choose M0 or M1 for an import. ChromIQ simply took M2.

You were right about the rest
ChromIQ didn't record which condition it used, dropped the spectra (so brightener compensation, other illuminants and merging with a chartread measurement weren't possible), and wrote i1Profiler's instrument name, which ArgyllCMS doesn't recognise.

What ChromIQ 4.3.23 does

• It asks. When an i1Profiler file holds more than one condition, ChromIQ asks which one to import (M0, M1 or M2), with a short explanation of each. M1 is preselected unless the file clearly names the condition chosen in i1Profiler.
• It records the condition in the .ti3 (MEASUREMENT_CONDITION), as your converter does.
• It keeps the spectra of the chosen condition, so the illuminant and observer options in Build Profile work for imports, and an import can be merged with a chartread measurement of the same condition.
• It writes ArgyllCMS's instrument name (for example "X-Rite i1 Pro 3") and keeps i1Profiler's own name in a separate keyword.
• Brightener compensation (FWA) only for M0 data. ArgyllCMS's FWA model assumes the instrument's own M0 lamp, so for M1 and M2 data the option is greyed, with the reason in its tooltip. M1 already contains the brighteners' effect as it looks in D50 daylight.
• Conditions are not mixed by accident. A measurement made in ChromIQ's Measure tab with the -F filter set now records its condition too. Merging or averaging two measurements with different recorded conditions is refused with an explanation, and when one is M1 or M2 and the other doesn't record its condition, ChromIQ asks before combining them.
• i1Profiler's .txt export can name its condition in its header ("Filter=..."), and ChromIQ now reads it when it is there.

About your converter
Its XYZ values match ArgyllCMS's own spec2cie to about 0.001 ΔE, which is very nice. ChromIQ's own calculation stays about 0.05 ΔE away from that because it samples the colour matching functions at 10 nm. That is far below the difference between two readings of the same sheet, so we left it as it is for now.

One request, if you have two minutes
Could you save the same i1Profiler measurement three times, once each with M0, M1 and M2 selected as the measurement condition, and attach the three .mxf files? Your files say SelectedMeasurementCondition="0", and we don't want to guess how i1Profiler numbers its choice. With those three files, ChromIQ can preselect the condition you chose in i1Profiler.

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

Thanks again for the careful testing!