Paint Mixer

A digital tool for translating colors from photographs into practical paint-mixing recipes.
Try Paint Mixer

How do you translate a color you see into a
physical recipe you can actually mix?

A color on a screen is produced with light. Paint produces color through pigments absorbing and scattering light. So the RGB value I get from a photograph tells me what the color looks like digitally, but not which physical paints will produce it when mixed. I looked into how physical paint can be modeled, including the RIT Artist Paint Spectral Database, which documents measured spectral properties of artist paints and computational mixtures based on Kubelka–Munk theory.

This made it clear that the problem was bigger than simply converting one RGB value into another. I needed a way to predict how combinations of physical paints would behave when mixed.

From there, I built the product's own search around Mixbox.

Each available paint is represented by a name and RGB value. When a user selects their available paints, Paint Mixer tests combinations of up to four paints, in 5% increments, and uses Mixbox to predict the resulting color. The app then compares each candidate to the target and returns the closest result. I tested whether expanding the search beyond 4 paints and 5% increments meaningfully improved the result, but it increased computation without producing enough improvement to justify the added complexity.

UX testing, debugging, working with AI

Problem:
Portrait and some landscape images were returning the wrong color when clicked near the edges.

What I did:
I tested the app on my own and then cross-checked with Claude Code to investigate what was going wrong and whether it could identify the issue. It seemed it would stretch the image in odd ways.

What I found:
The click coordinates were being calculated against the “<img>” element's full layout box, while “object-fit: contain” meant the actual image occupied only part of that box. The click math was sampling the wrong location.

What changed:
I had Claude Code change the coordinate calculation to account for the actual rendered image rectangle rather than the full element.

What I learned:
A visually simple interaction can depend on underlying rendering behavior. Working directly in the browser made it possible to discover that mismatch through testing rather than treating implementation as something that happens after design. I did not want to rely on Claude Code for user testing, or allow development without human review.

I knew I wanted to build the option to add another color to an existing saved palette. This would require the application to save the photograph for later reference. But the original saved palette did not contain the photograph. The new UI feature revealed a missing relationship in the data model. The palette was saving the output, but not the context to continue working with it.
The solution became:
Save palette > store image reference > edit palette > add color > reopen image > pick new color > add to existing palette

All photos taken by me in Iceland

Next: Net Health New Mexico Primary Care Payment Reform (PCPR)

Kennedy Castelli