So Far the GUI Works Great

[agoldhammer24]

I just completed building two profiles to test ChromIQ ver 3.6.1. Both involved generation of a one-page patch set for a preconditioning profile. This was then used to generate a two-page patch set for the final profile. Normally, I use a four-page patch set for the final profile but I wanted to conserve paper for testing purposes. Everything went fine and I generated profiles that appear to be just as good as those that I did through the manual command line process. I checked the program pop-up to see about updates and that pointed me to the most recent update on GitHub that I just downloaded. Since I use everything in manual mode, I've created profiles of all the settings so there should not be any user errror.

[itsab1989]

Thank you very much for posting this here!
The GUI probably needs some more fine-tuning. Someone else from the forum also got strange results and it took a while for me but then I thought that he might have had the same issue as you. And this should not happen.
So in the latest releases the bi-directional reading is enabled by default at least in the manual tab now.
That is why feedback is so important. For now I based the decision for defaults on my own (very limited) experience and recommendation from Knut. But I still have to find the right mix of settings for the guided mode so someone who does not want to go deep into the topic can more or less just click the big button on every tab and get a good result.

One "funny thing": On printerknowledge pharmacist advised to increase the margins in printtarg to 10 when an i1Pro device is used. I set this as a default for this device. In guided mode this is not changeable by the user. This results in one less strip fitting on an A4 paper. On another forum someone now was confused why with my app there is one less strip because he did not notice the margin setting right away. This was on dpreview and my posts there are being held under moderation for days now. I cannot reply which is very frustrating.

On a side note: please check the latest version. I mainly improved some visuals but it should helpt to give the user a better experience.

Oh and someone mentioned the highlighter wasn't working when measuring. Is this happening for you as well?

[agoldhammer24]

I'll try to remember to post all my comments on your GitHub site. As I said on Printer Knowledge, adding the average feature to the chart measurement tab will be useful to me. When I measure charts for profiles I always do two measuements and then use the 'average' utility that is part of ArgyllCMS. You can either use a number or letter to do this. The first pass of the reading would create, file_1.ti3 and the second reading, file_2.ti3 Then it is simple command: average file_1.ti3 file_2.ti3 file.ti3 where 'file.ti3' is used to create the profile. Int his case 'file' is the name of the paper that I am profiling, for example 'Canson_Platine_Fibre_Rag

[itsab1989]

That's very kind! With the feature request you mention I am already done, just not released before I made some more progress. Or do you want adjustments?

[agoldhammer24]

That looks great. I just need the 'average' tool integrated and then I'm good to go. I have a new paper waiting to be profiled and I will use this app to get it done.

[itsab1989]

That's the next thing I am already working on :)

[itsab1989]

Hi Alan,

this one is specifically for you. I have to admit I tested nothing except that the app starts. It passed all of Claudes tests but I would kindly ask you to run a real test against a real target:

What to test

The completion dialog appears. Finish a normal chart read — after the usual
"All stripes read" prompt, a new Measurement Complete dialog should offer
Continue to Build Profile and Measure again to average.
Measure again. Choosing it should re-read the same chart from the start (a
fresh full read, not a resume) and keep the previous read.
Two or more reads. After a second read the dialog should offer Average all
reads & build, Use last read only, and Measure again, plus the Mean/Median
selector.
Average & build. Averaging should produce one measurement file and take you
to Build Profile with it loaded; the chart's patch file is still linked, so
"print again" / refinement keep working.
Three or more reads and the Median option, if you want to exercise the
outlier-rejection path.

If anything is broken, if there is an oversight, a glitch in the user interface or something you miss please open an issue here on GitHub.

https://github.com/itsab1989/ChromIQ/releases/tag/v3.8.0-beta.5

[itsab1989]

Or are those new options overwhelming for an unexperienced user?
Should I make them optional by adding a new option in the settings window that is disabled by default?

[agoldhammer24]

I have a two page patch set that I used this morning and will try it again and report back. I used this patch set to make a final profile with is excellent. Thank you for all the hard work.

[itsab1989]

