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

[itsab1989]

@jctay thank you for the three files saved with M0, M1 and M2 selected, and for the set with only some of the conditions. They answered exactly what we needed, and ChromIQ 4.3.24 uses them:

• ChromIQ now preselects the condition you chose in i1Profiler. Your files show that SelectedMeasurementCondition "0", "1" and "2" mean M0, M1 and M2, also in the files that hold only some conditions (the M1+M2 file says "1", the M2-only file says "2"). The import window still lets you choose another condition, and it says that the preselected one is the one chosen in i1Profiler.
• Files with only some conditions import correctly. A file with one condition is imported without a question, and the log says which condition it was. A file with two offers only those two.
• XYZ is now worked out exactly as ArgyllCMS does it. You were right that your converter was closer to ArgyllCMS's spec2cie than ChromIQ's import. Small things add up, so ChromIQ now uses ArgyllCMS's method (1 nm steps, its interpolation and its tables). On your 600 patches the difference to spec2cie went from about 0.05 ΔE76 on average (0.1 at most) to 0.00002 (0.00008 at most), for M0, M1 and M2. Measurements already imported keep their numbers; only new imports use the new method.
• While checking this we found the same kind of shortcut in a few other places and fixed them too: Build Profile with ChromIQ's own profile engine when another illuminant or observer is chosen (with the fluorescent illuminants F5, F8 and F10 it was off by several ΔE), the Measurement info window for files that hold only spectra, and new CR30 and FD-9 readings.
• A broken file is refused with an explanation. If a spectrum holds a value that isn't a number, ChromIQ now names the patch by page, row and column instead of writing "nan" into the measurement.

Thanks also for fixing your RoundTrip tool for charts wider than 26 columns.

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

Thanks again for the careful testing!

 

[jctay]

.pxf file (ChromIQ exports folder)

Severity: Low (if importing to i1Profiler only)

ChromIQ Export Folder (causes errors when imported into PatchTool):
- Project-TI2-i1profiler.pxf

Converted via Alternative Method (successfully imports into PatchTool):
-Project-TI2-txf.txf

Left image is Project-TI2-i1profiler.pxf

 

[itsab1989]

I have used up 90% of my token for this week already. So since this does not seem to be very urgent I will let it wait for a few days.

 

[jctay]

Comparing Chart Conversion Strategies: Physical Chart Rotation vs. Sequential Patch Reordering

A Comparison of Two Methods for Importing and Exporting Color Patch Data Between ChromIQ and i1Profiler:

(I) ChromIQ Method – 90-Degree Chart Rotation

(II) Sequential Patch Reordering


90-Degree Rotation Approach:
Converts the chart layout by rotating the original ArgyllCMS chart through 90 degrees to accommodate i1Profiler's measurement orientation.

Sequential Patch Reordering:
Re-organizes the color patches according to their measurement sequence, rather than relying on physical chart rotation. This provides a more direct way of mapping patch positions between the two chart layouts.


Which Approach Is More Logical and Systematic?

I'd appreciate your thoughts and feedback.


/edit: Title

 

[jctay]

Case Study: Physical Chart Rotation vs. Sequential Patch Reordering

[AI assisted]
Consider a chart containing 193 patches (a prime number)
- If the layout uses a rectangular grid, 193 cannot be divided evenly into rows and columns (other than 1 × 193).
- A 90-degree rotation changes the orientation but does not solve the underlying grid arrangement problem.
- You may need to introduce empty positions, spacers or special handling to accommodate the layout.

By contrast, your Sequential Order Approach does not depend on the patch count being divisible into a regular rectangular grid. It can handle 193, 197, 199 or any other patch count, provided the mapping preserves patch identity and measurement sequence.

- Sequential reordering is inherently more flexible when dealing with arbitrary patch counts, particularly prime numbers.

It could certainly be argued that 193 patches are neither a conventional nor an appropriate choice for printer profiling

However, I think that argument misses the point of your comparison.

There are two separate issues:
1. Profiling requirements: Whether 193 patches provide sufficient color coverage and accuracy for generating a reliable ICC profile.
2. Chart conversion capability: Whether a conversion method can correctly handle an arbitrary number of color patches while preserving patch identity, RGB values and measurement sequence.
Even if 193 patches are not recommended for profiling, that does not invalidate their use as a test case for evaluating chart conversion methods.

[AI] My recommendation
I would retain the prime-number example.

It is a useful way to demonstrate the fundamental difference:
- 90-degree rotation: More dependent on chart geometry and layout constraints.
- Sequential reordering: Independent of rectangular grid dimensions and more adaptable to arbitrary patch counts.
The objective is not to prove that 193 patches make a better ICC profile. It is to demonstrate which conversion method offers greater flexibility and a more systematic approach.

 

[jctay]

Should Negative RGB Values Be Preserved in Color Profiling Tools?

Project: ColorCheck24-test1

