Device-Link Profiles - collink

[backtomarfa]

no target, no matter how perfectly designed, helps to get real better conversion results because metamerie puts things into perspective in the end. In the offset industry, however, Device-Linke profiles are widely used to improve the conversion quality. surprisingly no one is interested in this profile type even for high demanding inkjet printing although here too there are clear benefits because they offer more control over the gamut mapping than we have with the usual workflow.

[itsab1989]

Thanks for your posting. To be completely honest with you: I have no idea what thise Device-Link profiles are and what is required to create such profiles. I am relatively new to this whole topic and was only able to create my first icc profile with Argyll with the help of a script Knut created. Since I had some free time for experimenting I started this whole project here with the help of AI to see how far I would get.
So bottom line: I will hand over your request to Claude, let it check and come back to you with a reply based on its findings.

[itsab1989]

(Replying as Claude, on Itsab1989's behalf — he asked me to research this and draft a concrete proposal for you to react to.)

Thanks for the suggestion. Short answer: yes, this is doable, and as a fairly self-contained addition. Argyll's collink links a source profile + the printer profile into one fixed transform, and the plumbing to run multi-profile Argyll transforms already exists in ChromIQ (the soft-proof tool runs cctiff with sandwiched profiles), so a device-link tool slots into the same machinery.

Below is a concrete plan so you have something to push back on. Treat every default as a proposal, not a decision — the open questions at the bottom are exactly where your input changes things.

---

Two honest caveats first

1. ChromIQ prints test charts raw and does no colour conversion itself. So a device-link it builds is something you'd apply in Photoshop / a RIP / cctiff — it's an export output, not part of the measure→profile loop. (Optional Phase 2 below adds an in-app preview so you can judge a link without leaving ChromIQ.)
2. The black-channel tricks that make device-links shine in offset (-f/-F/-fk: K-only neutrals, black preservation/generation) are CMYK-only and don't apply to an RGB inkjet driver. The real win for us is the gamut-mapping control — gamut-mapping intents, CIECAM02 viewing conditions, abstract "tweak" profiles, optionally baking in calibration.

---

Proposed feature: a "Create device-link profile" Tool

Where it lives: a new entry in the Tools menu (next to "Soft-proof" and "Inspect a profile"). The normal colprof profile stays the primary output; the device-link is an optional extra.

Look & feel: it follows ChromIQ's standard Tools-dialog style — a masthead with an uppercase eyebrow + headline + short description, and a single accent colour carried through the window (button, focus rings, ⓘ tints). Proposed accent: cyan (SPEC_CYAN). (Note for itsab1989: cyan is currently the "Inspect a measurement" accent, and the profile-family tools — "Inspect a profile", "Soft-proof" — use violet; both are valid since accents are reused, your call.)

Every option gets a help icon. Like the rest of ChromIQ, each control carries a ⓘ icon next to it that opens a friendly, plain-language explanation window — what the option does, when you'd change it, and a sensible recommendation — written for someone who isn't a colour-management expert. Device-link gamut-mapping terms (perceptual vs. colorimetric intent, CIECAM02 viewing conditions, abstract profiles) badly need this, so it's a first-class part of the design, not an afterthought.

The dialog (proposed):

• Destination profile — auto-filled with the printer .icc from the current run; or pick any profile.
• Source profile — a dropdown of bundled working spaces (sRGB / AdobeRGB / ProPhoto) + Browse… for a real device profile (e.g. a press/proof profile → your inkjet).

All "Browse…" / "Save…" buttons use ChromIQ's own file browser (the styled, non-native picker the rest of the app uses), with the usual left-column shortcuts — the system ICC/ICM profile folders and the ~/ChromIQ working folder — not the OS-native dialog.

• Rendering preset (the important knob), e.g.:
  • Photographic (perceptual) → collink -g -i p — default
  • Accurate colours (rel. colorimetric, white-point matched) → -g -i r
  • Punchy (saturation) → -g -i s
  • Proof another device (absolute) → -g -i a
• Viewing conditions preset → -c source / -d dest, e.g. "Screen → print (typical)" = -c mt -d pp, "Screen → print (D50 booth / critical)" = -c mt -d pc.
• Quality → -q m|h|u (clut resolution). Default High — it's a one-time bake, so runtime isn't a concern.
• Map black to black (RGB→RGB) → -b.
• Optimise for a specific image (optional) — pick an image and ChromIQ runs its existing tiffgamut to build that image's gamut, fed to collink as -g image.gam so the compression is tuned to the colours that are actually in the picture, not the whole working space.
• Expert section (collapsed, matching the app's expert_only pattern): abstract profile -p, bake-in calibration -a <run>.cal, forced white-point -w, manual res -r, gamut-map diagnostic -P, optional 3DLUT export -3.
• Description/maker strings (-D/-M/-A/-C) auto-filled from the project name so the link is self-identifying.

Output destination:

• If the destination profile is one ChromIQ built (it lives in a run/working folder) → the link is saved there as <project>-devicelink.icc, self-identifying and tracked, per the folder-layout conventions.
• If the destination is an arbitrary profile from outside a working folder → the link defaults to next to that profile (<dst>-from-<src>-devicelink.icc), and the Save dialog (ChromIQ's own browser, with the ~/ChromIQ shortcut) lets you redirect it anywhere.

Guards: ICC-v2 only (Argyll writes v2; same guard the soft-proof tool already uses) — I'd bundle v2 copies of the working spaces to avoid surprises.

What about ICC v4 source profiles? I tested this directly: Argyll's engine flatly can't read v4 — collink prints "Warning: ICC V4 not supported!" and aborts. That's a hard Argyll limitation (Graeme Gill never implemented v4), not a ChromIQ choice, so a v4 profile can never be fed to it directly. The fix is to convert the source to v2 first, in tiers:

• Bundle v2 copies of the common working spaces (sRGB, AdobeRGB, ProPhoto, Display P3, Rec.709/2020) so the usual source choice just works and never touches v4.
• Auto-transcode a user-supplied matrix + tone-curve v4 profile to v2 — which is nearly every v4 working/display space, including macOS's own Display P3 / Rec.2020 / ROMM. This class converts exactly (same colorants + tone curves + white point), and ChromIQ already parses ICC internals, so it needs no new dependency.
• LUT-based v4 profiles (some camera/printer profiles, plus v4's PRMG perceptual reference) are supported too: we resample them to v2 via lcms2 — the reference open-source colour engine that already handles v4 correctly, and which ChromIQ already ships through Pillow. So both classes of v4 source are covered, not just matrix ones.

The converted v2 file is a throwaway intermediate — the link bakes in the source's colorimetry, so the v2 copy has no further use. It's written to a temp location and deleted once the link is built (same disposable-tempfile pattern the soft-proof tool already uses), so nothing clutters the working folder.

Why convert rather than fork/patch collink to add v4? I weighed that and it's the wrong trade:

• Adding v4 correctly to Argyll is a deep colour-science job (new v4 tag types + the PRMG perceptual semantics throughout the engine), i.e. weeks–months re-implementing what lcms2 already does — with real risk of subtle intent bugs.
• It would make us maintain an AGPL fork of ArgyllCMS (publish modified source, rebuild for macOS/Windows/Linux on every upstream release) for the sake of one input file.
• v4 only ever appears as a source profile a user brings in — the rest of the pipeline is v2 already — so converting that one file does the same job with a fraction of the effort and no licensing burden.

Net: v4 sources are supported in practice (bundled v2 spaces + exact auto-transcode of matrix profiles, lcms2 for the rare LUT case), while the link Argyll builds stays v2 under the hood.

---

How it maps onto the code (low-risk)

• workflow/collink_runner.py (new) — builds the collink [opts] src dst link args and runs them through the singleton ArgyllRunner, mirroring softproof_runner.py / profcheck_runner.py, with error/warning parsing.
• ui/dialogs/devicelink_dialog.py (new) — the dialog above, built on the shared dialog_masthead() + accent convention (cyan), a TooltipButton (ⓘ) per option with extensive friendly copy, the ui/widgets.py non-native file pickers (open_file_dialog / save_file_dialog, already wired with ICC-folder + ~/ChromIQ sidebar shortcuts) for all browsing, plus progress + result summary.
• v4 conversion helper — extend workflow/icc_info.py (it already parses ICC internals) for the exact matrix transcode, and lcms2 (via Pillow) for the LUT case; both write to a tempfile that's deleted after linking.
• ui/tools_popup.py — one new ToolEntry("device_link", …).
• ui/dialogs/tools_dialogs.py — one new branch in open_tool_dialog() (same place softproof is wired).
• i18n — new strings ×12 catalogs; tests — an arg-building test like the other runners; assets — bundle the v2 working-space profiles.

Phasing:

• Phase 1 (MVP): generate the link (everything above).
• Phase 2 (nice-to-have): "Preview on an image" — reuse the soft-proof cctiff infrastructure to apply the link to a sample image and show before/after + out-of-gamut highlight, so you can judge the gamut mapping in-app.
• Phase 3 (optional): save settings / presets like the other panels.

---

Update — incorporating backtomarfa's replies

Some of this is now settled, and one genuinely valuable new lever surfaced:

• Purpose (Q1) — both consistency and reproduction-grade accuracy. Stable printer/ink/paper setups reused across a photo-book or exhibition series, plus critical art reproduction where a fixed, tested link removes CMM/software-version variability. Matte-paper work — where neither perceptual nor relative-colorimetric is consistently ideal — is a strong target.
• End use (Q2) — Photoshop "Convert to Profile" and RIP integration. Both confirmed.
• New and worth building: a per-image source gamut. Mapping against the actual image's gamut instead of the whole working space is collink's -g image.gam, and ChromIQ already wraps tiffgamut (the tool that produces that gamut file) — so "optimise the link for a specific image" is real and reuses existing code. Added as an optional step.
• Honest reset on one claim: collink does not expose a "knee softness" or "hue-vs-saturation weighting" slider — I checked its full option list. The granularity over Photoshop's three intents comes from (a) a richer set of named gamut-mapping intents, (b) detailed CIECAM02 viewing conditions, (c) the per-image source gamut, and (d) abstract profiles — not free numeric knobs. The RGB→RGB benefits backtomarfa cites (no live Lab round-trip at apply time, fewer rounding errors / less posterization, cleaner saturated primaries) are fair for the delivered link. Bonus: collink can also emit a 3D gamut-mapping diagnostic (-P) and an optional 3DLUT (.cube / eeColor / MadVR) for LUT-based RIPs.

---

Open questions (this is where your feedback steers it)

1. What's the link for — proofing accuracy, or production? → Answered: both — series consistency + critical reproduction (matte paper).
2. End use — Photoshop, a RIP, or direct? → Answered: Photoshop "Convert to Profile" + RIP.
3. Destination scope — is the destination always the printer profile you just built in ChromIQ (I'd auto-fill it, still browsable), or do you want to link any two existing profiles (a canned profile, or one ChromIQ didn't make)? The second makes the profile picker the primary control rather than a convenience.
4. Source side — mostly fixed working spaces (sRGB / AdobeRGB / ProPhoto), or device-to-device (e.g. a press/proof profile → your inkjet)? Which source profiles should ship bundled?
5. Which controls actually matter to you in practice — intent, viewing conditions, abstract profile, baked-in calibration? Anything in my "expert" list you'd promote to the main view, or anything I've listed that's just noise?
6. Defaults — does perceptual + High quality + screen→print viewing conditions match your starting point, or would you set different defaults?
7. Viewing conditions — are the -c/-d CIECAM02 presets something you tune, or should I keep it to two or three named presets?
8. Output expectations — one link per run alongside the ICC is fine, or do you want to batch several source spaces at once?
9. Any reference offset workflow you'd want mirrored, so I'm matching something real rather than guessing?

(Things like which collink mode flag, default black handling, clut resolution, file naming and ICC description strings are mine to decide — I'll just propose sensible values and you correct anything that's off.)

No code yet — this is for you to shape. Honestly the fastest path with someone who knows this area: answer what's easy, and I'll build a rough prototype you can react to — a concrete version will surface the real requirements faster than more questions.

— Claude (via Itsab1989)

[backtomarfa]

outside the prepress world almost nobody even heard about this profile type and i´m not 100% sure about real visible benefits, theoratically going from the source space without a connection space (LAB) should have an advantage, I asked Claude before posting and it agreed:

Warum das für deinen Anwendungsfall relevant ist

Genau dein Wunsch nach präziserer, weniger grober Kontrolle über die Gamut-Kompression lässt sich mit collink tatsächlich umsetzen, weil du hier nicht auf die drei festen Photoshop-Intents beschränkt bist, sondern die Kompressionscharakteristik granular konfigurieren kannst: weicher oder härterer Knee, Priorisierung von Hue-Erhaltung vs. Sättigungserhaltung, separates Quellgamut aus deinem tatsächlichen Bildmaterial statt aus dem generischen Arbeitsfarbraum. Das Ergebnis ist ein einziges, in sich geschlossenes Device-Link-Profil, das du dann z. B. in Photoshop über "Convert to Profile" mit Intent "absolute colorimetric" (wichtig, da Device-Links keine weitere Intent-Wahl mehr erlauben) anwendest, oder direkt im RIP deines Druckertreibers einbindest.

Why this is relevant to your use case

Exactly your desire for more precise, less rough control over the gamut compression can actually be implemented with collink, because you are not limited to the three fixed Photoshop intentions here, but can configure the compression characteristic granularly: softer or harder knee, prioritization of Hue preservation vs. Saturation preservation, separate source gamut from your actual image material instead of from the generic working color space. The result is a single, self-contained device link profile, which you can then e.g. B. in Photoshop via "Convert to Profile" with Intent "absolute colorimetric" (important because device links no longer allow further intent choice), or integrate directly in the RIP of your printer driver.

Wo Device-Links im Inkjet-Bereich trotzdem sinnvoll sind
Sie lohnen sich, sobald du eine wiederkehrende, stabile Kombination hast, etwa wenn du für ein Fotobuch-Projekt oder eine Ausstellungsserie konsequent dasselbe Drucker-Tinte-Papier-Setup über viele Bilder hinweg nutzt. Dann gilt dasselbe Argument wie im Offset: Einmal sorgfältig kalibriert (mit den feinjustierten collink-Parametern, über die wir gesprochen haben), sparst du dir die Live-Berechnung bei jeder einzelnen Bildkonvertierung und hast garantierte Konsistenz über die gesamte Serie. Auch für sehr kritische Reproduktionsaufgaben, etwa Kunstreproduktionen, bei denen exakte, reproduzierbare Farbtreue über viele Drucke hinweg entscheidend ist, kann ein fest definiertes, getestetes Device-Link-Profil dem flexiblen Standard-Workflow überlegen sein, weil es Variabilität durch unterschiedliche CMM-Interpretationen oder Software-Versionen ausschließt.

Where device links in the inkjet area still make sense

They are worthwhile as soon as you have a recurring, stable combination, for example if you consistently use the same printer-inkj-paper setup across many pictures for a photo book project or an exhibition series. Then the same argument applies as in the offset: Once carefully calibrated (with the finely adjusted collink parameters we talked about), you save yourself the live calculation with every single image conversion and have guaranteed consistency over the entire series. Even for very critical reproduction tasks, such as art reproductions, where exact, reproducible color fidelity across many prints is crucial, a firmly defined, tested Device Link profile can be superior to the flexible standard workflow, because it excludes variability due to different CMM interpretations or software versions.

[itsab1989]

Ich werde es nachher mal weiterreichen und schauen was Claude hier dazu sagt. Immerhin scheint es ja zuversichtlich zu sein, dass die Implementierung grundsätzlich möglich ist. Mir fehlt allerdings die Kompetenz, zu beurteilen, ob es am Ende richtig funktioniert.

[backtomarfa]

Google sieht es auch Positiv...

Why Use an RGB-to-RGB DeviceLink? Bypasses Driver Inaccuracies: Standard printing uses the operating system's Color Management Module (CMM) to convert Adobe RGB → Lab → Printer Profile. An RGB-to-RGB DeviceLink forces a mathematical shortcut directly from Adobe RGB → Printer Profile, ignoring the Lab middleman entirely.Preserves Pure Saturated Primaries: Standard Lab conversions often taint highly saturated reds, greens, or blues with speckles of unintended colors. A DeviceLink maps those extreme spectrum points smoothly to the printer's maximum output without unexpected color shifts.Prevents Posterization: Eliminating the intermediate Lab translation minimizes decimal rounding errors, ensuring smooth tonal gradations in photographic skies, vignettes, and fine art shadows.

Ich habe bisher auch nicht an diesen Profiltyp gedacht aber ich beschäftige mich mit der Optimierung für mattes Papier wo Gamut Mapping eine wichtige Rolle spielt und sowohl perzeptiv als auch rel. Farbmetrisch nicht immer optimal sind. DLP sind da vielleicht die Lösung , in einer APP wie deiner ist das für Qulitäts-Besessene vielleicht zugänglicher als mit command line oder spezial Software.

[itsab1989]

(Claude again, on Itsab1989's behalf.)

Thanks — this is really useful, and your RGB→RGB reasoning is sound. The key benefit is exactly that the delivered device-link is one baked RGB→RGB table, so at apply time there's no live source→Lab→printer round-trip, no per-conversion CMM variability, and fewer rounding stages — which is where the cleaner saturated primaries and reduced posterization come from. For a stable printer/ink/matte-paper setup reused across a series, that consistency argument is strong, and matte paper is a great fit because that's where the standard perceptual/relative intents are least satisfying.

One honest correction so we set the right expectation: I went through collink's full option list, and it does not expose a "knee softness" or "hue-vs-saturation weighting" slider. The real granularity over Photoshop's three intents comes from: a richer set of named gamut-mapping intents, detailed CIECAM02 viewing conditions, abstract profiles for manual tweaks, and — the strongest lever for your case — a per-image source gamut (map against the actual image instead of the whole working space). ChromIQ already wraps the tool that builds that gamut, so that one's very doable.

Itsab1989 has given the go-ahead and I'm starting on a first version now (a "Create device-link profile" Tool). If any of the open questions in the plan spark a preference — especially default intent and which source spaces to bundle — drop a note and I'll fold it in.

[itsab1989]

Ich höre das hier gerade zum ersten Mal, aber wenn es klappt, wäre es natürlich toll. Hast du den Plan von Claude gelesen? Stimmst du grob zu? Falls dir zu den Fragen was einfällt, kommentier das gern. Bin gerade mit all meinen 3 Accounts am Limit und muss warten bis ich den ersten wieder nutzen kann.

[itsab1989]

Wenn mein Account nachher einsatzbereit ist, lasse ich zunächst die Fehlerreports von Knut noch durchlaufen, damit die aktuelle Betaversion stabiler wird. Zum Glück scheinen die gröbsten Patzer beseitigt zu sein.
Danach ist das hier dran. Hier habe ich nicht so große Schmerzen. Wir fragen, probieren es und da es als separates Tool konzipiert ist, greift es nicht so tief in bestehende Strukturen ein. Also wenn es absolut schlimm wird, dann entfernen wir es halt wieder.

[backtomarfa]

OK

Ich lerne... Claude liegt richtig.

Einfache DLP Quellfarbraum zu Printerprofile mit Mapping Optionen sind ein Anfang aber wirklich spannend wird das Ganze , wie auch von Claude vorgeschlagen, wenn man den Gamut der Bilder (tiffgamut ) und nicht den eines grossen Arbeitsfarbraums zB Prophoto für das Mapping verwendet, man kann dabei den Gamut aus mehreren Bilder erstellen - zB von einer Serie für Ausstellungs Prints, das müsst klare Vorteile gegenüber den normalen Workflow haben.

[itsab1989]

Ich mache noch eine kleine Detailarbeit, damit die Akzentfarben stimmen und die Icons alle rechts platziert sind. Dann kurzer Test auf meiner Windows VM, damit es da keine bösen Überraschungen gibt. Aber sollte nicht mehr allzu lange dauern.

[itsab1989]

Ok, Claude war wieder etwas faul und hat zuvor erwähnte Expertenoptionen erstmal ausgelassen. Die nehmen wir natürlich noch mit rein, wenn wir einmal dabei sind. Umstrukturieren kann man später natürlich noch.

[itsab1989]

Scrollbalken noch nen Tick zu nah an den Optionen und der Verlauf unten hat ne komische Lücke. Aber wir nähern uns der Sache.

[itsab1989]

So, da ist es:
https://github.com/itsab1989/ChromIQ/releases/tag/v3.13.0-beta.47

Kleiner Disclaimer: In der Beta sind neue / geänderte Optionen nur englisch, weil ich da immer wieder Dinge anpasse und sonst jedes Mal die Texte für 12 Sprachen anpassen müsste. Das verzögert den ganzen Prozess und verbraucht jedes Mal viele Token. Deshalb mach ich das in einem Rutsch, wenn ich denke, dass es fertig ist.

Lass mich bitte wissen, ob es funktioniert wie du es dir vorgestellt hast! Bin echt gespannt! Viel Spaß!

[backtomarfa]

Wow, danke schau mir das morgen an

[itsab1989]

nimm dann das hier - musste nochmal ein Update nachschieben:
https://github.com/itsab1989/ChromIQ/releases/tag/v3.13.0-beta.48

[itsab1989]

https://github.com/itsab1989/ChromIQ/releases/tag/v3.13.0-beta.50

[backtomarfa]

Habe heute Früh ein paar Test Profile generiert , das Tool funktioniert wie es soll, hier meine Beobachtungen:

Mein Testbild hat hoch gesättigte Magenta und Cyan Töne.

Grosser Quellfarbraum Prophoto RGB (im Profile berücksichtigt) - perzeptiv - liefert sowohl via Adobe CMM, Standart Profil, als auch via DeviceLink unbrauchbare Ergebnisse was mich echt überrascht, in beider Fällen wird Magenta zu Orange. auch wenn man den Bild Gamut verwendet was das Ergebnis eigentlich verbessern sollte.

Mittlerer Quellfarbraum ECI RGB (im Profile berücksichtigt) - perzeptiv - hier sehe ich super subtile Verbesserung mit dem DLP.

Vorläufiges Fazit: Ich bin mir noch nicht sicher ob sich der zusätzliche Aufwand wirklich lohnt, Claude war vielleicht etwas zu optimistisch im Ausloben der Vorteile. Wenn du Lust hast könntest du weitere Parameter einfügen wie zB die Mapping Options -i und das mehr Bilder zur Generierung des Bild Gamuts geladen werden können sowie die Kontrolle über den -f Parameter von tiffgamut.

"Image dependent gamut mapping using device links

When images are stored in large gamut colorspaces (such as. Lab*, ProPhoto, scRGB etc.), then using the colorspace gamut as the source gamut for gamut mapping is generally a bad idea, as it leads to overly compressed and dull images. The correct approach is to use a source gamut that represents the gamut of the images themselves. This can be created using tiffgamut, and an example workflow is as follows:

tiffgamut -f80 -pj -cmt ProPhoto.icm image.tif

collink -v -qh -G image.gam -ip -cmt -dpp ProPhoto.icm RGBDestinationProfile.icm Source2Destination.icm

cctiff Source2Destination.icm image.tif printfile.tif

The printfile.tif is then send to the printer without color management, (i.e. in the same way the printer characterization test chart was printed), since it is in the printers native colorspace.

You can adjust how conservatively the image gamut is preserved using the tiffgamut -f parameter. Omitting it or using a larger value (up to 100) preserves the color gradations of even the lesser used colors, at the cost of compressing the gamut more.
Using a smaller value will preserve the saturation of the most popular colors, at the cost of not preserving the color gradations of less popular colors.

You can create a gamut that covers a set of source images by providing more than one image file name to tiffgamut. This may be more efficient for a group of related images, and ensures that colors are transformed in exactly the same way for all of the images.

An alternative generating a gamut for a specific set of images, is to use a general smaller gamut definition (i.e. the sRGB profile), or a gamut that represents the typical range of colors you wish to preserve.

The arguments to collink should be appropriate for the output device type - see the collink examples in the above section."

[itsab1989]

(Claude again, on Itsab1989's behalf.)

Thanks — this is exactly the hands-on testing that moves it forward, and your ProPhoto-vs-ECI observation put the finger on a real bug.

Why the image gamut wasn't helping (now fixed). ChromIQ was building the per-image gamut in Lab, while collink does its perceptual gamut mapping in CIECAM02 Jab appearance space. So the "optimise for an image" gamut was described in a different space than the mapping that consumes it — it barely bit. It now follows Argyll's documented recipe: tiffgamut -pj -c<viewcond> (appearance space + the link's own viewing conditions), matched to collink's -cmt. On a big source like ProPhoto that's the difference between "no visible change" and an actual effect.

What I added from your notes (v3.13.0-beta.51):

• Image-gamut detail — exposes tiffgamut -f (the popularity filter you quoted). Favour the main colours (≈ -f 80, Argyll's suggested start) tightens the gamut around the colours actually in the image so their saturation is held; Preserve all gradations keeps the rare colours.
• Multiple images → one shared gamut — add a whole exhibition series and every image is mapped identically, exactly the case you described.
• More -i gamut-mapping intents — including Luminance-preserving perceptual (lp), often the best starting point for matte fine-art paper where plain perceptual/relative disappoint.
• Workflow help — the tooltip now spells out your Photoshop finding: turn on Advanced in Convert to Profile (device-links only show up there), pick it under Device Link, print with the printer's colour management off.

The honest bit: you're right that on a huge space like ProPhoto + plain perceptual, strong magenta drifting toward orange is largely inherent — that's a lot of gamut to crush. Your ECI-RGB result fits: a source space closer to the printer's gamut leaves less to compress. The new levers aim straight at that — a tighter image gamut (-f), appearance-space alignment, and lp — so the mapping has less to do and holds your key colours better. I've kept the tooltips honest that the win is real but situational, not magic.

Could you re-run your magenta/cyan test on beta.51?

1. With Optimise for specific images on (now appearance-space) — does ProPhoto perceptual still go orange, or does it hold?
2. Does Luminance-preserving perceptual on matte paper beat plain perceptual / relative for you?
3. Is the Image-gamut detail control useful, and are those presets right — or would you rather set a raw 0–100 -f number?

https://github.com/itsab1989/ChromIQ/releases/tag/v3.13.0-beta.51

— Claude (via Itsab1989)

[itsab1989]

(Claude, on Itsab1989's behalf — small follow-up.)

Quick update on my own open question above ("presets vs. a raw -f number"): I did both. Image-gamut detail keeps the friendly presets and adds a Custom… entry that reveals a raw 0–100 spinner for tiffgamut's -f, so you can dial the popularity filter exactly when you want to — while the presets stay for the common cases.

It's in v3.13.0-beta.53 (on top of beta.51's appearance-space image-gamut fix). The three test questions from my previous reply still stand whenever you get to it — no rush.

https://github.com/itsab1989/ChromIQ/releases/tag/v3.13.0-beta.53

— Claude (via Itsab1989)

[backtomarfa]

Zum Workflow, man muss die erweiterten Einstellung in Photoshop für Profil Konvertieren aktivieren erst dann hat man Zugriff auf die DeviceLink Profile - ich habe für beide dann zur Sicherheit kein Farbmanagment via Profil zuweisen aktiviert und so an Canon P&L geschickt und dort ohne Farbmangment gedruckt.

[itsab1989]

Ich habe dein Feedback weitergereicht und lasse Claude gerade daran arbeiten. Aber ich ziehe spontan erstmal daraus, dass es grundsätzlich funktioniert - ob sich der Aufwand nun lohnt erstmal außer Acht gelassen.
Bei mir ist die KI manhcmal auch etwas überschwänglich was Vorteile oder Risiken angeht...

[itsab1989]

Schauen wir mal

[backtomarfa]

Habe die Profile von Claude analysiert lassen, der Theorie nach sollte ja bei der Konvertierung des grossen ProPhoto Farbraums zum Drucker Gamut das DLP einen Vorteil haben doch das schein nicht der fall zu sein, es gibt zwar einen kleinen Fehler im DLP falscher Profil Platzhalter aber die Massive notwendige Kompression stösst an Grenzen. Generell schneiden die DeviceLinks nach Claud´s analyse schlechter ab:

Auch der auf ohnePar zielende Device-Link zeigt dieselbe Magenta-Hue-Drehung (~8° wärmer als die farbmetrisch korrekte eciRGB-Richtung) und dasselbe Cyan-Fold-back (Chroma steigt bis 90%, fällt bei 100% wieder ab).
Da dieser Fehler nun in zwei unabhängig gebauten Device-Links (einer gegen die adaptierte ECI-1-Charakterisierung, einer gegen die unadaptierte ohnePar-Charakterisierung) in praktisch identischer Größenordnung auftritt, spricht das noch deutlicher dafür, dass die Ursache im Perceptual-Gamut-Mapping-Algorithmus von ChromIQ selbst liegt (in der Art, wie er die Kompression von eciRGB v2 in Richtung des kleineren Matte-Papier-Gamuts nahe den Primärvalenzen berechnet) – und nicht an einer der beiden spezifischen Drucker-Charakterisierungen liegt.

[itsab1989]

gebe ich mal so weiter

[itsab1989]

bin gespannt:

[itsab1989]

(Claude, on Itsab1989's behalf — I ran this down with real measurements, not theory.)

Thanks for the careful analysis — your measured numbers are solid, and they let me pin down exactly what's happening. One correction up front, then the evidence.

ChromIQ has no gamut-mapping algorithm of its own. It's a thin wrapper that assembles a collink command line and runs the ArgyllCMS binary — it never touches the resulting .icc. So a ChromIQ device-link is byte-for-byte collink's output, and the perceptual mapping is entirely Argyll's gammap code. Every link below I built by running collink directly, outside ChromIQ, and they reproduce your effect exactly — so the cause isn't a ChromIQ algorithm; there isn't one to be at fault.

The magenta rotation is the perceptual intent, and it's controllable. Measured, full magenta, ProPhoto → a real printer profile (printer-Lab hue vs the colorimetric target):

intent	hue	Δ vs colorimetric
colorimetric target	−25.1°	—
Perceptual -ip (default)	−19.2°	+3.6° warmer ← your effect
Luminance-preserving perceptual	−20.3°	+2.5°
Accurate colours (-ir)	−22.7°	+0.1°
Lab colorimetric (-irl)	−22.8°	0.0°

Perceptual deliberately rotates hue to keep gradations smooth; switch the intent and the rotation vanishes. Your ~8° is plausible on a more-compressed matte gamut. And your strongest point — "the same rotation in two independent links, so it's systematic" — is exactly right, but it points at the perceptual intent, not ChromIQ: both links used the same intent through the same engine, so of course they match.

Cyan fold-back: on my semigloss profile cyan chroma rose monotonically to 100% — no peak-at-90%-then-drop. So that one is specific to your matte gamut near the cyan primary (a property of Argyll's mapping into that compressed gamut), not a systematic bug.

"Wrong profile placeholder": good catch — it's the informational pseq (profile-sequence) tag, whose destination entry was blank because ChromIQ's colprof-built printer profiles didn't carry device-ID tags (the source showed ProPhoto's own CRT/R709 self-labelling). It's descriptive metadata only — it does not affect the A2B LUT that does the conversion — but it shouldn't be blank. Fixed: ChromIQ now stamps manufacturer/model on the profiles it builds, so new device-links carry a proper sequence (verified).

ProPhoto vs ECI: your instinct is right, and it's about chroma, not hue — a smaller source needs far less compression. Measured chroma crush: ProPhoto magenta 160→73 vs sRGB 111→70; hue rotation was similar across sources.

Bottom line: nothing in the mapping is a ChromIQ defect — it's Argyll's perceptual mapping, faithfully wrapped and fully intent-selectable. Two changes shipped from this: (1) the Rendering-style tooltip now notes that perceptual trades hue for gradation and points hue-critical work to Accurate; (2) the device-ID/pseq fix above. Both in the next beta.

If you want hue kept exact on those magentas, try Accurate colours (≈0° rotation here) or Luminance-preserving perceptual on matte — and a source closer to your printer's gamut (like ECI) will always beat ProPhoto for gradation.

— Claude (via Itsab1989)

[itsab1989]

(Claude again, on Itsab1989's behalf — I went spelunking in the ArgyllCMS source to find the actual mechanism, so this isn't hand-waving.)

Short version: I found exactly where your magenta shift comes from in Argyll's code, and it turns out to be a deliberate, named feature of the perceptual gamut mapping — not a bug, and (as you'd expect by now) nothing ChromIQ does. Here's the friendly tour.

The mechanism has a name: "cusp alignment"

Picture each colour space as a 3-D solid with pointy corners — one for the most saturated red, one for magenta, one for cyan, and so on. Those corners are called cusps. When Argyll's perceptual engine squeezes your big source solid (ProPhoto) down into the printer's smaller solid, it doesn't just shrink it straight inward — it also gently rotates each source corner so it lines up with the matching corner of the printer. The intent is kind: keep "the most saturated magenta you had" pointing at "the most saturated magenta the printer can actually make," so the picture still feels natural after compression.

The catch: on your matte paper, the printer's magenta corner sits at a slightly warmer hue (and much lower saturation) than ProPhoto's magenta corner. So when Argyll snaps your magenta onto the printer's magenta corner, it drags the hue warmer. That's your ~8°.

It's tunable — and Argyll sets the dial by intent. I read the exact numbers.

In gamut/gammap.c there's a table of "cusp hue alignment" weights (0 = don't rotate at all, 1 = snap fully onto the printer's corner):

• Perceptual (p, the default): 0.2 — a gentle-but-real pull.
• Luminance-preserving perceptual (lp): 0.0 — their comment literally says "preserving lightness and hue has the highest priority… chroma is basically sacrificed."
• Saturation (s/ms): 0.6 — pulls harder, for punch.

There's also a second knob, twist power, set to 2.0 ("late curve"), meaning the rotation barely touches muted colours and does almost all its work right at the saturated tip. That's why the shift is invisible on pastel magentas and largest on the fully-saturated one — exactly the shape you measured.

Why "Accurate colours" makes it go away

In xicc/xicc.c each intent also has an on/off switch for this whole perceptual step. Perceptual leaves it fully on; Accurate colours (relative colorimetric, -ir) turns the perceptual surface weighting to zero, so no cusp rotation happens at all. Measured on a real printer profile:

intent	magenta hue vs colorimetric
Perceptual (default)	+3.6° warmer
Luminance-preserving perceptual	+2.5°
Accurate colours	+0.1°
pure Lab colorimetric	0.0°

So if a magenta hue must stay exact, Accurate colours (or lp) is the lever — both are in the Rendering-style dropdown, and the tooltip now spells this out.

A detail you'll appreciate

Magenta and cyan get no special protection in that table. Yellow has a hand-tuned exception ("treat yellow differently, to get purer result"), and there's even a blue-hue-preservation case in the code — but it's commented out (#ifdef NEVER). So your two colours fall straight through to the generic 0.2 pull with nothing to catch them. That's a Graeme-Gill design decision, not something ChromIQ can or should override.

Your cyan fold-back

Chroma rising to ~90% then dropping at 100% fits the same picture: that "late-curve" twist pulls hardest right at the tip, and when it's squeezing into a tiny matte cyan corner, the very last sliver of chroma can get folded back as it's yanked toward the printer's cusp. On my larger semigloss profile it didn't happen (chroma climbed all the way) — so it's a property of how compressed your matte cyan is, not a systematic error.

Net

Your analysis was right that it's systematic and reproducible — it's just systematic in Argyll's perceptual algorithm, by design, reproduced identically whether ChromIQ or a raw collink command builds the link. For hue-critical magentas: reach for Accurate colours or lp, and keep leaning on a source space closer to your printer (your ECI instinct) so there's simply less to compress in the first place.

Happy to dig further into any of this — it's a genuinely interesting corner of the pipeline.

— Claude (via Itsab1989)

[backtomarfa]

Danke, wieder was gelernt. Das hat aber praktische Konsequenzen, viel Fotografen haben gelernt den größten Farbraum zu verwenden und wenn notwendig den Druckerprofil die Kompression zu überlassen, das ist aber der Claude Analyse nach kein guter weg mit Argyll Profilen, ich habe leider keinen Profilemaker mehr um das zu vergleiche. Ich persönlich hatte immer Zweifel ob das wirklich sinnvoll ist da reale Bilder, keine synthetischen Farben oder selbstleuchtende Objekte relative kleine Gamuts haben die gut in gängige Farbräume wie Adobe RGB passen. Bin gespannt welche Ergebnisse die weiteren Intends liefern.

[itsab1989]

Ich gebe das nochmal zu Claude weiter. Vielleicht hat es da nochmal Feedback zu.
Ich selbst habe immer nur sRGB für meine Bilder verwendet. Als ich angefangen habe hat mein damaliges MacBook Display nicht mehr abgedeckt als und ich fand es irgendwie nicht direkt nachvollziehbar mit Farben zu arbeiten, die ich an meinem Display gar nicht sehen konnte.
Durch die ganze Geschichte mit dem Programm hier habe ich mal Vergleichsdrucke gemacht und zumindest gesehen, dass bei speziellen Tesbildern AdobeRGB im Druck bessere Ergebnisse (teilweise sattere Farben) erzielt. Für meinen persönlichen Stil ist das aber gar nicht so stark von Bedeutung, da ich Bilder tendenziell leicht entsättige

[itsab1989]

(Wieder Claude, im Auftrag von Itsab1989.)

Du hast da etwas wirklich Wichtiges erkannt, und dein Instinkt ist richtig — ich würde sagen, das ist eine der nützlichsten Erkenntnisse aus diesem ganzen Thread.

Die Angewohnheit „den größten Arbeitsfarbraum nehmen und die Kompression dem Profil überlassen" gehört tatsächlich hinterfragt, genau wie du vermutest.

Wenn Argyll Farben so komprimiert, dass sie auf den Drucker passen, komprimiert es gegen die Hülle des Quellfarbraums, den du ihm gibst — nicht gegen die Farben, die tatsächlich in deinem Bild sind. Gibst du ihm ProPhoto, nimmt es an, dein Bild könnte Farben bis hinaus in die äußersten Ecken von ProPhoto enthalten, und quetscht deshalb alles nach innen, um für diese Möglichkeit Platz zu schaffen — selbst wenn dein echtes Foto diesen Farben nie auch nur nahegekommen ist. Die Cusp-Rotation, über die wir gesprochen haben, wird dann auf Farbtöne angewendet, die gar nicht hätten verschoben werden müssen, und deine tatsächlich im Gamut liegenden Farben werden stärker komprimiert als nötig.

Ein Vergleich: Es ist, als würdest du einem Umzugsunternehmen sagen „mein Hausrat könnte eine Villa füllen", woraufhin sie sicherheitshalber alles extrem dicht packen — obwohl du in Wirklichkeit eine überschaubare Einzimmerwohnung umziehst. Gib ihnen die echte Inventarliste, und nichts wird zerdrückt.

Und deine andere Beobachtung ist der Schlüssel zum Ganzen.

Echte Fotos — reflektierende Oberflächen, Haut, Laub, Himmel — haben erstaunlich kleine Gamuts, die bequem in AdobeRGB passen. Die wirklich weitgamutigen Fälle sind die Ausnahmen: gesättigte Blüten, Neon, durchleuchtete Transluzenz, manche gefärbten Textilien. Für die meiste Arbeit ist AdobeRGB also ein völlig sinnvolles Zuhause, und ProPhoto zahlt sich erst aus, wenn du diese extremen Farben wirklich hast.

Die saubere Lösung ist genau das, was du vorhin vorgeschlagen hast: das Gamut pro Bild.

Das ist die „echte Inventarliste". tiffgamut misst die Farben, die tatsächlich in deinem Bild vorkommen (oder in deiner ganzen Ausstellungsserie), und der Link komprimiert dann gegen dieses Gamut, nicht gegen die Hülle von ProPhoto. So kannst du in einem großen Farbraum bearbeiten, wenn du magst, und bekommst trotzdem die sanftestmögliche Kompression — das Beste aus beiden Welten. Deshalb ist das für deinen Anwendungsfall meiner Meinung nach der interessanteste Teil des Tools.

Zu den Intents — ich bin auch neugierig, deshalb hier, was dich erwartet, damit du deine Tests ausrichten kannst:

• Farbtreu (relativ farbmetrisch): hält den Farbton exakt (die ~0°, die wir gemessen haben), beschneidet, was nicht passt — am besten, wenn ein bestimmter Farbton sich nicht bewegen darf.
• Luminanzerhaltend perzeptiv (lp): hält Helligkeit und Farbton, opfert die Sättigung — auf mattem Papier oft am schönsten, wo man die Sättigung ohnehin nicht halten kann.
• Perzeptiv: die glatte Standard-Wahl für sanfte Abstufungen, um den Preis dieser Farbton-Verschiebung.

Probier jedes mit eingeschaltetem Bild-Gamut, von einem Quellfarbraum nah an deinem tatsächlichen Inhalt — genau diese Kombination ist es, wo die Unterschiede (und die Vorteile gegenüber dem „großer Raum, lass komprimieren"-Weg) am deutlichsten werden.

Und Itsab1989 — deine sRGB-Vergangenheit ist völlig nachvollziehbar, nichts, wofür du dich entschuldigen müsstest.

„In dem bearbeiten, was dein Display tatsächlich zeigen und verlässlich beurteilen kann" ist eine solide Disziplin — und genau deshalb hast du gesehen, dass AdobeRGB bei Testbildern gesättigtere Drucke liefert: sRGB beschneidet manche gesättigten Grün- und Cyantöne, bevor sie überhaupt den Drucker erreichen, sodass der Drucker gar nicht die Chance bekommt, sie wiederzugeben. Für einen Stil, der leicht entsättigt, ist der praktische Unterschied gering — dein Workflow ist gut so.

Die eigentliche Erkenntnis aus all dem ist nicht „größer ist besser", sondern den Arbeitsfarbraum an deinen tatsächlichen Inhalt und deinen Monitor anpassen, nicht an ein Dogma — und genau dahin tendiert ihr beide ohnehin schon aus dem Bauch heraus.

— Claude (via Itsab1989)

[backtomarfa]

Nach weiteren Test denke ich die Schuld für das massiv nach orange gekippte Bild liegt bei der Canon Software oder der Kommunikation mit Photoshop. Ich kann es reproduzier und es ist sehr strange. Test Charts ohne Profil werden korrekt ausgegeben
die in PS umgewandelten und mit "ohne Farbmanagment "markierten Dateien verhalten sich anders vielleicht liegt es an der Apple CMM die Canon wahrscheinlich verwendet.

Druckt man mit perzeptiv aus C P&L erhält man mit einen mit basic Einstellungen erstellen Profil , also auch keinen Quell Gamut die höchsten Sättigungen im Druck, verwendet am einen Farbraum - ECI RGB - ist die Sättigung geringer und der Druck ist etwas heller, die Bilddatei hat ECI RGB eingebettet. Die Lehre daraus colprof komprimiert also offensichtlich den Gamut mehr als notwendig wenn ein Quellfarbraum verwendet wird, damit machen aber die DeviceLinks in der Folge keinen Sinn will man maximal mögliche Sättigung auf matten Papier. Ich denke nur Graeme W. Gill selbst könnte das wirklich aufklären und uns weiterhelfen.

Praktisch gesehen funktioniert alles gut auch luminanzerhaltend perzeptiv. liefert schöne Ergebnisse nur im direkten Vergleich zeigen sich die Unterschiede.

Danke für deine Arbeit !

[itsab1989]

Mir fällt die Beurteilung dessen leider sehr schwer. Unter macOS macht mir mein Canon Drucker allerdings auch Probleme. Claude hat festgestellt, dass teilweise falsche Papier IDs an den Drucker gesendet werden und es deshalb zu Abweichungen kommt. Außerdem darf ich im Treiberdialog nicht irgendwo auf abbrechen klicken, weil sonst Einstellungen verändert werden.

[itsab1989]

(Wieder Claude, im Auftrag von Itsab1989.)

Zwei sehr gute Beobachtungen — und zu beiden habe ich diesmal nachgemessen bzw. im Argyll-Quellcode nachgeschaut, statt zu raten. Kurz gesagt: du liegst bei beidem richtig, und für das eine gibt es sogar eine klare Lösung.

1. Das Orange-Problem: dein Instinkt stimmt — es ist der Druck­pfad, nicht das Mapping.

Der entscheidende Unterschied ist, wie die beiden Dateien zum Drucker kommen:

• Testcharts druckt ChromIQ roh (lp -o raw) — der Weg umgeht ColorSync und die Farbverwaltung des Canon-Treibers komplett. Der Treiber fasst die Zahlen nie an.
• Ein in Photoshop umgewandeltes Foto, das du über Canon Print & Layout druckst, läuft dagegen durch den Canon-Treiber. Und der PRO-300-Treiber unter macOS ist dafür bekannt, still Farbverwaltung anzuwenden — selbst wenn „Keine Korrektur“ eingestellt ist. Deine Device-Link-Datei liegt da schon im Drucker­farbraum, bekommt aber vom Treiber noch eine zweite Transformation aufgedrückt → Orange.

Deshalb: Chart korrekt, PS-Datei daneben. Nicht das Device-Link-Mapping ist schuld, sondern der Treiber, der doppelt verwaltet — genau die Apple-CMM-Vermutung, die du hattest.

Der eigentlich korrekte Device-Link-Workflow ist übrigens der, den du selbst aus den Argyll-Docs zitiert hast: Link mit cctiff auf das Bild anwenden → druckerfertiges TIFF → das genauso roh drucken wie das Chart. Dann fasst kein Treiber-CM die Farben mehr an. Naheliegende Idee für ChromIQ: ein Bild durch den Device-Link schicken und roh drucken (so wie die Charts) — damit wäre der Treiber komplett umgangen und Device-Links auf dem PRO-300 erst richtig nutzbar. Das setze ich mal auf die Liste.

2. „colprof komprimiert mehr als nötig“ — fast; ich habe den genauen Grund gefunden.

In colprof heißt die Option -s: „Apply gamut mapping to output profile perceptual B2A table.“ Das Entscheidende: ohne -s (also ein Basisprofil) macht colprof gar kein echtes perzeptives Gamut-Mapping — die „perzeptive“ Tabelle eines Basisprofils ist praktisch nahezu farbmetrisch (sie clippt an die Gamut-Grenze und behält damit die maximale Sättigung).

Ein Device-Link hat dagegen immer einen Quellfarbraum, also macht collink echtes perzeptives Mapping → es komprimiert → weniger Sättigung, etwas heller. Genau deine Beobachtung. Es ist also nicht „colprof komprimiert zu viel“, sondern: das Basisprofil komprimiert perzeptiv praktisch gar nicht, der Device-Link tut es.

3. Aber: Device-Links sind für maximale Sättigung nicht sinnlos — du hast die zwei sättigungs­ärmsten Absichten getestet.

Messung, Volltöne, ProPhoto→dein Drucker, reproduzierte Chroma im Druck­farbraum:

Absicht	Magenta Chroma / L*	Cyan Chroma / L*
Luminanzerhaltend perzeptiv (lp)	61.4 / 67.5	35.7 / 78.1
Perzeptiv	72.8 / 59.0	53.1 / 68.1
Farbtreu (rel. farbmetrisch)	75.4 / 56.5	49.7 / 72.4
Sättigung (-is)	83.5 / 54.5	65.9 / 60.7

Zwei Dinge fallen auf:

• lp liefert die geringste Chroma und die hellsten Werte — exakt dein „geringere Sättigung, etwas heller“. Deine Beobachtung ist also messbar bestätigt.
• Die Sättigungs-Absicht (-is) liefert die höchste Chroma — sogar mehr als der reine farbmetrische Clip. Sie tauscht dafür etwas Helligkeit gegen Sättigung (geht dunkler, wo das Drucker­gamut breiter ist).

Heißt praktisch: willst du maximale Sättigung auf mattem Papier, nimm einen Device-Link mit Sättigungs-Absicht (oder farbtreu, wenn die In-Gamut-Farben exakt bleiben sollen und der Rest hart clippen darf) — nicht perzeptiv oder lp, denn die sind per Design die weichen, sättigungs­opfernden Modi. Der Device-Link ist also nicht das Problem, nur die gewählte Absicht.

Zu Graeme Gill

Klar, er wäre die letzte Instanz — aber zwischen dem Quellcode (gammap.c / xicc.c) und diesen Messungen ist das Bild eigentlich schon ziemlich rund: alles Beobachtete lässt sich sauber auf Argylls Design zurückführen, nichts davon ist ein Fehler in ChromIQ oder in Argyll.

Und schön zu hören, dass lp dir schöne Ergebnisse liefert — für matte Fine-Art-Papiere ist das oft genau der richtige Kompromiss. Danke dir fürs gründliche Testen, das bringt das Ganze wirklich weiter!

— Claude (via Itsab1989)

[itsab1989]

(Claude, im Auftrag von Itsab1989.)

Kurzes Update: Das neue Tool ist fertig und in v3.13.0-beta.56 — genau als Antwort auf das Orange-Problem.

„Device-Link auf ein Bild anwenden“ (Tools-Menü) schickt deine Bilder mit cctiff durch den Device-Link und speichert neben jedem eine druckfertige Datei <name>-printready.tif. Diese liegt bereits in den eigenen Farben des Druckers, ohne Profil — genau die Datei, die du roh druckst (Farbverwaltung des Druckers aus, so wie ChromIQ die Testcharts druckt) oder in deinen RIP lädst. Damit umgehst du den Treiber, der die Datei sonst ein zweites Mal verwaltet — die Ursache des Orange-Stichs.

Ein paar Details, die dir vielleicht gefallen:

• Mehrere Bilder auf einmal (z. B. eine ganze Serie).
• Quellfarbraum-Autokorrektur: Der „Device-Link erstellen“-Schritt legt jetzt eine kleine .source.icc-Datei neben den Link. Das Anwenden-Tool liest sie, prüft das eingebettete Profil jedes Bildes und wandelt es bei Bedarf zuerst in den Quellfarbraum des Links um — so stimmt das Ergebnis auch, wenn dein Bild noch nicht im richtigen Farbraum war. Bei fremden Links ohne diese Datei gibt es einen klaren Hinweis.
• Bewusst ohne In-App-Druck: Unsere Roh-Druckpipeline gibt es nur unter macOS und ist noch nicht zu 100 % erprobt, also erzeugt das Tool nur die Datei — die du dann genauso druckst wie deine Charts, oder im RIP verwendest. Dadurch ist es plattformübergreifend.

Wichtig fürs Testen: Die Autokorrektur greift nur bei Links, die du mit beta.56 neu erstellst (wegen der .source.icc-Datei). Und für maximale Sättigung auf matt weiterhin die Sättigungs-Absicht ausprobieren.

Bin gespannt, ob damit der Orange-Stich verschwindet! Danke nochmal fürs viele Testen.

— Claude (via Itsab1989)

[backtomarfa]

Danke, das Perzeptiv dann in Wahrheit rel. Farbmetrisch ist habe ich auch schon herausgefunden, inklusive wirksamer BPC...hinter jeder Tür eine neue Überraschung.

[itsab1989]

Das Thema Farbmanagement ist ein endloses Rabbit-Hole...
Weil Claude es vorgeschlagen hat, habe ich das eine Tool noch zusätzlich reingebaut. Keine Ahnung, ob es einen riesigen Mehrwert bietet, aber es kostet ja nichts.

[backtomarfa]

Du sagst es, unsere Diskussion zeigt wie komplex die Dinge werden dringt man nur etwas tiefer ein, ich beschäftige mich auch mit Kamerakalibrierung der selbe Wahnsinn. Google AI findet Perceptual Appearance irgendwie besser als Luminance Preserving Perceptual auf das Claude offensichtlich steht, praktisch verwendet hat das wohl sowieso niemand darum finden man auch keine wirklichen Anwendungsberichte und reale Erfahrungen sonder erdichtete Meinungen unserer AI Freunde. Deine Canon Treiber Geschichte ist beispielhaft, ich habe seit Monaten ein Airplay, Sonos Problem, je nach Fragestellung gibt es unterschiedliche Schuldige oder Lösungsansätze funktioniert hat nichts.

[itsab1989]

Dabei sollte AI doch alle unsere Probleme lösen... ;)
Das mit der Kamerakalibrierung fange ich gar nicht erst an. Ich glaube ich tue mir am Ende keinen Gefallen damit...

[backtomarfa]

Hast du irgend ein Feedback zu den devicelinks bekommen ? Es wäre sicher nützlich wenn andere das auch testen und zu ihren üblichen Workflows vergleichen. Ich habe mich weiter mit der Sache beschäftigt, nachdem das doch etwas komplexer ist hier ein praktische Ablauf :

1 . Das Grund Druckerprofile braucht keine perzeptive Tabelle, ! Also keinen definierten Quell Farbraum oder sonstige perzeptive Tunings. (Das war eine Fehlerquelle bei mir )

2. Perceptual Appearance ist wohl universeller und besser geeignete auch für Vergleiche zu anderen Standard Profilen als Luminance Preserving da kein Erhalt der Helligkeitsabstufung auf Kosten der Sättigung erzwungen wird was besser bei matten Papieren ist. Die unterschiede sind allerdings nicht riesig aber sichtbar. Bei meinen Motiv ist Perceptual Appearance ästhetisch klar besser.

3. Erst im DeviceLink wird der Quellgamut für die Transformation festgelegt mit den Arbeistfarbraum oder Bild-Gamut

4. In PS oder CIQ wird in dann das Bild mit den Device Linke konvertiert und ohne Farbmanagment an den Drucker geschickt., aber....

Ich bin nun sicher das es es unmöglich ist egal aus welcher Anwendung auch immer mit der Einstellung ohne Farbmangment brauchbare Ergebnisse mit OSX Tahoe zu erreichen ! Der einzige weg ist Canon Farbe ohne Farbkerrektur. Auch drucken aus Canon P&L funktioniert nicht daher mein Problem mit dem orange shift. Als Test kannst du vor den Drucken im Treiber die Option öffnen in Vorschau wählen, bei gewählten kein Farbmangment erkennt man sofort die zusätzliche Farb- Transformation. Das heisst also im Klartext die Empfehlung von Calibrite ist der einzig verlässliche weg !

[itsab1989]

Es gibt bei dem Thema ein paar sehr Interessierte, die ab und zu was von sich hören lassen, aber breit gefächertes Feedback bekomme ich nicht und wenn dann eher mit Verzögerung. Zu diesen Tools bisher noch gar nichts, aber sie sind auch erst seit gestern implementiert und auch nur in der Beta. Gerade ist wieder für eine Woche Claude Fable am Start. Wenn ich wieder zu Hause bin, werde ich die Infos von dir nochmal weiterreichen und schauen was es dazu sagt.

[itsab1989]

(Claude, im Auftrag von itsab1989)

Danke für den ausführlichen Praxis-Ablauf — der deckt sich sehr gut mit dem, was wir hier gemessen haben, und dein macOS-Befund ist der eigentliche Knackpunkt. Der Reihe nach:

1–3 (Profil-Aufbau): stimmt genau.

• Das Basis-Druckerprofil sollte rein kolorimetrisch sein — keine perzeptive Tabelle, kein Quellfarbraum. colprof ohne -s macht keine perzeptive Kompression; das Gamut-Mapping übernimmt erst der Device-Link. Ein perzeptiv „vorgetuntes" Basisprofil würde doppelt komprimieren — daher war das bei dir zurecht eine Fehlerquelle.
• Perceptual Appearance vs. Luminance Preserving: deine Beobachtung passt zur Messung. lp erhält die Helligkeitsabstufung und opfert dafür Chroma → auf mattem Papier wirkt es flauer. Falls du mal maximale Sättigung gegentesten willst: die Sättigungs-Intent (-is) lag bei uns für Magenta/Cyan klar über perceptual und lp.
• Quellgamut erst im Link (Arbeitsfarbraum oder Bild-Gamut): korrekt, genau so ist es gedacht.

4 (macOS Tahoe – der Knackpunkt): deine Diagnose ist goldrichtig, und es gibt einen technischen Grund.
„Kein Farbmanagement" im Druckdialog schaltet nur das ColorSync der Anwendung ab — es stoppt nicht die eigene Farb-Transformation des Canon-Treibers. Der rendert dann mit seiner Default-Aufbereitung, und genau die siehst du in der Vorschau als zusätzlichen Shift (dein Orange). Erst wenn du im Treiber selbst „Canon Farbe → ohne Farbkorrektur" wählst, fasst der Treiber wirklich nichts mehr an — und das ist bei einem Device-Link genau das Ziel: der Link hat die Transformation Quelle→Drucker schon gebacken, das Bild ist bereits druckerspezifisch, der Treiber darf nichts mehr machen. Insofern deckt sich das exakt mit Calibrites Empfehlung.

Wie ChromIQ da reinpasst:

• Charts druckt ChromIQ über lp -o raw — das umgeht ColorSync und die CUPS-Filter komplett. Deshalb sind die Messungen korrekt; der Treiber-Shift greift hier gar nicht.
• Für Fotos erzeugt das Werkzeug „Device-Link auf ein Bild anwenden" eine druckerfertige TIFF (bereits in Druckerfarben, ohne eingebettetes Profil). Die druckst du dann „roh" wie ein Chart bzw. über den Treiber mit „ohne Farbkorrektur" — oder gibst sie in einen RIP. Das ist genau der verlässliche Weg, den du beschreibst, nur als fertige Datei.

Zu deinen früheren Wünschen: die volleren -i-Intents, mehrere Bilder für den Bild-Gamut und die -f-Kontrolle von tiffgamut sind seit Beta 51 drin; der Bild-Gamut läuft jetzt in CIECAM02-Jab (-pj -c…), damit -g/-G überhaupt greift.

Ehrliche Einordnung bleibt: ProPhoto + perzeptiv bei hochgesättigtem Magenta ist teils inhärent grenzwertig — ein riesiger Quellgamut muss stark gequetscht werden. ECI als Quelle (oder gleich die Sättigungs-Intent) trifft realistische Bildfarben besser. Die Regler helfen, sind aber kein Zauber.

Bleib gern dran mit den Tests — der Tahoe-Befund ist wirklich wertvoll.

[backtomarfa]

Ich denke wir haben ein doppel Problem, A die Apple CMM selbst und B die Canon Papierprofile die zwangsweise angewendet werden auch wenn man das Farbmanagment ausschaltet. Warum man im Netz dazu nichts findet ist mir ein Rätsel . Die Aussage der Canon Leute das Canon P&L direkt mit den Drucker kommuniziert scheint auch so nicht zu stimmen. Ich beschäftige mich schon lange mit Apple Farbmanagment aber das ist unglaublich..

https://youtu.be/adOtIj9EnCk

[itsab1989]

Dein Video ist privat, ich kann es nicht anschauen.

[backtomarfa]

https://youtu.be/adOtIj9EnCk sorry, das was die schreiben ist BS

[itsab1989]

Naja, ist halt damit man Ruhe gibt. Die müssten viel mehr solche Fehlerberichte bekommen, damit ein Zwang bestünde, etwas zu unternehmen. Aber ich glaube auch ganz ehrlich, das viele Nutzer das nichtmal bemerken. Jemand, der unter meinem YouTube Video kommentiert hat, meinte auch, dass mein Fehler bei ihm unter Tahoe nicht auftreten würde. Andersrum läuft es bei mir mit Epson besser als mit Canon...

https://youtu.be/zLnS7CkQ5O0?is=ZrvDVwNSGJ3HhXhr

Schaue jetzt mal dein Video an.

Edit: Habe eben erst festgestellt, dass du der Gleiche bist, der auf YT kommentiert hat. Aber ist doch "toll" wie das alles funktioniert - nicht...

[backtomarfa]

Habe Adobe kontaktiert: Um rohe Farbmuster ohne jegliches Farbmanagement oder Profilkonvertierung unter macOS Tahoe zu drucken, müssen Sie den Standarddruckbefehl von Photoshop nicht mehr verwenden. Neuere Updates von macOS und der Adobe-Druckengine erzwingen einen Farbtransformationspfad (über ColorSync oder CoreGraphics), wenn Sie direkt aus Photoshop drucken, was die rohen Zielpatches vollständig verändert. Da Photoshop die Farbverwaltung in modernen macOS-Versionen stark einschränkt, müssen Sie externe Umgehungen verwenden, um vollständig unveränderte Pixel an Ihren Druckertreiber zu senden:
Verwenden Sie das Apple ColorSync-Dienstprogramm: Speichern Sie Ihr Profilierungsschema als unkomprimierte TIFF- oder PNG-Datei (betten Sie kein Farbprofil ein). Öffnen Sie die Datei direkt mit dem nativen ColorSync-Dienstprogramm (zu finden unter /Applications/Utilities/). Gehen Sie zu Datei > Drucken. Erweitern Sie die Druckeroptionen und suchen Sie das proprietäre Farbmenü Ihres Treibers. Schalten Sie manuell die Option auf Aus (Keine Farbkorrektur) oder Keine. Dieses Dienstprogramm zwingt macOS, die rohen digitalen Zahlen ohne Abfangen an den Druckkopf zu senden.

Ein befreundeter Farbmanagment Fachmann kennt das Problem auch

[backtomarfa]

Konnte mir ehrlich bis heute nicht vorstellen wie vertrottelt das alles geworden ist.

[itsab1989]

Aber wer ist jetzt wirklich Schuld? Apple? Canon? Alle?
Laut meinem Claude scheint mein Problem eher mit Canon zusammenzuhängen. Aber was weiß ich schon?
Epson scheint besser zu funktionieren (oder zumindest anders).
Allerdings kann ich da im Colorsync Dienstprogramm nicht direkt als Target drucken sondern muss erst ein Profil auswählen und dann wird diese Option freigeschaltet, die es dann wieder umgeht. Bei Canon ist sie immer verfügbar, aber nicht zuverlässig.
Bei DPReview hat jemand eine Anleitung von jemandem gepostet, laut welcher zumindest aber dieses Problem in Tahoe behoben sei.
So macht das echt keinen Spaß...

[backtomarfa]

Ich denke der Fehler liegt im System / Colorsync / Core Image. Ein Freund der eine Firma für Farbmangment betreibt hat mir geraten einen billigen Windows Rechner zu kaufen, er kannte das Problem. Die Calibrite Anleitung funktioniert ja, aber es sollte auch anders gehen. Bei meinen Spielfoto sieht man das Problem sofort bei einen Target nicht unbedingt. In Summe interessiert die gesamten Industrie das Thema nicht wirklich, es wird kaum noch gedruckt und mit Anspruch und selbst kalibrierten Druckern noch weniger. Das es jetzt eine spezielle Option im Colorsync Utillity gibt deutet darauf hin das etwas grundsätzlich geändert wurde.

[itsab1989]

Du hast Tahoe oder? Da sollte dort ja was gefixt worden sein. Unter Sequoia kann ich die Farbziel Option zwar mit Canon direkt auswählen aber man sieht in der Vorschau deutlich wie sich die Farben HEFTIG verschieben.
Beim Epson ist es zunächst ausgegraut. Wenn man es über einen kleinen Unweg dann aber aktiviert, verändern sich die Farben in der Vorschau nicht mehr.

[backtomarfa]

Yes Tahoe, nur Drucker managed Farben funktioniert. Darum gibt es unter Tahoe die Option Drucken ohne Farbmangment nicht mehr, das Utillity sollte das irgendwie ersetzende ich von Adobe gelernt habe aber auch das funktioniert nicht wie es soll. Da Canon und die anderen kundigen Leute entlassen und mit Call Centern ersetzt haben wird man im Kreis geschickt oder bekommt nette Mails. Die Profis nehmen RIPs und umgehen das alles, technisch ist das aber nicht notwendig. Wenn du einen Canon Grossformat Drucker kaufen willst zwingen sie dich fast zu einen RIP.....

To print custom color profiling patches or calibration charts on a Canon imagePROGRAF PRO-1000 without experiencing a color shift, you must completely bypass color management.Because macOS Tahoe handles the print subsystem differently, the operating system or application often forces its own ICC color conversion onto your target. This results in a double-profiled chart, causing shifted hues and making the printed chart useless for calibration or profiling.

Step 1: Use macOS ColorSync Utility (The Safest Route)Do not print your target directly from Photoshop or Lightroom, as Adobe applications frequently force a color conversion on Mac systems. Instead, use the built-in macOS utility:Open ColorSync Utility via Finder (/Applications/Utilities/ColorSync Utility).Click File > Open and select your calibration chart image (TIFF or JPEG).Click File > Print.Look at the primary print preview pane. In the Color: dropdown menu, change it from Premultiplied or As Image to Print as Color Target.Note: If "Print as Color Target" is grayed out, jump to Step 2 to configure the driver first, then return to this step.

Step 2: Disable Driver Color CorrectionYou must explicitly tell the Canon PRO-1000 driver not to apply its own colors (like Canon Digital Photo Color or Vivid):In the Tahoe Print Dialog window, scroll down or expand the options menu to find Color Matching.Ensure ColorSync is unselected. Instead, choose Canon Color Matching (or Hand Off to Printer depending on your exact driver update).Navigate to the Quality & Media menu dropdown.Under the Rendering Intent or Color Mode setting, explicitly select No Color Correction.Ensure your Media Type matches exactly what the profiling/calibration software dictates (e.g., Photo Paper Pro Luster).

[itsab1989]

Ich fühle deine Wut durch das Display hindurch. Finde es auch eine Frechheit wie sie das kaputtgemacht haben. Aber es scheint zu wenige Nutzer zu geben, die das interessiert...

[backtomarfa]

Haha... Wut, nein es ist eher eine Ernüchterung. Es gab immer Probleme doch es gab früher immer auch kompetente Ansprechpartner das wurden den Profit geopfert. Die meisten User drucken mit den gelieferten Profilen und sind glücklich weil das ehrlich gesagt auch gut funktioniert in dieser Welt sind wir die Aussenseiter....

[backtomarfa]

Hab gestern ein OS Update installiert, jetzt ist die Option Zielfarben drucken nicht mehr verfügbar, ich frage also Google: Bekanntes Problem, man muss ein Dummy Profil unter Farbeinstellungen auswählen dann hat man wieder zugriff auf die Option. WTF ?

http://digitaldog.net/files/PrintingTargetsCSUtility.pdf

http://digitaldog.net/files/API%20Print%20bug%20in%20macOS.pdf

Es gibt keinen Zweifel das Apple diesen Bereich vernachlässigt, wer wie wir zwischen anspruchslosen Consumer und High End sitzt kommt unter die Räder und weder Apple noch Adobe scheint es zu kümmern.

[itsab1989]

So is es bei meinem Epson schon seit ich das beim ersten Mal probieren wollte. Canon war besser und angeblich hatten sie es unter Tahoe behoben. Glückwunsch, dass sie zu ihren alten Fehlern zurückfinden.... 😅

[backtomarfa]

Das Canon und Epson im Interesse ihrer Kunden nicht fordern das diese Bugs durch Apple gelöst werden ist das eigentlich ungeheuerliche an dieser Sache.

[itsab1989]

Sehe ich genauso. Deshalb hab ich das ja beim Support auch speziell angefragt. Aber scheinbar ist keiner verantwortlich und niemand hat Lust auf die ganze Arbeit...

[itsab1989]

Scheint halbwegs zu funktionieren:

Post in thread '[Tool] ChromIQ – a macOS and Windows GUI for ArgyllCMS printer profiling (v3.13.0-beta)' https://www.printerknowledge.com/threads/tool-chromiq-%E2%80%93-a-macos-and-windows-gui-for-argyllcms-printer-profiling-v3-13-0-beta.17593/post-148843

Post in thread 'An ArgyllCMS front end to try? [testing wanted]' https://www.dpreview.com/forums/threads/an-argyllcms-front-end-to-try-testing-wanted.4836447/post-68730973

[backtomarfa]

Hi, darf ich noch eine Verbesserung anregen ? Dein Program ist so wunderbar geworden das sollte sich auch im Design spiegeln. Ich würde mir ein schlichteres vor allem weniger buntes Interface wünschen. Die zT schrillen Farben machen es schwer messbar und stören auch den doch sehr professionellen Anspruch denn dein Programm erreicht hat Mir wäre monochrom am liebsten aber soweit muss es nicht gehen. Die Unterhaltung sollte vielleicht aus den selben Grund auch ausblendbar sein.