Repository navigation
ChromIQ v4.3.4
Fixes from Knut's tests of 4.3.3. Misread outlines are judged only after "Was a strip read twice?" is answered, and a value exactly on a threshold no longer counts as over it. Install Profile on the Build Profile tab works again, printing a chart again no longer makes it look changed, and From Profile Gamut charts cover the printer's strongest colours. Printing a verification chart through the macOS print dialog is explained on the Print Chart tab and checked more closely, including Epson's own colour matching.
Fixed
- A strip turned red behind "Was a strip read twice?", and stayed red after the answer. With the reader on strip C, reading strip B again filed B's colours as C, and ChromIQ judged them as C at once, before the question was asked, so all of C was outlined red (or yellow) behind the window and kept that after "I read strip B". A reading the question is about is now judged only once it is answered, and for the strip the answer gives it: Keep (or closing the window) judges it as the strip it was read on, Re-read and I read strip B set it aside unjudged, and the strip shows no reading until it is read again. Nothing changes behind the open window (#182, Knut).
- A patch exactly on a threshold was outlined red. Patch B3 turned red at ΔE 3.0 with the neighbour limit at 3.0. Every threshold in Preferences ▸ Measurement now compares at one decimal, as the patch cards show the values, and only a value above the threshold is flagged: at 3.0, ΔE 3.0 is not red and 3.1 is. This applies to the patch error limit, the strip test, the neighbour limit, the colour-neighbour radius (a patch 15.0 away is within a radius of 15.0) and the same-reading tolerance (a re-read 3.0 away is the same reading at 3.0) (#182, Knut).
- Install Profile on the Build Profile tab did nothing. After a profile was built, making a chart (for example a verification chart) emptied the tab's profile but left the button enabled, so pressing it later installed nothing and said nothing. The button now follows the profile: it is enabled exactly when the selected run has a built profile, the profile comes back when you return to that run, and a profile restored at start-up can be installed straight away. Both Install buttons (Build Profile and the Profile Quality Assessment window in Check & Refine) write the same line in their tab's log, naming the folder the profile was copied to, and both give a refined (merged) profile the project's name in the system folder instead of "merged" (#182, Knut).
- "Stored chart differs" after printing the same verification chart again. The print record (
<name>-verify.print.json, which says when and how the sheet was printed) was compared as if it were part of the chart, so printing again and starting a new measurement on the same date raised the window for a chart nobody had changed. Only the chart files decide now; the window still appears when the chart itself is different. The record of the earlier print is kept with the earlier measurement in the date'sold/folder, and the new print's record goes with the new measurement (#182, Knut). - "Before you measure this verification chart" was bold from top to bottom, and wide. macOS draws a message window's text in bold, so the whole window was. Only its two headings ("Before you measure this verification chart" and "What the report does with a metric this chart cannot answer") are bold now, the rest is in the normal weight, an indented line of the metric list stays indented when it wraps, and the window is about a fifth narrower (768 instead of 968 points). On a screen too short for it the one-line version keeps that width too, where it opened about 1000 points wide (#182, Knut).
- A chart macOS converted after all could still be reported as printed with application colour matching only (macOS print dialog). When the chart could not be given the profile the job prints with, ChromIQ warned only for printers whose driver file lists profiles, not for a printer with a profile assigned in ColorSync Utility, such as a PostScript printer set up with your own profile. The warning "The chart may not print with its own colours" now appears for every job that prints with a profile the chart did not get. When the chart does get it, as it normally does, nothing changes: its numbers reach the printer unchanged, measured on a queue set up like Knut's HP Color LaserJet 5550, also with another profile chosen in the dialog's Color Matching panel.
- A verification chart made From Profile Gamut left gaps at the edge of the printer's range. Its colours were the first ones from ChromIQ's colour list that the profile can print, which spread them well over the screen's (sRGB) range but not over your printer's: the strongest colours the printer can make were thinly covered, and on Knut's 324-patch chart the largest gap was 16 ΔE from the nearest patch (24 on a 100-patch chart). The colours are now picked to be as far apart as possible within the profile's range, starting from the eight cube corners, white and black, which brings those gaps down to 11 and 15 ΔE. The same profile and patch count still give the same chart, and a smaller chart's colours are still part of a larger one's. Charts you already made are not changed; only a chart generated again picks the new colours. Some of the gaps seen in the patch distribution view are not gaps in colour: the view plots the printer's RGB values, and in the blues, for example, a large step in RGB is a small step in colour (#182, Knut).
- The Print Chart tab said nothing about printing a verification chart (macOS). With Run type Verification it now says, under its notice, to print the chart on the same printer, paper, media type and quality as the profiling chart, and by the same route; and why the route matters on a PostScript printer. With the macOS print dialog on, it also says to leave the dialog's colour settings, including its Color Matching panel, as they are (#182, Knut).
- On a PostScript printer with your own profile set in ColorSync Utility, the status line now says the chart went with that profile (macOS print dialog), so macOS left its colours unchanged, as it does for a Canon or Epson paper profile. It said only "application colour matching" before. Printers whose driver takes raster data never get this sentence, because there it would not be true (#182, Knut).
- Choosing Epson's own colour matching in the macOS print dialog's Color Matching panel went unnoticed. The job then carried the Epson option instead of ColorSync, and the status line still confirmed it. ChromIQ now sets it back to ColorSync after you close the dialog, as a print from Photoshop has it, and checks the job for it: the job is then the same as with the panel left alone. Canon's own colour matching and a PostScript printer's "printer specific" choice in that panel already changed nothing. The status line now says when ChromIQ set it back, and a window says so if the job still carries the Epson option. Measured the same way on more drivers (Epson SC-P600, Canon PIXMA iP8750 and PRO-100, Brother MFC-9460CDN, HP Color LaserJet 5550 and Photosmart Pro B9100, Gutenprint): only Epson's choice reaches the job; the others' choice changes nothing once ChromIQ has set the job to application colour matching.
- The print confirmation window named the paper twice ("Media Size: A4" and, three rows lower, "Media size: 210 × 297 mm"). The millimetres now follow the paper's name in its row: "Media Size: A4 (210 × 297 mm)" (#182, Knut).
Installation (Linux, beta): Download the tarball for your architecture (x86_64 for most desktops/laptops, aarch64 for ARM systems like Raspberry Pi 4/5). Extract with tar xzf ChromIQ-Linux-*.tar.gz, then run ./ChromIQ/ChromIQ. Requires ArgyllCMS — install via your package manager (sudo apt install argyll) or from argyllcms.com/downloadlinux.html.
☕ ChromIQ is free and always will be — if it saves you time or ink, a coffee is a kind way to say thanks. Completely optional, and the app stays fully featured either way.