How BrushForge builds a paint-match shortlist

Current public facts

1. Catalogue records and colour sources

The source library stores a stable paint identifier plus brand, name, code, line, line variant, product type, finish, colour data, tags, lifecycle state, update timestamp, and maintenance notes. The web generator uses only records with a usable stored colour and an eligible classification.

Catalogue work combines manufacturer-supplied data where available, published manufacturer or retailer product information, and manual curation and cleaning. Some manufacturers have supplied data directly; other records require research and reconciliation. The current public pages do not expose a source URL or measurement method for each colour record.

2. Inclusion and exclusion

A record needs an RGB/hex colour and a supported miniature-paint classification. The current web pipeline excludes technical products, varnishes, mediums, auxiliaries, primers, markers, effect products, and air-specific paints from conversion pools. Records tagged as effect, varnish, pigment, or placeholder colour are also excluded. Dry paints are logged separately rather than forced into a colour-matching pool.

Lines identified as auxiliary products, weathering effects, pigment effects, diorama effects, varnish, primer, air, airbrush, spray, or mecha are outside the normal pool. This reduces comparisons between products intended for materially different jobs.

Some records remain valid page subjects but are not recommended in cross-brand results. The current policy excludes Vallejo Arte Deco variants and AK Interactive AFV, Naval, and General Series from ordinary recommendations. Visibility and recommendation eligibility are deliberately separate.

3. Identity and duplicate handling

Paths begin with a normalized paint name within a brand. If that would collide, the generator adds line, line variant, code, and finally a counter. The visible title should include enough of brand, range, and code to distinguish repeated names.

The 10 July snapshot contains 405 repeated name groups across the public catalogue and 296 repeated groups within a brand. No exact identity duplicates remain when brand, line, name, and code are considered together. Alias and lifecycle work is reviewed separately because two records with similar names are not automatically the same product.

4. sRGB → XYZ D65 → CIELAB

For each 8-bit channel, BrushForge divides by 255 and applies the standard sRGB inverse transfer function:

• c / 12.92 when c ≤ 0.04045
• ((c + 0.055) / 1.055)^2.4 otherwise

Linear RGB is converted to XYZ with the sRGB D65 matrix:

XYZ is converted to Lab against D65 reference white X_n = 0.95047, Y_n = 1.0, Z_n = 1.08883. The usual CIELAB piecewise function uses δ = 6/29. No additional chromatic adaptation is applied because both the stored sRGB interpretation and Lab reference use D65 in this implementation.

5. Strict behaviour families

The generator retains three broad display pools—standard, translucent, and metallic—but does not use that broad translucent grouping to claim compatibility. Every eligible record also receives one of seven strict behaviour families:

A compatible candidate must match the source family, requested target brand, and recommendation policy. If a source has no target in the same family, a record from another translucent family may be shown only as a warned reference with the text “No close same-type equivalent found; nearest recorded color shown.” It is not called compatible.

6. CIEDE2000 distance and ranking

BrushForge calculates the complete CIEDE2000 formula on the source and candidate Lab coordinates with k_L = k_C = k_H = 1. It ranks eligible candidates by the resulting distance and selects the smallest value. Calculation uses full floating-point precision; public displays round for readability.

There is no statistical confidence model behind a colour conversion. A lower distance is simply a closer recorded colour under this formula and input set; it is not a probability of physical equivalence.

7. Reference and boundary tests

The Python generator and browser result code share the tier boundaries. Boundary tests cover 0, 0.1, 2, 2.1, 5, 5.1, 10, and 10.1. The CIEDE2000 implementation is checked against the published Sharma, Wu, and Dalal reference pairs to catch sign, hue-angle, and rotation-term errors.

8. Known limitations

• Catalogue colours can be approximate and can vary in provenance.
• A single stored colour cannot represent opacity, coverage, hue bias, viscosity, or drying shift.
• Metallic reflectance and particle behaviour are not represented by a flat sRGB value.
• Washes and transparent one-coat paints depend strongly on undercoat, pooling, and application.
• Batch variation, product age, reformulation, and lighting are not modelled.
• Screen swatches vary with display calibration, gamut, True Tone, Night Shift, brightness, and ambient light.
• The public catalogue and native app catalogue are separate snapshots and may not update simultaneously.

Use swatches for relative comparison, then verify with physical paint when the final appearance or finish matters. Aim for ΔE ≤5 as a shortlist—not a promise.

9. Update and correction policy

Generated pages use the latest source-record update date rather than a hard-coded build date. Catalogue additions and changes are regenerated across paint pages, charts, browser data, internal links, and sitemaps. A second generator run should produce no unexplained changes.

To report an error, use brushforgeapp@gmail.com. Include the page URL, brand, range, paint name, code, proposed correction, and a manufacturer link or clear label photo where possible. Reports are reviewed before the source library changes.

Methodology changelog

References

• CIE 015:2018, Colorimetry Part 6: CIEDE2000 Colour-Difference Formula.
• CIE 116:1995, validity of formulae for small colour differences.
• Sharma, Wu, and Dalal: CIEDE2000 implementation notes and reference data.
• BrushForge guide: what ΔE2000 means for miniature paints.