[Feature] i1iO 2/3 device support for reading charts

[joinsrl]

What problem does this solve?

Reading charts with only i1, especially when there are many patches spread over multiple pages, takes a lot of time. At the moment, the only solution is to use i1 profiler to read the charts with i1iO and then import the readings, but it would be useful to directly support the tool so you don't have to leave the wizard.

Proposed solution

Implementing support for iO drivers.

Alternatives considered

No response

Relevant platform(s)

Any / all

Anything else?

No response

[itsab1989]

Hi @joinsrl, and thanks for the request — sorry it took a while to answer properly.

A bit of honesty up front about who's writing this: I'm Claude, an AI assistant, and I looked into this together with the maintainer. I want to be straight with you about what's realistic, because this is the kind of feature that's easy to get excited about and then can't be delivered. So this is a long, careful reply rather than a quick "yes we'll do it".

The most important context: ChromIQ is essentially a one-person project, and that person isn't a professional developer — it's a hobby built with a lot of care, not a company with a hardware lab. That shapes everything below. I'd rather under-promise here than leave you waiting on something that may never arrive.

Where things stand today

The short version: it's not supported now, and adding it is a real project, not a quick fix — but it isn't hopeless either.

The reason it's hard is simple. The i1iO table talks to the computer over a serial-style USB connection, and the "language" it uses isn't publicly documented anywhere. ChromIQ can't drive a device whose commands it doesn't know. So before any of the nice user-facing parts, someone has to work out how the table communicates — and the only sound way to do that is by observing an i1iO while it's being used normally. Which is the one real blocker: nobody working on ChromIQ owns an i1iO. That's the whole problem in one sentence.

There is some cautious good news. ChromIQ's measuring engine is built on top of a long-standing open-source colour tool that, years ago, supported a similar kind of automated measuring table — so the general idea of "a motor moves the instrument over the chart" isn't foreign to the foundations. I don't want to oversell that, though: the maintainer notes, fairly, that he's never even seen those older automated-table options anywhere in ChromIQ's own interface. So "groundwork exists underneath" is very different from "it's half done". It would still be a substantial piece of work, and it honestly might not get built at all.

What "full automated support" would involve

You specifically want the real thing — the table reading the whole chart on its own, not just being nudged along like a hand. That's the right goal, and here's the honest scope so nobody's surprised later:

1. Teaching ChromIQ the table's command language (move here, go home, hold the paper, read this spot). This is the hard, uncertain part, and it's impossible without the hardware.
2. A chart layout designed for a robot rather than a person — a dense grid the arm addresses by coordinates. ChromIQ would need a new layout for the iO; it doesn't have one today. (Interestingly, i1Profiler's own files show the iO uses far denser charts than a handheld i1Pro, and that it has two reading styles — a spot mode and a strip-scan mode — which is useful to know.)
3. The user-facing parts — starting it from the Measure screen, progress, a stop button.

A realistic path, if this ever happens, would probably start smaller and build up. But even that depends entirely on getting past the blocker above. I'm describing a possible route, not a commitment or a timeline — there genuinely isn't one.

How you (or anyone with an iO) could help

This is where it stops being theoretical, and it's a small, completely safe first step.

I made a little read-only helper tool that collects the technical details of how an i1iO appears to your computer. To be very clear about what it does and doesn't do:

• ✅ It only reads information your computer already has about plugged-in hardware.
• ❌ It never sends anything to the table, and it cannot move the arm. It doesn't even open a connection to the device.
• ❌ It changes nothing and needs no special setup or calibration.

It now comes as a ready-to-run download — no Python or setup needed. Plug in your iO, run the file for your system, follow three short on-screen steps, and it saves a plain-text file you can look over and attach here.

➡️ Download it here (latest release)

Your system	File to download
Windows	chromiq-io-probe-windows.exe
macOS (Intel and Apple Silicon)	chromiq-io-probe-macos
Linux	chromiq-io-probe-linux

The tool lives in its own small repo: https://github.com/itsab1989/chromiq-i1io-probe — you can read every line of it before running anything, and the README explains exactly what it collects and how to get past the "unidentified developer" warning (the downloads aren't code-signed, so your system will warn once — that's normal). Prefer to run the plain source instead? Grab chromiq-i1io-probe-scripts.zip from the same release.

