Where you load two palette assets side by side and let the nearest-entry Oklab delta-E statistics tell you whether a refactor drifted too far, whether a dark and light theme are still perceptually paired, or whether two palettes are ready to be used together in a Texture Recolor pass.
Summary
Palettes evolve. A theme gets refined, an alternative variant gets authored, a colorist makes a “very small” tweak that the lead artist needs to verify against the baseline. The cases where the question is “are these two palettes still close enough” or “how far have we drifted” are common enough to deserve their own workspace, and they are uncomfortably difficult to answer by eye when both palettes have a couple of dozen entries.
The Compare tab handles those cases with a single mechanic: for every entry in palette A, find the nearest entry in palette B by Oklab (a perceptually uniform color space designed to make equal numeric distances correspond to equal perceived color differences) delta-E (the standard measure of perceptual color distance), then report the minimum, average, and maximum of those distances. A low average and low max mean every entry in A has a close counterpart in B; a high max with a low average means most of A maps cleanly but at least one entry has no good match in B; a high min means no entry in A has a counterpart in B closer than the min, which usually flags an intentionally distinct color.
- Audit a refactored palette against its predecessor to confirm the drift is within an acceptable bound.
- Compare sibling palettes (a dark theme and a light theme of the same brand) to confirm they share a perceptual relationship.
- Identify palette entries that have no close counterpart in a target palette before running a Texture Recolor, which requires the source and target palettes to have the same entry count.
- Bisect “which entry changed too much” between two palette versions by reading the max distance and locating the corresponding swatch.
Features
- Two palette slots.
ObjectFieldwidgets labelled Palette A and Palette B, each accepting anyColorPaletteAsset. Drag a palette from the library sidebar or from the Project window onto either field, or click the picker icon to open Unity’s asset picker. - Two side-by-side swatch columns. Each palette’s entries render as a vertical scroll column of named swatches. Both columns scroll independently, so palettes of different lengths can be browsed in parallel.
- Nearest-entry Oklab delta-E statistics. Below the swatch columns, a single line reports the min, avg, and max of the nearest-entry distances from palette A to palette B, plus the entry counts for each palette. The format is
Nearest-entry Oklab delta-E over A -> B: min X.XXX avg X.XXX max X.XXX (A: N entries, B: M entries). - Auto-refresh on slot change. Changing either palette field rebuilds the swatch columns and recomputes the stats line. There is no separate refresh button because the rebuild happens automatically.
- Empty state. When either slot is empty (or holds an empty palette), the swatch columns show an empty-state message and the stats line reads
Assign two palettes to compare. - Drag-drop everywhere. The palette slots accept drops from the library sidebar, from the Project window, and from a file dragged from disk. Drop semantics mirror the other Chroma palette inputs.
Recipes
These recipes cover the four authoring workflows the Compare tab is built for. Each one is self-contained, so jump to whichever matches what you are doing.
Load two palettes for comparison
Problem. You have two palette assets and you want to put them side by side in the Compare tab – whether that is a before-and-after pair from a refactor, a dark and light theme you want to measure against each other, or two palettes you are considering combining in a Texture Recolor pass. Getting them both loaded is the prerequisite for everything else here.
Solution. Three loading paths all work for both slots. Use whichever is fastest depending on where the palette is:
- Drag a
ColorPaletteAssetfrom the Library sidebar’s Palettes sub-tab onto either Palette A or Palette B field. - Drag a
ColorPaletteAssetdirectly from the Project window onto either field. - Click the small object-picker icon on the right edge of either field to open Unity’s asset picker.
The swatch columns rebuild immediately on any slot change. A common starting pattern is “before vs after”: load the current production palette into Palette A and the proposed revision into Palette B. The A-to-B direction matters for the stats – see the next recipe for why.
Browse the swatch columns side by side
Problem. You have two palettes loaded and you want to scan the entries visually – checking that a brand palette still has the right hues after an accessibility pass, confirming a dark theme maps intuitively onto its light counterpart, or locating the specific swatch that the stats line’s max distance is pointing at.
Solution. The two columns render each palette’s entries top-to-bottom in their on-asset order. Each row shows the swatch color, the entry name, and the hex code. Both columns are independent scroll views, so palettes of different lengths can be browsed in parallel without one column dragging the other.
A few things to keep in mind as you read the columns:
- The columns are not aligned row-for-row. Palette A’s first entry is at the top of column A; palette B’s first entry is at the top of column B; the panel does not assume the two correspond by index. Each entry in palette A is matched to its nearest counterpart in palette B by Oklab delta-E, not by array position.
- For palettes that were authored as direct revisions of each other (a brand refresh, a contrast tune-up), the row alignment is often informally meaningful even though the panel does not enforce it.
- For palettes that come from independent design passes, the columns are just two browseable lists. The stats line underneath does the analytical work; the columns give you the visual confirmation.
When you want row-for-row alignment to matter (a literal recolor revision where A’s row 1 should correspond to B’s row 1), browse both columns and trust the eye for that case rather than the nearest-Oklab matching. The Palette Editor lets you reorder entries if you want to bring two palettes into index alignment.
Read the nearest-entry distance statistics
Problem. You want to know quantitatively how far two palettes are from each other – not just by feel. A production pipeline might require that a refactored palette stay within a certain max delta-E from the original; a sibling-theme workflow might require that the dark and light variants share an average distance below some perceptual threshold. The stats line is what you read for that.
Solution. Below the swatch columns, a single stats line reports three numbers plus the entry counts:
Nearest-entry Oklab delta-E over A -> B:
min X.XXX avg X.XXX max X.XXX
(A: N entries, B: M entries)
The computation is asymmetric: for each entry in palette A, the panel finds the nearest entry in palette B (the one with the smallest Oklab delta-E), records that distance, and aggregates the minimum, average, and maximum across all A entries. The direction matters because A-to-B and B-to-A are not the same question. A-to-B answers “how well does every entry in A find a counterpart in B”; B-to-A answers “how well does every entry in B find a counterpart in A”. When the comparison is “did A drift from B as baseline”, load the baseline into B. When the comparison is “does the new B have counterparts for every old A”, load the old palette into A.
The same Oklab delta-E rating scale used by the Accessibility tab applies here:
| Distance | Rating |
|---|---|
| < 0.01 | Imperceptible |
| < 0.03 | Very Subtle |
| < 0.06 | Subtle |
| < 0.10 | Noticeable |
| < 0.20 | Distinct |
| >= 0.20 | Strong |
Three common patterns in the numbers:
- Low min, low avg, low max. Every entry in A has a close counterpart in B. The two palettes are functionally interchangeable; the refactor or revision did not drift meaningfully. Typical for cosmetic touch-ups.
- Low min, low avg, high max. Most of A maps cleanly to B, but at least one entry has no good match. Often the case when a new color was added to B that has no counterpart in A, or an outlier was added to A that no entry in B is close to. The max value is the distance to that outlier; finding it requires walking the swatch column.
- High min, high avg, high max. No entry in A has a close counterpart in B. The two palettes are unrelated, or the comparison direction is wrong. Verify the slot assignments; if both palettes look unrelated by eye, the high stats are just confirming what is visible.
Act on the comparison result
Problem. You have read the stats and browsed the columns. Now you need to do something with that information: confirm a refactor is safe, flag the drifted swatches for correction, or decide whether two palettes are ready to be used together.
Solution. The Compare tab is diagnostic, not prescriptive. The next move depends on what the comparison was for:
- Auditing a refactor. A low max distance confirms the refactor stayed within bounds. A high max distance flags that at least one swatch drifted too far; walk the swatch column to find it visually, then either accept the drift, revert the offending entry in the Palette Editor, or push the rest of the palette to match.
- Sibling theme verification. A low avg distance confirms the dark and light themes are perceptually paired. A high avg distance flags that one of them needs to be re-tuned. The fix is in the Palette Editor, not here.
- Pre-recolor validation. If a Texture Recolor pass is planned (palette-to-palette pixel remap), the source and target palettes must have the same entry count. The Compare tab does not enforce this, but the swatch columns make a count mismatch obvious at a glance, and the stats line ends with the explicit
(A: N entries, B: M entries)count. Resolve any mismatch in the Palette Editor before running the recolor.