pigment-mixing

name	pigment-mixing
description	Reference for pigment-style color mixing in art-junk — why paints mix differently from light, the Kubelka-Munk foundation, the Sochorová/Jamriška 2021 latent-space approach, and the licensing constraints that govern what we can ship.

Pigment mixing — reference

Why this matters for a drawing app

Additive mixing (the math RGB does natively) is how light mixes: blue light plus yellow light makes whitish light. Paint does not mix that way: blue pigment plus yellow pigment makes green, because pigments subtract wavelengths from reflected light rather than adding them. A drawing app whose colors claim to behave like paint but mix like projector lamps breaks the user's intuition at exactly the moments a painter reaches for it — wet-on-wet blending, glazing, color wheels built from complementary primaries.

art-junk intends to offer pigment-style mixing as a first-class option alongside additive mixing. This skill is the conceptual reference.

Three tiers of sophistication

Tier	What it does	Cost	"Yellow + Blue ="
1. Oklab interpolation	Perceptual midpoint in Oklab	1 matrix op per sample	Greenish-gray (perceptually smoother than sRGB lerp, still additive)
2. Spectral Kubelka-Munk	Real K-M physics over a sampled spectrum, with a pigment database	~10–100× tier 1	Green (correct paint behavior)
3. Latent-space pigment mixing	Sochorová/Jamriška 2021: RGB → (pigment concentrations, residual) → linear ops → RGB	~5–10× tier 1, LUT-driven	Green (K-M-like result with RGB-speed I/O)

Tier 1 is always on — our color picker lives in Oklch, so any "interpolate two colors" operation gets tier 1 for free. Tier 2 is a clean, fully-public-domain option we can ship. Tier 3 is the state of the art — but see the licensing section below before planning to use it.

• kubelka-munk.md — the physics; how K/S space works; how to go RGB → spectrum → K/S → spectrum → RGB.
• latent-space.md — the Sochorová/Jamriška approach at a conceptual level; what a clean-room reimplementation looks like; why we don't vendor Mixbox.

---

Licensing — read this first

The reference implementation of tier 3 is Mixbox by Secret Weapons (Sochorová and Jamriška's company). Mixbox ships:

• Source code (C / GLSL / JS / Rust bindings) — licensed CC BY-NC 4.0.
• mixbox_lut.png — a 3D lookup table encoding the pigment decomposition — licensed CC BY-NC 4.0.

CC BY-NC 4.0 is non-commercial only and not compatible with art-junk's MIT OR Apache-2.0 workspace license. We cannot:

• Add mixbox as a Cargo dependency and ship it.
• Vendor the source into a crate.
• Redistribute the LUT as a binary asset.

We can:

• Use Mixbox locally, for personal experimentation, off the main branch.
• Cite the paper and discuss the algorithm in design notes.
• Implement tier 2 (plain Kubelka-Munk) from first principles — K-M physics is 1930s and public-domain.
• Clean-room reimplement tier 3 based only on the published paper, with our own primary pigments and our own LUT, citing the paper for methodology. See latent-space.md.

Before committing to the clean-room path, do a patent search. A casual search shows nothing filed by Secret Weapons, and the paper and commercial-license wording imply their moat is copyright of the LUT and code rather than a patent, but that is not legal advice and needs checking before the code leaves the project.

If someone on the team wants Mixbox's behavior quickly for a demo, the right move is a feature-flag-gated crate (feature = "mixbox-preview") that pulls Mixbox as a dev-only, non-commercial dependency — not a default-on part of the distribution.

Where in the architecture

Tier 1 (Oklab) is a property of the color picker and any gradient UI — the perceptual-color skill covers it.

Tiers 2 and 3 are properties of a brush mixing mode. Two brushes should be able to produce different mixing behavior when they overlap a canvas region. This maps cleanly onto the existing BrushParams structure — add a mixing_mode: MixingMode field with variants like Additive, Pigment (and room for Pigment { kind: ... } if we support multiple pigment algorithms). The stroke rasterizer queries the mode and dispatches to the appropriate blend.

Because pigment mixing is more expensive than additive mixing, and because it's doing per-pixel work, it belongs on the GPU via a WGSL pass in aj-effects, or on the CPU via a worker in aj-engine for the "resolve full brush texturing off-thread" path described in CLAUDE.md. The placeholder / resolve split in the latency strategy is exactly the right seam: paint a cheap additive placeholder in <1ms, resolve pigment mixing in a worker, swap in.

UX considerations

• Mixing mode is not a global setting — it's per-brush. A highlighter should stay additive (overlapping yellow onto blue stays yellow-on-blue-ish, not green). An "oil paint" brush should use pigment mixing.
• Make the default mode honest. The first brush the user meets should mix the way they expect. For a "paint-first" app the default is pigment; for an "illustration-first" app the default is additive. art-junk's framing (stylus-first, drawing program, paint vocabulary) argues for pigment as default.
• Don't bury the switch. A brush inspector's mixing-mode dropdown needs to be discoverable, not hidden in a palette's settings submenu. Users will want to A/B the two modes.
• Show the primary pigments somewhere. Tier 2 and tier 3 both work off a finite palette of primaries. Exposing "this brush's pigment decomposition" as a small swatch row in the inspector teaches the user what's happening and gives us somewhere to explain why "crimson + cerulean = violet, not brown."

Further reading

• Sochorová & Jamriška (2021). Practical Pigment Mixing for Digital Painting. ACM TOG 40(6), Article 234 (SIGGRAPH Asia 2021). Project page · DOI 10.1145/3478513.3480549.
• Kubelka–Munk theory — Wikipedia
• Mixbox — GitHub (reference, CC BY-NC 4.0 — do not vendor).
• Meng, Simon, Hanika, Dachsbacher (2015). Physically Meaningful Rendering using Tristimulus Colours. EGSR 2015. — spectral upsampling technique we would use for tier 2.