Uneven skin tone and smoothness

Overview

Uneven skin tone measures how much facial skin colour varies. Analysis includes variations in darkness-lightness and variations of the chromatic nature (blue-yellow / red-green). The metric is sensitive to a large spectrum of spatial scales from the smaller details to smoother trends across larger distances. However, the smallest details covered by the texture metric are not included to the uneven skin tone analysis. Smoothness is its inverse, normalized for “good number goes up” UIs. Both are computed from the same underlying analysis.

components:
  - uneven_skin_tone
  - smoothness
request:
  query: "components=uneven_skin_tone,smoothness,uneven_skin_tone_visualization"
response_path:
  - "results[].description == \"uneven_skin_tone\""
  - "results[].description == \"smoothness\""
value_range: [0, 1]
also_request:
  - uneven_skin_tone_visualization
warnings: []                   # these metrics emit no metric-specific codes

When to use which

• uneven_skin_tone — diagnostic UIs (“where does the tone vary”).
• smoothness — improvement-tracking UIs (“your tone is more even — score increases as condition improves”).

Don’t surface both in the same UI; users find the inversion confusing.

Reference imagery

Reference imagery for this metric is not yet published.

Rendering notes

const ust = response.results.find((r) => r.description === "uneven_skin_tone");
const sm  = response.results.find((r) => r.description === "smoothness");

For an improvement-over-time UI, prefer smoothness. For a “where is my tone uneven” diagnostic, prefer uneven_skin_tone. This is a complement to hyperpigmentation and dark_spots — surface them together for a complete pigmentation story. Avoid using all of them as separate dials in the same UI; pick one summary score and put the others in a “details” panel.

Beyond the top-level value, each finding carries two sum_measures — Luminance variation and Chroma variation (on smoothness these read inverted, so a higher number is the better outcome) — plus a per-region breakdown in measurement_locations[] (one entry per face region, each with its own value and polygon-area visualization_data). A region scores -1 when its mask couldn’t be sampled — treat that as “region unavailable,” not a real low score.

Edge cases

• Lighting gradients (window light from one side) materially elevate this score. Encourage front-on diffuse lighting.

local_warnings[]

These metrics emit no metric-specific local_warnings[] codes; they inherit the global image-quality codes. An unsamplable region returns value: -1 (no status code).

Related

• How metrics connect — smoothness is the inverse of uneven_skin_tone (same analysis).
• Visualization data — Cat D (AOI + mask + advanced); 2 intensity levels by default (categorical 1..2).
• Rendering recipes → Polygon areas — paste-ready renderer.
• smoothness shares this metric’s advanced visualization data. The API has no separate smoothness_visualization switch — request uneven_skin_tone_visualization and the response carries advanced viz on both metrics.