# Light Ink Splitting in Digital Print Color Management

*Transfer-Curve Linearization vs. DeviceLink-Based Ink Splitting*

White paper — August 2026

## 1. The problem

Many wide-format and industrial digital presses extend their CMYK (or CMYK+) ink set with "light" variants of one or more colorants — typically light cyan and light magenta, and sometimes light black (or light-light black in a K/lK/llK grey ladder). The light ink has lower colorant strength, so it can render very low tone values with a finer, less visible halftone dot than the full-strength ink would produce at the same coverage. Used alone, however, light ink runs out of density long before 100% input is reached.

Ink splitting is the transform that converts a single logical channel (e.g. "Cyan") into two (or three) physical channels — light and solid (and light-light) — so that highlights and quartertones are built almost entirely from light ink, while shadows are built from full ink, with a controlled hand-off in between. Two implementation strategies are in common use, and both are supported, in different forms, by ColorLogic's CrossXColor SDK.

## 2. Method 1 — Transfer-curve (parametric) splitting

This approach treats ink splitting as a pair (or triplet) of one-dimensional transfer curves per logical channel, independent of every other channel. For an achromatic pair (K / light-K) the curve is commonly driven off luminance; for a chromatic pair (C/lC, M/lM) it is driven off chroma. Each curve is defined by a handful of break points: where the light ink starts, where it reaches its maximum, and where the solid ink starts and reaches 100% — i.e. as the light ink approaches its maximum, the solid ink is introduced and takes over.

This is exactly the model CrossXColor exposes as the curve-based mode of its own ink-splitting device link ("ProfileType" = "InkSplitDeviceLink", option "InkSplitCurves" / "InkSplitCurves3"): each parameter set is literally "solidInk, lightInk, startSolid, endSolid, maxLight, endLight" (and, for three inks, +lightlightInk, maxLightLight, endLightLight). Values can be fixed by the operator or resolved automatically ("Auto") from measurement data. The same logic is often implemented directly at the RIP or driver level, outside any ICC pipeline, as a simple ink-limit / transfer-curve tool.

### Pros

- Simple to reason about and tune: a small number of numeric break points map directly to something a press operator can see and adjust from a printed ramp.
- Cheap to compute and apply: a 1-D lookup per channel, no multi-dimensional LUT to build or invert.
- Can be changed instantly (e.g. from the RIP UI or a curve file) without regenerating a full profile — useful for day-to-day press calibration.
- When measurement-driven ("Auto"), it needs a lighter chart than Method 2: single-channel process-color gradients are sufficient; two-color overprint patches are only "recommended," not required.
- Easy to isolate and debug: a banding or graininess problem can usually be traced to one curve segment.

### Cons

- Still needs measured data for a decent result. CrossXColor is explicit that "reference and measurement data is required if you use 'Auto' for any of the values" — a curve set by eye, without printing and measuring at least the process-color gradients, tends to produce a visible, non-colorimetric hand-off between light and solid ink rather than a smooth one. The lighter setup effort applies to the size of the chart, not to whether a chart is needed at all.
- Purely channel-wise: it cannot account for interactions between colorants (e.g. how light-cyan-over-light-magenta prints differently than either alone), so it is a first-order approximation of the real device response — and without measured overprint patches, that approximation is never corrected.
- If implemented outside the color-management pipeline (driver/RIP curve), it is not a portable, versioned profile object — it doesn't travel with the job, chain with other transforms, or get embedded/exchanged the way an ICC element does.
- Scales poorly to three-ink splitting (light-light variants): CrossXColor's own documentation notes that "the dependencies for 3-ink splitting are higher than for only two inks" and that "target values may not be reached exactly" once solid/light/light-light curves start competing for the same tonal range.
- Curve break points must be re-tuned whenever ink set, substrate, linearization or screening changes — there is no colorimetric optimization step to fall back on.

## 3. Method 2 — DeviceLink-based splitting ("ProfileType" = "InkSplitDeviceLink")

CrossXColor also packages ink splitting as a first-class DeviceLink profile type. Internally it still works in two steps — copy source channels to destination channels ("InkSplitChannels"), then apply per-channel transfer curves — so it is a superset of Method 1, not a different algorithm. What changes is the surrounding infrastructure: the result is emitted as a standard DeviceLink profile object that plugs into the normal ICC/CrossXColor workflow.

