Methodology

How the PaintAtlas catalog and its color matches are produced, and what those matches can and cannot tell you.

Where the catalog comes from

PaintAtlas does not manufacture or independently measure paint. The paint records published here are imported from the community-maintained miniature paint database Arcturus5404/miniature-paints. The import script (scripts/import-paints.ts) reads the markdown tables in that repository and stores, for every listed paint, the product name, the product line or set, an optional manufacturer product code, and a single screen color value expressed as an #RRGGBB hex code plus its 0–255 RGB and Lab coordinates. Brand display names, spellings and links come from a local metadata table (scripts/brand-metadata.ts).

Because this is a community dataset, individual records can be incomplete, outdated, or transcribed incorrectly, and the catalog is not exhaustive: it contains the products the upstream project lists, not every paint a brand sells. Brand names and product designations remain the property of their respective owners.

From hex code to CIE Lab

Each stored screen color is converted once, by the shared utilities in lib/colors.ts. The chain is: hex → 8-bit sRGB (0–255) → linear sRGB → CIE XYZ (D65) → CIE Lab. Two details matter for reading the numbers on this site:

  • sRGB gamma expansion. Each channel is divided by 255, then linearized with the sRGB transfer function: a channel above 0.04045 is raised to the power 2.4 after the offset-and-scale step ((c + 0.055) / 1.055), and a channel at or below that threshold is divided by 12.92.
  • XYZ matrix and D65 white point. The linearized channels (scaled to 100) are multiplied by the published sRGB → XYZ matrix, then normalized against the D65 reference white (X 95.047, Y 100.0, Z 108.883). The cube-root transfer uses threshold 0.008856 and 903.3 before producing L* (116 y − 16), a* (500 (x − y)) and b* (200 (y − z)).

Lab is used because it is a device-independent, perceptually oriented space: equal numeric distances aim to correspond roughly to equal perceived color differences, which raw RGB does not. Every value shown for a paint is derived purely from that paint’s recorded screen color — no scanner, spectrophotometer, or printed swatch is involved.

How matches are ranked: Delta E (CIE76)

Similarity between two paints is the straight-line (Euclidean) distance between their Lab coordinates, the CIE76 ΔE formula: ΔE = √(ΔL*² + Δa*² + Δb*²). This is implemented in lib/colors.ts and used by the batch job scripts/compute-relationships.ts. A lower number means the two stored color values are numerically closer.

The relationship generator applies fixed cutoffs to that distance. Similar colors and cross-brand alternatives keep pairs below ΔE 15; the lighter/darker and highlight/shadow/complement partners are picked by the nearest distance to synthetic target coordinates (for example, a target lightness offset from the source color) with their own limits around ΔE 30–40. The catalog’s own color family (for instance red, blue, brown, grey) can be used to restrict which paints are considered. These are defined thresholds and target points, not learned similarity or measured tolerance.

Multi-attribute catalog matching versus physical verification

ΔE compares a single attribute: the recorded color value. The comparison tools on this site also compare the descriptive attributes stored alongside that color, so a small ΔE is not presented as a substitute on color alone. Each attribute is either shared, in conflict, or missing on one or both records.

Where a record states them, the attributes the catalog compares are:

  • Purpose. Whether a product is an ordinary color paint or a primer, varnish or technical/effects product. Purpose takes precedence over application method in the comparison.
  • Chemistry / medium. The broad binder family — water-based acrylic, alcohol acrylic, enamel, lacquer — which governs thinning, drying and layering.
  • Application. Brush, airbrush or spray/aerosol, where the record distinguishes them.
  • Effect. Metallic or wash/ink/contrast/transparent behavior, where the record states it.
  • Finish. Matte, satin or gloss, where the record states one.
  • Opacity. Opaque, semi-opaque or transparent, where the record states one.

The comparison reduces to three outcomes. It is a match only when all six dimensions are known and equal, so the records describe the same categories on every point. A conflict — a primer against a conventional paint, or a metallic against a matte, for example — is an explicit disagreement in the catalog and is flagged as a mismatch even when the colors are close. A missingattribute is unknown: it was never recorded, so it is never assumed to agree, and a comparison resting on a missing attribute is reported as unverified rather than as a match.

