Color Calibration for Virtual Makeup Try-On: How to Bring Your SKUs Into the Render

The hard part of a virtual makeup try-on is not the render: it is the color. Color calibration for virtual makeup try-on is the work of translating each real SKU — a lipstick, a foundation, a blush — into a value the engine can paint on the customer's face with enough fidelity for the purchase decision to make sense. When that step is rushed and done without criteria, the experience works technically and fails commercially: the customer tries, buys, receives the product and discovers a different shade.

Why color decides the outcome of the experience

A virtual try-on serves one concrete purpose: to remove the uncertainty of buying makeup without touching it. That purpose depends entirely on the shade shown on screen resembling the shade of the product on the face. When it does not, the brand does not gain a conversion tool; it gains a new channel of unmet expectations and support contacts.

There are three sources of noise worth separating from the start:

• The real product: the same lipstick changes with the amount applied, the lip's own base color and the finish.
• The reference the brand uses: retouched packshots, campaign photos under studio light and catalog swatches rarely agree with each other.
• The customer's screen: brightness, dark mode and the device's color profile vary and cannot be controlled.

You cannot eliminate all three. You can, however, pin down the first and the second with a disciplined process, and accept the third as a known margin.

Color calibration for virtual makeup try-on: what is decided on each path

MaIA Try-On exists in two forms, and calibration is organised differently in each.

The photo-based API

In the photo-based virtual makeup try-on, the customer sends an image, the product — lipstick or foundation — is rendered on it and the image comes back ready to display. The palettes are calibrated to the brand's real products inside a project. In other words: this is not about picking a random hex, but about building, together with the team, the correspondence between each SKU in the catalog and its representation in the render.

That model fits well when the channel is not a browser the brand controls: WhatsApp, a campaign, a CRM flow, an app of your own. The trade-off is that lipstick and foundation are the products the API covers; the rest of the catalog is not rendered through it.

The SDK in the browser

The browser SDK, in early access since September 2026, covers thirteen products — lipstick, foundation, blush, face powder, under-eye concealer, eyeshadow, mascara, eyebrow makeup, eyeliner, bronzer, contour, highlighter and lip liner — plus a combined Full Look, in Live mode through the camera (everything processed locally in the browser, without uploading the photo) or in Photo mode. It accepts any color in #RRGGBB format and is hosted by the brand itself on its own domain.

That freedom is the advantage and also the responsibility: if the team can pass any hex, someone has to decide which one. That is where the calibration process stops being a technical detail and becomes a product task. If you are still comparing formats, the article on photo-based virtual try-on vs AR try-on helps place each option.

A calibration process in five steps

1. Define the real scope of the catalog

You do not calibrate 400 SKUs in the first week. Choose the lines where shade doubt concentrates: the best-selling lipstick family, the foundation range, the eyeshadows of the launch. The rest comes in later waves.

2. Fix a single reference per SKU

Before discussing hex values, decide which image rules. The usual choice is a controlled capture of the applied product — same light, same background, same camera, same reference skins — instead of campaign photos. Document that capture condition: it is the standard you will return to every time someone says "it looks off".

3. Propose the first version of the color

The reference yields an initial value per SKU. In the SDK, that value is a configurable #RRGGBB. In the API, the palette is built against the real products inside the project. In both cases, store the value with the SKU code, not with the commercial name: names change and repeat across collections.

4. Review with the people who know the product

Validation is not the engineering team's job. Sit down with makeup artists, the product team or whoever trains the sales staff and review the render on several skin tones and several devices. The corrections that come out of that session are usually few, but they are the ones that prevent complaints.

5. Version and govern

Treat the palette as an artefact with an owner and a history: who approved each shade, when it changed, which reformulation prompted it. When a new collection arrives, the process already exists and calibration stops being a project and becomes a launch routine.

Mistakes that keep repeating

• Using the packshot as the source of truth. The packaging and the applied product almost never share a shade.
• Validating on a single skin tone. A lipstick behaves differently on lips of different depths; testing on one face hides half the problems.
• Mixing finish with color. A matte and a satin of the same pigment do not read the same on screen; record the finish as an attribute separate from the hex.
• Not communicating the margin. A brief notice that screens may vary is honest and reduces friction afterwards.

Once the palette is calibrated, color stops being a debate and becomes one more piece of catalog data, reusable on the product page, in campaigns and in the conversation with the customer.

Want to test it with your own SKUs? Create your account and your key in the API documentation, or talk to our team to build your brand's palette.