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.