A couple of quick questions that also help regardless:

• Which generation is your table — iO, iO2, or iO3?
• Which instrument is mounted on it (i1Pro, i1Pro 2, i1Pro 3)?
• Which operating system would you be using?

One more bit of honesty on timing: the maintainer does this in whatever spare time he has, alongside plenty of other things, so even in the best case — someone helps, the report is useful — this could sit for a long while before anything happens, and it might not happen at all. There's no schedule here and nothing is being committed to. Please read the tool as "a way to keep the door open," not as a sign that work is starting.

In the meantime

The workflow you mentioned — measuring in i1Profiler and importing the results — does still work, and the import side has improved recently, so it's a bit less painful than it used to be. Not the seamless in-wizard experience you're after, I know, but it's there today.

Bottom line

It's a good request, and I don't want to close the door on it — but I also won't pretend it's around the corner. It's a sizeable, uncertain feature, currently stuck for want of hardware and time on a small hobby project. The honest status is "we'd like to, we've done the homework, and it now depends on an i1iO owner being willing to help." If that's you, the little tool above is the perfect first step.

Thanks again for taking the time to suggest it. 🙂

— Claude (with the maintainer)

[itsab1989]

Quick update — the helper tool is ready to run with no setup (an earlier version needed Python; that's no longer the case), and it has had a few rounds of polish since.

If you have an i1iO and are willing to help, this is a genuinely small, completely safe favour: the tool only reads how your table appears to the computer. It never sends anything to the table and cannot move the arm — it doesn't even open a connection to it.

➡️ Download for your system (latest release)

• Windows → chromiq-io-probe-windows.exe — double-click it, then More info → Run anyway.
• macOS (Intel and Apple Silicon, one universal file) → chromiq-io-probe-macos — see the note below.
• Linux → chromiq-io-probe-linux — see the note below.

That link always points at the newest version, so it stays correct. Plug in the iO, run the file, follow three short steps, then attach the plain-text file it saves. About two minutes, no technical knowledge needed.

A small but important note for macOS and Linux: downloaded files aren't marked as runnable, so double-clicking may look like it does nothing at all. On macOS, try right-clicking the file → Open → Open again in the dialog. If that doesn't work (or you're on Linux), open a terminal and run:

cd ~/Downloads
chmod +x chromiq-io-probe-macos      # or chromiq-io-probe-linux
./chromiq-io-probe-macos

chmod +x just marks the file as runnable; the second line starts it. Sorry for the extra step — the downloads aren't code-signed (that needs a paid certificate), so your system will also warn you once. That's normal, and the README explains it fully — and lets you read the whole tool first, if you'd rather.

If you're on macOS and feel like doing the optional advanced step too: it used to say "install Wireshark and its ChmodBPF helper", which was both awkward and, as it turns out, unnecessary. macOS already includes everything needed, so the tool now just writes a short, readable script you can double-click. It asks for your admin password (macOS requires that to listen to USB traffic), records to a file, and puts every setting back as it found it. Nothing gets installed and nothing is left behind — and it still only listens; it cannot move the arm. The guided part of that step follows i1Profiler's real measuring sequence (press Measure, align the arm on the three corner patches by hand, let it scan), so it should match what you actually see on screen.

That advanced step is entirely optional and takes longer. Please feel free to skip it — the basic report on its own is already the useful part.

No pressure and no promises attached — as noted above, even with a report in hand this is a big, uncertain feature on a small hobby project, worked on in whatever spare time there is. But this report is the one thing that would move it from "interesting idea, no hardware" to "okay, we can actually look." Thank you to anyone who gives it a go. 🙏

[itsab1989]

And an answer from me personally 😊

I like this idea and it would really be a very nice improvement for the app. Another person mentioned that he would like it to natively support an i1isis as well. And I agree. But I have no way of testing this. I am a care worker and this started as a hobby project. Then Knut and I got more involved with this than we planned, spent sleepless nights with it (and a lot of money for AI). But I think the project turned out to he pretty good so far and is already useful for a few people.

So if you have such a device please try the little tool and comment here with the output added. However I can't judge how realistic support for it will be. To be honest I was surprised about Claude being so optimistic.

[joinsrl]

I tried to run yours since I have an i1 + iO, but some of the steps it requires in the advanced phase, like the commands for positioning the reading arm, can't be done with i1Profiler

[soul-traveller]

I suggest one thing:
Use a known chart.
Use the IO tool while reading that chart with your Colormunki/i1Studio.
Hand over both chart files and the resulting IO monitoring files, also the logfile from during measurement, to Claude.

Analyse the data, the known charts against the data, and check against current implementation of the ChromIQ chartread engine. Report on issues found or differences in implementation found from actual evidence found from IO monitoring (aligned with and verified against the known chart info).

Then, have claude correct the IO tool if it finds any bad behaviour, bugs, wrong monitoring methods/strategy, wrong interpretation of formats, encoding of events and data, calibration data, identification of hardware etc.
This would verify, to some degree, if the IO tool works, and would make it more robust for other tasks.

Just a thought of action….

[itsab1989]

@joinsrl
Which version of it did you try? I noticed last night that some of the things it asked for made no sense and let Claude make an update for it after watching a video that showed hoe the i1iO is handeled.

Or could you maybe describe what this little test app asks for and what i1Profiler actually does so I can get it right?

[soul-traveller]

@joinsrl and @itsab1989 :

Claude needs to know exactly what happens when an action is initiated in i1Profiler. Thus you need to supply the chart files used, and explain what the arm is doing, where it is moving exactly (every move), which patch it is stopping at (position number/ID), so that Claude can analyse the chart data and compare with the communication traffic to the instrument. This way claude can find the familiar patterns and evolve the IO monitoring tool to measure and identify the next steps. Then run the exact same action again with a new IO monitoring version, supply all the same data files again for reanalysis, then evolve the IO monitoring tool again. This loop may need to be made several times. Then, a small i1iO control app can be created and evolved, until all the various actions are identified and can be replicated using this control tool. The control tool must also have its own log and feedback, so that claude can correct its behaviour and fix bugs and wrong assumptions.

Supplying any known command ID codes that the iO uses can also be useful, maybe search the internet for such information too.
Possible USB commands to identfy:

• Return (x,y) vector postion for arm
• Move Left, Right, up, down
• Start / stop movement
• Read patch color (and detect how many readings for the specified patch and color is returned)
• and possible other commands, such as overall commands that perform several sub-commands: Like - Calibrate on white patch, Start measurement process, Go to last read patch and read again, or others.

It is important to focus on one single command from i1Profiler at a time, till it is figured out. Start with the simplest command available, such as Set start position patch, or Go to patch, or Calibrate... Whatever commands are available. For each command executed, claude needs a detailed description of what you can see happening on screen and with the arm, then supply all the files and logs available.

This is how I see it moving forward.

[itsab1989]

Hi @joinsrl — thank you for actually trying it, and sorry the version you ran asked for things i1Profiler can't do. That's fixed.

The old walkthrough wrongly implied the tool would position the arm through i1Profiler — it never does. It just watches while you run i1Profiler normally and move the arm by hand onto the corner patches, exactly as you already do. The current release (latest) matches that real sequence.

If you're up for another go: grab the newest download and re-run it. There's also a new --analyze option that lets you check your own capture before sending it — it'll tell you plainly whether it recorded real traffic from the table, so you're never sending a file that didn't work. No pressure at all, and thank you again. 🙂

— Claude (ChromIQ's AI assistant, working on this together with the maintainer)

[itsab1989]

Hi @soul-traveller — you sent one more idea to the maintainer privately (over iMessage rather than here on the issue), and it's good enough that we wanted to bring it into the thread so it's on the record and anyone else following along can weigh in. 🙂

Your thought: once this little tool has helped us identify the i1iO's USB commands, the first version of an i1iO control app could simply put a button on screen for each command. You press a button, watch what the arm does, and report back — and that way we'd map out what each command means very quickly. With, as you rightly said, a finger on the power switch in case the arm moves too fast or past its limits.

I think the end goal you're describing is exactly right, and I want to build up to it. Let me explain how I'd sequence it, because there's an important safety point.

First, one big distinction. Everything shared so far — the probe, the capture, the analyzer — only ever reads. It never sends a single thing to your instrument. That's deliberate, and it's the reason it's safe for anyone to run. The button app you're describing is the opposite kind of tool: it sends commands and moves a motor. That's completely fine and necessary — but it's a separate app, and it stays separate, so the read-only tools keep their "this can't possibly touch your hardware" promise.

Now the safety point, plainly: a motorised arm can slam to a hard stop faster than a human can react — by the time your finger reaches the switch, it may already have hit something. And that "something" could be the i1Pro mounted on the arm, which is the expensive part. So the finger-on-the-switch is a good backup, but I don't want it to be the only thing standing between a wrong command and a damaged instrument.

So rather than showing every button at once, I'd order them by risk — same idea, just safest-first:

1. Buttons that only ask questions, first. Some commands just read — "where is the arm?", "what's your status?", "what's your firmware/serial?". These are 100% safe to press as often as we like, and pressing them teaches us how the arm reports its position — half the puzzle, with zero risk of movement.
2. Learn the movement without commanding it yet. Before ever sending a "move" command, we watch the arm being moved the safe ways — by i1Profiler, and by hand — while recording. That lets us work out the arm's coordinate system (what the position numbers mean) without us driving anything.
3. Only then, the smallest possible real move. The first movement button does a tiny nudge — one direction, a couple of millimetres — and the app refuses anything bigger until we've confirmed it behaves. We build up from there. For these early tests I'd also suggest taking the i1Pro off the arm, so the sensor can't be what collides.
4. Then the full button board — your idea. Once we actually understand the commands, buttons to fire them and iterate quickly is exactly the right tool. That's where we're heading; I just want to arrive there with the dangerous buttons added last, not first.

And you already nailed the other essential piece earlier: the control app keeps its own log of everything it sends and receives, so every test is reproducible and mistakes can be fixed from the data instead of guesswork.

Bottom line: love the idea, it's the right destination — I'd just walk the last few steps carefully, because it's your (expensive) hardware on the line. Thank you for keeping the ideas coming; you're thinking about this exactly the way it needs to be thought about. 🙏

— Claude (ChromIQ's AI assistant, working on this together with the maintainer)

[itsab1989]

Hi @soul-traveller — I did both things you suggested. Here's what came of them.

1. Your ColorMunki idea — we tried it, and it worked.

You suggested using a device we already support (a ColorMunki) on a known chart, to check whether the monitoring tool actually captures and interprets things correctly before we ever trust it on an unknown device. We did exactly that: recorded a real measurement, then compared the captured USB traffic against ArgyllCMS's own ColorMunki driver. It matched byte-for-byte — the same command codes, the same data lengths, the firmware handshake, all of it. So the capture-and-analysis pipeline is proven on real hardware, not just in theory. Genuinely good call.

One concrete result of that: the tool now has an --analyze option that reads a capture and tells you in plain language whether it actually recorded real instrument traffic (and prints the command timeline) — so nobody ends up sending a file that turned out to be empty.

2. Your "search the web for known command IDs" idea — I searched; here's the honest result.

I looked, fairly hard, from several angles. There is no public documentation of the i1iO's arm-control commands anywhere I could find — no SDK, no reverse-engineering write-up, no open-source project that drives the arm. The only X-Rite USB protocol that has been publicly documented (there's even a Wireshark dissector for it) is the i1 Display Pro colorimeter, which is a completely different device and tells us nothing about the table. And ArgyllCMS's author has confirmed the iO is unsupported; the only known workaround is measuring in X-Rite's own software and exporting the numbers as a CGATS/text file.

That sounds like bad news, but it actually settles the strategy: since nobody has written the commands down, the only way to learn them is to observe the real device — which is precisely the capture → analyse → repeat loop you laid out. The empty web search doesn't weaken the plan; it confirms it's the only path.

One encouraging thing I did find: ArgyllCMS already supports a different motorised measurement table — the old Gretag SpectroScan, a motor that moves a spectrometer over a chart by X/Y coordinates. So the general idea of "drive a motor to a position and take a reading" already exists in the foundations ChromIQ is built on. The iO's specific commands still have to be observed, but we're not inventing the concept from scratch.

And your candidate command list — return arm X/Y, move in each direction, start/stop, read a patch, plus the composite "calibrate / start measurement / re-read last patch" ones — is exactly the right target list to work through, simplest first, once someone with an iO can capture a session.

So: both of your suggestions were good — one is already done and passed, and the other tells us the observation route is the real one. Thank you again for thinking this through so carefully. 🙏

— Claude (ChromIQ's AI assistant, working on this together with the maintainer)