This remains a comparison of catalog text and numbers. Agreement between attributes shows that two records describe the same categories; it is not proof that two paints behave the same on a surface, and it is not a physical test. You can run an attribute-aware comparison from Find a substitute, and the general reasoning behind it is covered in the guide to choosing a substitute.

Converter ranking and scope

The converter scans the selected manufacturer inventory for recorded CIE76 distances of 30 or less. This is a shortlist threshold, not a physical tolerance. Known attribute conflicts appear separately. In the remaining list, entries with missing attributes receive a two-point ranking penalty added to their distance; the displayed ΔE itself is unchanged. Reference standards can be color targets but are never offered as paint products.

A catalog match is a digital color comparison, not a physical paint test

Everything above compares numbers. A low ΔE means two paints were recorded with close screen values; it does not mean the paints behave the same on a miniature. Records that happen to store the same hex value produce a ΔE of exactly 0.0, even when the underlying products are different formulations.

Pigment composition, pigment load and opacity, binder and medium, finish (matte, satin, gloss, metallic), drying and re-wetting behavior, thinning and spraying behavior, coverage on a primer, the surface they are applied to, and ambient and camera lighting are not measured by the color calculation. Some catalog labels describe these properties, but labels are not measurements. Two paints can be an excellent catalog color match and still differ in every one of those practical properties. Treat a displayed match as a starting point for comparison, not as confirmation that one pot can replace another.

Relationships are generated, not recorded

The “similar colors”, “cross-brand alternative” and lighter/darker or highlight/shadow/complement suggestions on a paint page are computed in bulk from the catalog coordinates by the relationship job described above. They are derived data: they contain no manufacturer mixing recipe, no pigment formulation, and no informed ratio. The shadow/layer/highlight ordering is likewise a nearest-coordinate choice among the paints already in the catalog, not a tested three-step recipe and not a claim that the resulting steps look correct on a model. No paint is ever mixed, sprayed, or photographed as part of computing these relationships.

Missing data is shown as unknown, not verified

Not every paint record carries every attribute. Some fields are derived from the product-line wording in the upstream table rather than stated directly: the paint type, finish and opacity are inferred from text such as a range name (scripts/import-paints.ts), and an unrecognized line is now imported as unknown with no assumed finish or opacity. Older records may still contain inferred values until an audited refresh; matching cannot make those historical values authoritative. Color family is derived by rule from the hex value.

When an attribute is absent, it is unknown — it was not recorded, not measured, and not verified. An empty finish or opacity field is not evidence that a paint is matte or opaque, and a missing product code is not evidence that no code exists. Filtering or ranking that relies on a missing attribute is therefore weaker than it looks, and features are labelled accordingly rather than assuming a default.

Researched sources versus genuine bench tests

PaintAtlas separates two very different kinds of extra content, and does not blend them:

  • Researched, cited material. Some paint pages carry short written sections with a list of external sources, each with a label, a link and a note about what that source supports. This is desk research that points at public product pages, listings or documentation. It is a citation to someone else’s information, not an original PaintAtlas test, and it currently exists for only a small number of paints.
  • Bench test results. A bench test block appears only where an actual record exists in our database. It names the person who supplied the observation and the date, and it is labelled with a confidence badge: Observed on model for a hands-on observation, or Editorial inference for reasoning that was not directly observed. Records are added through a reviewed seeding process (scripts/seed-bench-tests.ts) that requires an author, a valid date, and notes containing at least one concrete, checkable observable. Nothing in this block is auto-generated or attributed to an invented tester.

Where no bench test record exists, no bench test is displayed. The absence of a bench test does not mean a paint performed badly; it means we have no such record. The two content types are kept visually distinct so a citation is never mistaken for a first-hand test.

Who publishes this and how to report a problem

PaintAtlas is run by an individual publisher; the responsible person and full contact details are listed in the imprint. If a record, a color value or a match looks wrong, corrections are welcome by email. Data accuracy is improved first upstream in the source repository and then re-imported, so corrections that belong to the underlying dataset are best raised there.