I can only give this back - thank YOU so much.
A few weeks ago I thought I made a simple GUI for Argyll. I got it to a point where it was working for me and I thought I was done and that I had covered everything. Thanks to you I learned about features of Argyll that I did not even know they exist.
And now in the other discussion here out of nowhere a complete stranger tells me that he likes this idea and it might save him a good amount of money. This is so nice to hear. And you and pharmacist are a big part of this. So thanks a lot!

[itsab1989]

I made a beta 6 already, added of few general improvements and made this new feature an option. So in case you download beta 6 you have to activate it first:

https://github.com/itsab1989/ChromIQ/releases/tag/v3.8.0-beta.6

[agoldhammer24]

Downloaded the beta and will test tomorrow. Too tired to read patches right now!!😁

[itsab1989]

Same for me. But I keep checking my email for comments. It's like an addiction to a degree. Which is not good sometimes. So I will put my phone away for now!
Looking forward to hear from you tomorrow!

[agoldhammer24]

Average did not work. The pop up window asked if I wanted to build the profile or do another reading to average. I clicked on do another reading to average and the app locked up. It would not let me do anything in the measurement tab. I went to view the files and the existing ti3 file that I just measured is saved as 'file_read1.ti3. It now appears to be responsive and I will read the patches again to see if the average works OK.

[itsab1989]

That's not good. In case it happens again could you please attach the log files so Claude can see exactly what went wrong?

I just tried on my Mac and it does not even give me the new option. Need to figure this one out.

[itsab1989]

Hi Alan,

Quick note on who's actually typing here: I'm Claude, the AI assistant Basti (itsab1989) works with on ChromIQ. He asked me to dig properly into your Verify feedback, sanity-check the ideas against the ArgyllCMS source, and share what I found with you directly — so this comment is from me, with his blessing. 🙂

First, the reassuring part: your instinct was right, and what you saw isn't really a bug — and it probably isn't your chart's RGB values being "off" either.

Why the deep blacks blew up

Your friend's reference Lab values came out of i1Profiler and, as he said, were optimised for glossy paper. You measured a print on matte. Matte paper simply has a much higher (lighter) black point — its darkest possible black might sit around L* 20–25, where glossy can reach L* 5 or lower. So when the reference asks "this patch should be L* 5" and your matte paper physically tops out at L* 22, you get a huge ΔE in the shadows — not because anything went wrong, but because you asked the paper for a black it can't make. That's a gamut fact, not a profile-accuracy fact. It's also why you said normal profiling always gives you low errors: that's a different measurement entirely (more on that below).

So the high numbers are real and meaningful — they're telling you "matte can't reproduce glossy-targeted shadows" — they're just not the question you actually wanted answered.

The key realisation: there are two different questions hiding here

Question 1 — "Is my profile accurate?" This is almost certainly what you really want, and it's the one with the satisfying low numbers. The fully-in-Argyll recipe you were reaching for does exist — and you already use every tool in it:

1. targen a fresh, modest patch set (different patches than the ones you built the profile with),
2. print it through the profile, chartread it → that gives you a .ti3 with your measurements in it,
3. run profcheck of that .ti3 against your .icc.

You wrote that you couldn't find a tool to turn a .ti2 into a .ti3 containing measurements — but that tool is chartread itself, which you use every day. chartread reads the chart and writes the measured .ti3; profcheck then runs each patch's device value through your profile and compares it to what you actually measured. Because the verification patches weren't used to build the profile, this is a genuine cross-check of accuracy — no external reference, no glossy-vs-matte mismatch, and it'll give you the low errors you expect from a good profile. ChromIQ already has profcheck under the hood (it powers Check & Refine), so this is mostly a matter of giving it its own friendly "verify my profile" front door.

Question 2 — "Can my paper reproduce my friend's specific target colours?" This is what Verify (colverify) is doing today, and it's a legitimate question — it's just dominated by physics unless we make it smarter. Here are concrete things colverify can already do that we don't yet surface:

• Skip the unreachable patches automatically (-L <your profile>). If we hand colverify your own matte profile, it drops the patches that fall outside what matte can print and tells you e.g. "42 of 50 patches in gamut" — so the deep blacks stop drowning out everything else, and the remaining ΔE reflects real reproduction error.
• Split the error into lightness vs colour. colverify already reports an average "how much was L* vs a* vs b*" breakdown, and for each patch it prints both the target and measured Lab — so we can label a shadow patch as "this error is almost entirely lightness — expected on matte" versus "this is an actual hue/colour error worth caring about." That's the bit that makes it genuinely more useful than dropping numbers into Excel: it interprets them for you.
• Best-90% / worst-10% summary (colverify prints this for free) — "ignore the worst few unreachable shadows; the rest matches at avg ΔE 1.3."
• Match the measurement conditions (illuminant / observer / FWA). If your friend's i1Profiler data was D50/M1 and you measured M0, that alone adds a systematic error to every patch. Lining these up removes a whole class of false differences.

A bonus: see where it diverges, in 3D

colverify can also emit a 3D visualisation (-w) drawing an arrow from each target colour to where your print actually landed. It happens to come out in exactly the same X3DOM format ChromIQ already uses for the gamut viewer — so we could show it right in the panel you already have: green dots = your friend's targets, red dots = your prints, arrows showing the drift. A picture like that makes "the shadows pull one way, the rest is spot-on" obvious at a glance.

Where this leaves us

My suggestion to Basti is to split Verify into two clearly-labelled modes:

• Verify my profile (the recommended default) — the independent targen → chartread → profcheck cross-check above. Self-contained, no external reference, gives the low errors you'd expect.
• Compare to an external reference (advanced) — today's colverify, but made interpretable: auto gamut-skip with your own profile, the lightness-vs-colour split, best-90%, and optionally the 3D drift plot.

Net: the tool isn't broken — it was just answering the harder of two questions without telling you which one. None of this is built yet; these are the directions we're weighing, and I'd genuinely love your gut reaction, since you're the one doing this for real on real paper.

Thanks again for testing so thoroughly — this kind of feedback is exactly what turns it from "works on my machine" into something that works for everyone.

— Claude (with Basti)

[agoldhammer24]

Yes, I would go ahead and put out the stable release. Right now it looks like we are tinkering around the edges. For probably 98% of the people who will be interested in this, all the features they might need are there. I would also post to the ArgyllCMS list serve about this.

[itsab1989]

Claude currently implements those changes it suggested to me and you. When it is done I would send you another message with the new beta. If it looks good to you I would make this a stable release and add the presets later. But I think 3.8.0 really made big progress and I want to get this out.

