The histogram of the exported file is meaningless.
darktable has 5 profiles :
- input, which usually is the standard matrice if you retouch a raw file,
- output, which is either the monitor ICC profile for previews or the file space for export,
- histogram, which is used for both the histogram and ill-named “over-exposure” alert,
- softproofing, which is used to preview the color appearance of the image printed on some medium (that is not the monitor) and display out-of-gamut alerts.
- working color profile, which is used for pixel operations in RGB.
Softproofing is meant only to preview the appearance of the printed image, noticeably when the printed medium has a much smaller dynamic range and gamut volume than the monitor. It is only to assess the quality of the gamut mapping result and black point compensation, and ensure no weird posterization, clipping or other gradients flattening happens.
Gamut alert is meant only to display pixels having a color in the current pipeline which has no target in the destination color space. But LittleCMS2 does gamut mapping, when converting to another space, so these pixels will not necessarily have their color clipped in the destination space, but they will get remapped to another color, chosen with the colorimetric intent. The gamut alert only says that these pixels will change color for the sake of preserving overall gradients in the target space.
So gamut alert ≠ gamut clipping. People really need to stop freaking out with the various misleading alerts presented to them in darktable to feed their anxiety.
As a hack, you can use the gamut alert against a large-gamut RGB space (like Rec2020), defined as your softproofing profile, because that large RGB space will act as an approximation of the visible locus, and it is generally good to ensure that your retouching doesn’t push any pixel outside of the visible range, because then, gamut mapping becomes a lot more difficult at export time.
But anything else is only mumbo-jumbo that looks scientific without having any real meaning.
The only histogram relevant to us would be the histogram of luminance, which will be color-space independent and present true over and under-exposure (unlike the current overexposure alert as of darktable 3.2.1, that got re-written last week in master). But we don’t have one.
RGB histograms in different RGB spaces don’t hold different meanings and I’m not even sure the histogram shows the file after the gamut mapping step. If the picture is over-exposed, you will get the same bump at the right of the histogram, no matter the space. If the picture is over-saturated, it will not necessarily show in the histogram, and anyway the gamut mapping should take care of most of it.
As long as the image looks good in the screen, forget the alerts, histograms, and engineer-style views, and trust your eyes.
I think that ICC color profiles, color spaces and science-y big words have lost people more than they help them. The only relevant question is to assess if you have nice gradients in your image or if some part presents a solid color blob or posterization. Everything else is irrelevant.