Natural skintone with reference colors


This posting describes a way to match skin color and white balance in Darktable using a reference palette.
This works similar to color adjustmens with a grey card or a color checker. This time a defined skin color is the reference to match skintones to.


Get a palette
First you need a skin color as reference. You find many reference palettes on the web
Find one that matches your needs and download it as a graphics file on your pc.
This example uses the reference color ‘Apricot’, #F9D1B8

Create a watermark file
Convert the image file into a vector graphic. You can use Inkscape for that with the following parameter:

inkscape -f palette.png -l palette.svg

Import watermark into Darktable
Just copy the SVG file into you Watermark folder like described in the manual

Load a portrait image
If you don’t have one already I recommend some free RAW practice files. I took one of these ones:

Photographer: William Clark
Instagram: @williamclarkphoto
Model: Jess Gagen
MUA: Grace Coole-Green
Hair: Stephen Manton

Matching the skintone

Open your image in Darktable and add the palette watermark to it.

Place the reference palette
Modify the watermark’s dimension and position so that the palette is near a ‘good’ skin part. ‘Good’ means:

  • Nice and even color
  • No shiny/white areas
  • No shadows

Find the right color
Search for a palette color that is most similar to your ‘good’ skin tone

Get reference sample
Move the watermark away from the skin to a corner and take a sample from its color using the color picker.

Get skin tone samples
Add more samples from ‘good’ parts of the skin. The samples should have similar values for red since you will start your modifications with red color in the next step.
The color samples should be taken with the ‘mean’ color setting to get the average color of their selected areas.

Match brightness
Now match the samples’ brightness with the reference color. Increase the exposure until the red color reaches the reference.
Note that the SVG overlay is not affected by your edits, the reference color will remain the same.

Adjust white balance
After brightness of skin tone and reference are near to each other start to modify the white balance.
Since red currently matches the reference, green is the next color.
Note that the values of red are being affected. This is not a problem because we will modify each color a few times.

Continue with the blue color. After that you will find that red and green have moved away from the reference. Adjust the values for red, green and blue again until they come as near as possible to the reference. For red adjustments you take the white balance now, not the exposure anymore.

After these modifications you can revert your exposure adjustment if you want.

Final result:


Thanks for the tutorial.

One thing that bothers me – how does the watermark module operate with respect to embedded colour profiles? I saved some reference jpegs/pngs from the link you gave – some of them didn’t have a profile so I needed to assign sRGB (which was a guess, because there’s no way of knowing if that was the intended profile for the file). Then I converted them to SVG and imported. When using those files in the watermark module they become more saturated than the originals, which tells me something’s wrong with colour management in the watermark module (I think it assumes my monitor is an sRGB-one, not a wide-gamut one). Have you noticed this?

I just noticed a slight difference in the colors. Color from the palette was in RGB 249,209,184 but the color sample in Darktable says 248,209,183.
This difference was too low for me to investigate further.

After your reply I checked the colors again. The screenshots in my post represent the colors that Darktable’s color picker saw.
Then I checked the original PNG file which had exactly the colors of their corresponding codes. Same is for the Image embedded in the SVG.

Right, so the color picker is not affected by this issue – good.

I prefer using the color look up table module to fine-tune skin colours once you get that Temp and Tint values where they need to be.

Where are you getting this? I am only checking your screenshots. Since the JPGs are lossy, the RGB values jump around a bit; but some pixels do land on 248,209,183.

I wonder whether converting from PNG to SVG using Inkscape is the best solution. I haven’t used Inkscape for a very long time but when I did the colour management wasn’t complete. If I had to use Inkscape, I would at least create the SVG from scratch using the app itself.

1 Like

I was thinking about this as a potential issue. I actually used Affinity Photo to do the conversion and it automatically converts from the embedded profile to sRGB (I don’t see any option to actually retain the original profile). I don’t know much about the SVG format but maybe it doesn’t let you use other colour profiles than sRGB?

Honestly I didn’t put any considerations into color profile when proceessing the image files.

While searching for a way to get one of these palettes into Darktable making the palette with Inkscape itself (just some squares with the corresponding colors) was an option for me. But it was easier to save palette images or screenshots as PNG and convert them into SVG.

I think that I try it with Inkscape. Moreover I will try to add a part with an alpha channel so that a color area gets a fading out effect where I can better see if the color fits to the skin tone.

a) Alpha blending
I took my time and made a palette with inkscape. One square with a skin color, a second one above with the same color and a gradient to transparent.
Darktable showed that palette correctly and it is now much more convenient to choose the right color.
Next I will make a stripe with all my colors in one SVG to be able to scroll through my colors with the ‘x-offset’ slider.

b) The color deviations
As described above i made a palette in Inkskape. After saving the file I checked the SVG file with a text editor and found out that the SVG had the exact colors in entered in Inkscape.
After loading the SVG in Darktable there were slight differences between the colors in the SVG and in the colors the color checker saw:

After experimenting around I found out that the differences only appear when using the ‘mean’ option, ‘min’ and ‘max’ were fine (same for LAB colors)

I reproduced that with other single-colored overlays and with images: The color checker did not show the correct color with the ‘mean’ setting.
So this part seems to me a bug in Darktable or am I wrong?

I understand that you would like to get proper skin tones by visually matching them to a reference palette. I prefer a simpler method though. I just import the reference palette to darktable as a jpg/png file and then measure the target tones (usually for highlights, midtones, and shadows) using the color picker in Lab mode. Finally I try to get those values in my photo (using white balance and color balance).
I don’t think RGB space is a good choice for these kinds of measurements because the lightness affects the values for all channels. Instead, you can safely lighten/darken the skin tones by keeping their a* and b* channel values the same. I remember that @harry_durgin had created a reference chart (Lab values) not only for skin tones but also for different kinds of things including sky, grass, etc. I wonder if it is still available since his website ( has been down for a long time. Anyway for correct skin tones for printing, the general thumb rule is to keep their value for a* channel lower than b* channel (unless for creative processing that you know what you are doing). Also, midtones are usually more saturated than shadows and shadows are usually more saturated than highlights (higher a* and b* values in Lab space means higher saturation).

Here it is: Average colors after sampling 1,000s of images

…and here’s a video where he uses this chart:

I used it for some pictures and it was very helpful for me.
Some parts of his website are still available via
Wayback Machine
I scrolled through different timestamps and found a few RAW files @harry_durgin used, wish there was a complete archive somewhere.

Back to the point of using LAB instead of RGB, you’re right. I’m so accustomed to RGB that I didn’t think about that.
So I just would modify exposure so the image matches the brightness of the reference colors to find the right color visually. After that I would revert the exposure and change the colors via LAB and keep the image’s brightness untouched.



Also :

1 Like