Would you then be so kind after this is released and write to the Argyll mailing list? I already mentioned it there twice and did not get that much response. First time someone said that the little Argyll GUI would be doing a good job as well (which I personally think it doesn't).
So I think it is better if someone else would give an honest recommendation.

[itsab1989]

Hi Alan — Claude here again (the AI assistant Basti works with on ChromIQ; he asked me to write this up for you directly).

A new beta is out, v3.8.0-beta.31, and it's built around the Verify feedback you gave a couple of days ago. Two things you said stuck with us: that the error numbers looked alarmingly high, and that the really meaningful check would be one that "keeps all the data inside ArgyllCMS." This release tackles both. Here's what changed and exactly what would be helpful to test.

👉 Download: https://github.com/itsab1989/ChromIQ/releases/tag/v3.8.0-beta.31

---

1. A brand-new tool: "Verify a profile (independent check)" ← this is the one I'd most love your eyes on

This is the honest, all-in-Argyll check you were reaching for. Remember you tried to think of a way to do it with targen and got stuck because there's no tool that turns a .ti2 into a .ti3 with measurements? It turns out the tool for that is one you already use every day — chartread. So the workflow is simply:

1. Make a small, fresh chart in the Create Chart tab — a few hundred patches is plenty, and the key is that it's different from the chart you built the profile with.
2. Print it through the profile you want to test, and read it back on the Measure tab. That gives you a .ti3.
3. Open Tools → "Verify a profile (independent check)", pick that profile and that measurement, and click Verify.

Because the verification patches weren't used to build the profile, this is a genuine test of accuracy — the profile has to predict colours it never saw. You'll get an average and peak ΔE plus a plain-language verdict ("excellent / good / …"). What I'd love to know: does it run cleanly end to end, do the numbers look sensible for a profile you trust, and is the wording clear?

2. "Verify against reference" now explains itself

This is the tool you used last time, where the deep blacks blew up. Two changes:

• It now tells you why the number is high. When you run it, it works out whether the error is mostly lightness (a black-point / paper limit — exactly what happens when glossy-targeted values are checked on matte, because matte can't go as dark) or a real colour shift. So instead of a scary ΔE with no context, it says something like "most of this is lightness, the actual colour is much closer." Please try it again with your friend's glossy-made reference on a matte print and see if the explanation matches your intuition.
• You can tell it to skip colours your paper can't print. There's a new optional "Your profile (.icc)" slot. Point it at the profile for the paper you actually printed on, and it leaves the unreachable colours (mostly the deepest shadows) out of the score — and tells you how many it skipped. The remaining number is a fair measure of the colours your paper can make.

3. A 3D difference map (optional, fun, and informative)

In "Verify against reference" there's a checkbox "Create a 3D difference map." Tick it, and when the check finishes an interactive 3D window opens: every patch is a short line from the colour you asked for (a green dot) to the colour you actually got (a red dot). Lines all leaning the same way = a consistent drift; a few long lines among short ones = specific problem patches. Drag to rotate, scroll to zoom. Worth checking on Windows especially — it uses the same 3D engine as the gamut viewer, so if that already works for you this should too, but I'd like to be sure it opens and renders rather than showing a blank box.

Smaller things

A couple of dark-mode tidy-ups (the status box in the tool windows now matches the other input fields instead of being almost black), and the Tools menu is a touch wider so the new entry isn't cut off.

---

One honest note: I tested all of this against the real Argyll tools and the app's own test suite, but the 3D map's actual on-screen rendering is the one piece I couldn't fully verify on my end (it needs a real display/GPU). That's why a quick "yes, the 3D window opened fine" from you would be especially valuable.

Thank you again — your testing is genuinely shaping this. No rush at all; whenever you next have a sheet drying. 🙂

— Claude (with Basti)

[itsab1989]

If you think it is fine you could also share this beta link in the Argyll mailing list because the stable release will not be much different from this except you find some big bugs in this when you check.

[itsab1989]

@agoldhammer24

I made v3.8.0 the new stable version now. Fingers crossed and thanks for everything! :)

[agoldhammer24]

One more thing to add when you have time. In the measurement tab using 'chartread' it would be nice to have the option to suppress spectral data when you read the chart. This is done with the '-n' flag. If you have the spectral data it can make it difficult to review the 'ti3' file as there is a lot of extraneous data there. Most of the time, I don't collect this data when I'm reading charts.

this is not an urgent request but when you do an update it would be a useful feature.

[itsab1989]

@agoldhammer24 Done — this is in v3.8.2, just released: https://github.com/itsab1989/ChromIQ/releases/tag/v3.8.2

In the Measure tab under Manual mode there's now an option "Don't save spectral data (-n)". Tick it and chartread stores only the colour values (XYZ, or Lab*) in the .ti3 and leaves the per-wavelength spectrum out — exactly the lean, easy-to-review file you were after. It's off by default, and your profiles are unaffected either way (colprof only needs the colour values).

There's an ⓘ explainer next to it spelling out the one caveat: keep spectral data if you use optical-brightener (FWA) compensation when building the profile, or want to re-derive values under a different illuminant.

Thanks again for the suggestion!

[itsab1989]

I mean AI is really great for the coding part. But sometimes it is very lazy. Over the course of making this app I told it multiple times to read the documentation of Argyll and to make sure to add EVERY option. It always told me that it did and I believed it. Yet I had to add a lot of options later. So you could say that I am lazy as well because I did not check :)

[agoldhammer24]

It's really hard when there are so many options. However a lot of those are for CMYK printers which don't concern most of us. Thanks for adding this in, I just forgot about it until today.

[itsab1989]

You're welcome! This was a 5 minute fix. If you notice that any other option is missing just give me a heads up!
But all in all I think printer profiling with Argyll should now be a solved issue :)

[agoldhammer24]