Negative RGB values can occur when converting colors from a device color space into a smaller color space, where certain out-of-gamut colors cannot be represented within the target gamut. These values may fall below the nominal 0–255 range in an 8-bit representation.

I suspect that most profiling applications simply clamp negative RGB values to zero, potentially losing information about out-of-gamut colors.

Untagged TIFF images intended for NCM (Non-Color-Managed) workflows may also have compatibility issues with negative RGB values, as conventional 8-bit RGB image data cannot directly represent them.

My opinion: Negative RGB values should ideally be preserved, with appropriate considerations when comparing patch layouts and identifying layout discrepancies.


ChromIQ applies a very strict validation procedure when importing measurement data.

Left: .ti2
Right: .ti3 from .mxf with Sequential Patch Reordering approach

SampleID 13 has a negative RGB value because the ColorChecker 24 chart was derived directly from the original device values. Such a situation would not normally arise in ChromIQ's standard profiling workflow. I would like to emphasise that this was not intentional but simply a consequence of using the original device values.

I am evaluating a workflow based on the Sequential Patch Reordering approach, with direct output in .ti3 format.

Be aware that when converting the supplied .mxf file directly through ChromIQ, an additional layout orientation adjustment is required to match the original .ti2 layout.

ZIP
ColorCheck24-test1.ti2 ( ChromIQ)
ColorCheck24-test1.png (ChromIQ)
ColorCheck24-test1.mxf (i1Profiler, with Sequential Patch Reordering approach)
ColorCheck24-test1-M1.ti3 (.mxf to .ti3 with Sequential Patch Reordering converter)
ColorCheck24-test1-M1(byChromIQ).ti3 (convert .mxf to .ti3 with ChromIQ converter, for reference only)

 

[jctay]

Should Negative RGB Values Be Preserved in Colour Profiling Tools? -- Part 2

My Opinion

I would suggest allowing ChromIQ to pass the validation check in this particular case, and I have a good reason for doing so.

When the .ti2 file is sent to i1Profiler, the profiling application simply clamps negative RGB values to zero.

Similarly, when the .ti3 file is imported into the ChromIQ profiling engine, negative RGB values are also clamped to zero.

The end result is that both cases, RGB= (-0.00000 52.15690 64.70590) or RGB= (-23.13730 52.15690 64.70590), produce identical profiles.

 

[itsab1989]

@jctay thank you for the three findings and the files. ChromIQ 4.3.26 is out with what came of them: https://github.com/itsab1989/ChromIQ/releases/tag/v4.3.26

1. The .pxf that PatchTool refused: a real bug, fixed.
Every patch in ChromIQ's RGB .pxf referred to a colour specification called "Unknown" that the file never defined. i1Profiler doesn't mind, but it makes the file invalid CxF3. We installed PatchTool 7.2.0 and reproduced your error exactly: its log says "A referenced <ColorSpecification> element was not found". With the fix, PatchTool imports the same patch set without any error, and i1Profiler still loads both. X-Rite's own RGB patch sets contain that definition too, so ChromIQ now writes them the same way. The CMYK files were already fine.

2. Turning the sheet vs. reordering the patches: ChromIQ already does the reordering.
ChromIQ's turned i1Profiler export writes the patches in measuring order, so that each row in i1Profiler is one strip on the sheet. "Turning" just describes how i1Profiler's screen lines up with the paper. Odd and prime patch counts are no problem: ChromIQ fills the last strip with paper-white patches, so the grid is always complete. We tested 7, 23, 191, 193 and 601 patches, and every reading came back onto its own patch.
You were right about your ColorCheck24 files: an .mxf made from a list that was reordered by another tool can't be mapped back by ChromIQ, because the file carries no ChromIQ patch numbers. ChromIQ refuses such an import rather than guessing and filing readings on the wrong patches. The refusal now says what to do instead: use ChromIQ's own i1Profiler export (normal or turned), which maps back by itself.

3. Negative RGB values: you were right that they shouldn't block you, but "just let them pass" would not be safe.
We checked what each part does with your −23.14:

• ChromIQ's own chart image and the i1Profiler exports print and write 0.
• ArgyllCMS's printtarg (used when the layout engine is off) wraps the value round and prints 196 of 255 instead of 0.
• ArgyllCMS's colprof uses −23.14 as it is, so the profile differs from one built with 0.

So 4.3.26 sets such values to 0 (and anything above 100 to 100) in the run's copy of the chart when you load the patch set, and tells you exactly which patch changed and from what (for example "Patch 13: red −23.1373 → 0"). Your own file is never changed. Then the chart, the print, the measurement and the profile all agree on what was printed, and the import goes through. A chart you already measured with such a value is checked against the clamped value too, so the .ti3 from your own converter (which is in the .ti2's patch order) now imports into your ColorCheck24 run.

Thanks again for the careful testing and the clear files!