Two calibration modes are available. Parameters can still be set explicitly with "InkSplitCurves" / "InkSplitCurves3" (i.e. Method 1's curves, just delivered as a profile). Or the SDK can derive the split automatically ("InkSplitChannels = Auto", or the "256"/"1024" flags of "MultiColorGeneration") from real measurement data — a dedicated test-chart type ("TestchartType = InkSplitting") generates gradients plus all two-color overprint combinations, so the resulting transform reflects actual overprint behavior rather than assuming channel independence. The "1024" flag additionally optimizes the split to maximize the reproducible gamut.

### Pros

- Produces a portable, standards-based artifact: the split is embedded in a DeviceLink profile that can be chained, merged (e.g. with spot-color device links via "MergeDeviceLink") and exchanged across RIPs/tools that consume CrossXColor or ICC-style profiles.
- "Auto" calibration is measurement-driven and includes real two-ink overprint data, so it can correct for colorant interaction that a pure transfer curve ignores.
- The "1024" optimization flag can maximize gamut when choosing how to allocate coverage between light and solid ink, something a manually set curve cannot do on its own.
- Formally supports three-ink (light-light) splitting with a dedicated, documented parameter set, and can be combined with ink limiting, linearization and gamut mapping in a single coherent pipeline stage.
- Because it is a profile, it is auditable and reproducible — the exact characterization is stored and versioned rather than living as a loose driver setting.

### Cons

- Heavier workflow: "Auto" calibration needs dedicated ink-splitting test charts to be printed and measured, and the full profiling/SDK pipeline (chart generation, measurement import, profile calculation) has to be run and re-run whenever press conditions change.
- More computationally expensive: building the full DeviceLink LUT is comparatively slow — the SDK documentation explicitly warns that generating a merged/complex device link "requires all LUT points to be calculated" and recommends using the lower-level separation call instead when only a few colors need converting.
- More moving parts to debug: with "Auto", the resolved curve values are the result of the profiler reconciling potentially conflicting constraints, so the final behavior is less directly traceable to a single input number than a hand-set curve.
- Adds an extra pipeline object (a profile file to generate, store and version) rather than a lightweight setting that lives inside the RIP/driver.

## 4. Side-by-side comparison

| Aspect | Transfer curve | DeviceLink (InkSplitDeviceLink) |
|---|---|---|
| Model | 1-D curve per channel, driven by luminance/chroma break points | 2-stage transform (channel copy + curves), optionally LUT-calibrated from measurement |
| Channel interaction | Ignored (each channel independent) | Can be captured via "Auto" + 2-color overprint chart data |
| Test chart needed for a decent result | Yes — at minimum measured single-channel process-color gradients; overprint patches recommended but optional | Yes — full "InkSplitting" chart: gradients plus all two-color overprint combinations |
| Setup effort | Lower — smaller chart, curve values editable directly on press | Higher — larger chart, full profile-generation workflow |
| Compute cost | Very low | Higher (full LUT build); SDK recommends lighter APIs for spot conversions |
| Portability | Often driver/RIP-local, not a standard profile object | Standard DeviceLink profile: chainable, mergeable, exchangeable |
| 3-ink (light-light) support | Possible but fragile — target values may not be reached exactly | Formally supported with a dedicated parameter set |
| Gamut optimization | Not available | Available via the "1024" optimize flag |
| Best fit | Fast press-side tuning, simple ink sets, minimal infrastructure | Managed color-managed production workflows, complex ink sets, chained profiles |

## 5. Recommendation

The two approaches are not mutually exclusive — they sit on the same spectrum, and neither one is measurement-free. A transfer curve is the right tool when the goal is quick, low-overhead tuning of a simple ink set on the press floor: it still requires printing and measuring process-color gradients for a decent, colorimetric result, but the chart is smaller and the parameters (a handful of numbers) are directly editable without a profiling workflow. A DeviceLink-based split is the right tool once the workflow already runs on ICC/CrossXColor profiles, the ink set includes three-ink (light-light) splitting, colorant-interaction accuracy or gamut optimization matters (which requires the larger overprint-inclusive chart), or the transform needs to be portable, versioned and chained with other profile stages.

In practice, CrossXColor lets a team have both: "InkSplitDeviceLink" can be driven purely by explicit "InkSplitCurves" parameters, giving the simplicity of Method 1 while still packaging the result as a standard, portable DeviceLink profile. "Auto" calibration should be reserved for cases where the added measurement and compute cost is justified by the accuracy gain — typically higher-channel-count ink sets or presses where overprint behavior is not well approximated by independent curves.