Skin tone fairness starts at the camera, not the model
ยท 6 min read
Fairness in dermatology AI is usually discussed as a modelling problem. Reweight the loss, resample the minority group, add an adversarial head to strip the protected attribute. Those are real techniques and they are aimed at the wrong stage.
At Healoncal we assess skin from ordinary phone cameras, which means I have had to look closely at what happens before any model runs. Most of the disparity is already baked in by then, and no loss function reaches back to undo it.
The obvious problem: the datasets
Public dermatology image sets skew heavily toward lighter skin. This is well documented and widely repeated, so I will not belabour it. Train on a distribution and you inherit it.
What matters more is that resampling does not fix a data problem of this kind. Upweighting a small number of darker skin images does not add information, it just increases the influence of whatever few examples you happen to have, including their quirks. You get a model that is more confident about a narrow slice, which is worse than one that is visibly uncertain.
The less obvious problem: the disease looks different
Many dermatological signs are described, taught and annotated in terms tuned to lighter skin. Redness is the clearest example. Inflammation on lighter skin reads as erythema, a recognisable red. On darker skin the same inflammation frequently presents violaceous, brown or grey, or is not visible as a colour change at all and shows up instead as a change in texture, thickness or scale.
So a model that has learned to key on redness has not learned inflammation. It has learned inflammation as it appears on one part of the population, and on the rest of the population the feature it depends on is simply absent. That is not a bias in the weights you can regularise away. The signal it was trained to find is not there.
The same holds for the vocabulary in the labels. If the annotation guideline says look for redness, then careful annotators following it correctly will under call inflammation on darker skin, and your ground truth carries the error before training starts.
The problem nobody puts in the fairness section: the camera
This is the part I did not expect and it changed how I build.
A phone camera does not hand you the sensor's view. It hands you the output of an image signal processor that has already made a long series of decisions. Auto exposure picks a brightness target. Auto white balance decides what counts as neutral. Tone curves, noise reduction and sharpening all run. Increasingly a learned enhancement stage runs too.
Those stages are tuned, and historically they have been tuned and evaluated on subjects that skew light. Point a metering system calibrated that way at darker skin and it tends to underexpose, because the frame reads as darker than its target. Underexposure costs you signal in exactly the tonal range where the clinical information lives, and then noise reduction smooths what little texture variation survived, because at low signal the processor cannot distinguish fine texture from noise.
By the time the JPEG exists, the discriminative information has already been compressed away for one group and preserved for another. The model is being handed two different qualities of evidence and asked to be equally good at both.
You can train on that output forever and never recover what the pipeline discarded. This is a measurement problem, and it belongs with the hardware, not the optimiser.
What we actually do about it
Constrain capture rather than hoping to fix it later. Lock exposure and white balance to fixed values where the API allows, so that two captures are comparable and neither has been auto corrected into a different colour space. Capture the least processed format available. Require a reference in frame where practical, because a known patch gives you something to normalise against and turns a colour judgement into a relative measurement.
Record the conditions as data. Device model, whether the flash fired, ambient light estimate, exposure settings. These belong in the record, because a result that depends on them and does not report them is not reproducible. It also lets you discover after the fact that performance tracks a device rather than a diagnosis.
Reject bad captures at capture time. If exposure in the region of interest is outside the usable range, ask for another photograph while the person is still holding the phone. The alternative is a confident prediction from evidence that was never adequate.
Report per band, never aggregate. We stratify metrics across skin tone bands and treat the worst band as the number that describes the product. An aggregate AUC on a population that is mostly one group is a statement about that group with extra steps.
Do not train the model to be blind to tone. Skin tone is clinically relevant information and adversarially removing it removes signal a dermatologist would use. The goal is not a model that cannot tell, it is a model that is equally reliable either way and honest about when it is not.
What I cannot claim
We have not solved this. Our own data still under represents the darkest bands relative to where I want it, and the tone banding schemes in common use are coarse proxies that were not designed as measurement instruments. Locking camera settings also loses you some of the quality the processing pipeline genuinely provides, which is a real cost, not a free win.
What I will claim is that stratified reporting is built in rather than added for a reviewer, and that the worst band is the number we hold ourselves to. That is a commitment about disclosure, which is the part I control. Closing the gap is a data collection programme and it is slower than any modelling change.
If you are working on this, the useful reframe is that fairness here is largely a measurement problem wearing a machine learning costume. Ask what your camera threw away before you ask what your loss function should weigh.
Related: a clinician who cannot see why will not act, on why per metric output beats a single score.