Just to close the loop on the discussion. I created a new profile using the GUI for a paper that is one of my regulars, Moab Entrada Rag. I used the dense packing for my i1 Pro to get 506 patches per sheet. I used a one sheet preconditioning profile with 32 grey patches. For the final profile I used three sheets (1518 patches) with 48 neutral patches. I don't see the need to go up to 64 as that can cause some spreading of patches. I did two readings of each set using the average feature. Everything worked well and I got very low standard errors with the only high error readings (1.3) for black which is understandable as this is a matte paper. The gamut report was the same as the previous profile using the command line.

Because I can get more patches on the page, I save a couple of sheets of paper. Given how much paper costs these days, that's a good thing. I'm impressed with Claude and this is the first concrete example that I have personally seen of an app created in this way. Good job to you and Claude!!!! I'm not sure I have much more to contribute to the project right now as I don't have any new papers to profile and all my existing profiles are just fine.

Thank you for the work you put in on this. I hope this attracts more potential users to ArgyllCMS. It's a very good program as well as being free!!

Alan

[itsab1989]

I am glad to hear this. Because now I feel like the app is somewhat finished and complete and it would not be without your feedback. Right from the beginning of your tests you noticed so many missing options that I felt a little embarrassed because I did not notice it myself. But now everything should be in place.
AI is really great for things like this. But it is not a one and done solution. Although Claude wrote the code you have to handhold it, check what it is doing, stop if something goes in the wrong direction...
So it still was a lot of work. But it makes me happy to get positive responses now :)

[agoldhammer24]

I posted over on Printer Knowledge about having the same problem with the refine function. I think this is the log file from the run where there was an issue. It does identify the row graphically,
chromiqa.log
but I don't know if it writes the data back to the correct place. After I ran 'refine' I got huge errors in the profile.

I had to rename the log file so it would post which is why the 'a' is in there. I did not want to write over an existing log file.

[agoldhammer24]

Unfortunately, I deleted those folders and reprofiled without using the refine step. So I cannot help you. I might have some time early next week to examine this and maybe print out a very short patch set and use the refine step. I'll center on one patch strip and do two different readings, 1) read the strip in the forward direction and then 2) read it in the reverse direction. I wonder if the refine step does not have bidirectional reading enabled. I honestly cannot remember how I read those strips and I think there were 4-5 of them.

[itsab1989]

I was wondering the same thing but it should have it enabled. There is still the possibility that it is enabled but it is failing to identify the correct direction. If that was the case I would really disable bi-directional for refinement and make it extra clear that the user is supposed to read the strips from the side with the letter for this process only. I think this would be fine because you are not reading the whole chart again for this process.
But of course only if this really is the issue.

[agoldhammer24]

I just scanned a one page patch set this morning that ended up with two patches above 1.5 error. I used the refine tool to measure the two strips again and it worked just fine. I did several runs using both reading in the forward and reverse directions and there was no difference. The one patch with an error over 2 is solid black and it improved with the second reading just a bit. I think this issue is now fixed. I have included the log file just for information.

If there is anything else that you want me to check just message me through GitHub. All the features that I use now appear to be working properly. Again, thank you for all the work on this project. I hope that others will use it.
chromiq.log

[agoldhammer24]

I was just looking over your change log and see that there is a setting for 5x7 paper. This is also useful as I do print out Artist Cards. The previous paper manufacturer, Museo, is out of business and when my stock runs out I will need to bet some from Moab and will have to profile those.

[itsab1989]

Hi Alan!

It is always nice to hear from you!
While I added some more presets from Pharmacist I noticed that the scanning highlighter was off in his screenshot. Claude then told me that for the first measurement run it used a very solid version of its patch recognition but for whatever reason when you go back into a session it used a more simple way which I thought was replaced completely already.
After I figured that out it should now always use the improved version. So I don't know for sure but maybe the highlighter was off and that was the reason the refinement scans came out so bad.

The paper size you mentioned has been around for a while now. But yesterday I have noticed that Claude had not added the amount of patches that fit on a single sheet for all of the combinations of instruments and settings. So I let it run targen and printtarg again to figure out those values. That's why it is in the changelog again.
Happy to hear that it is useful for you!