Thanks @RawConvert for doing these tests. Many people have probably been wondering about these matters.
The sRGB_v4_ICC_preference.icc is a so-called LUT profile which, instead of a matrix and curves, contains look-up tables for different rendering intents that tell how colors should be mapped from a reference medium to the output (or something along the lines of this).
sRGB (web-safe) built-in profile in darktable is a profile of the “matrix + curves” type.
The error:
[dt_ioppr_set_pipe_output_profile_info] unsupported output profile 0 /home/bill/.config/darktable-3jul/color/out/sRGB_v4_ICC_preference.icc, it will be replaced with sRGB
just tells that darktable won’t be able to use profile internally for some things. Namely, the output profile is used for:
- color managing the sliders in color balance rgb and color calibration (so nothing that relates to the final image, just UI)
- final gamut mapping in filmic rgb v6 color science
These functions will then fall back to the built-in sRGB profile. However, the output color profile module will apply the requested color profile and intent (using Little CMS 2) at export. This is also apparent from the results you posted.
-
The sRGB web-safe rendering (first image) clearly shows gamut escape in the brightest highlights - RGB channel values higher than 1 clipped, thus the initially orange highlights turn into yellow when the red channel can’t go high enough.
-
The v4 profile with perceptual rendering intent preserves the hue better in the highlights and results in kind of a heavy compression.
-
The v4 profile with relative colorimetric intent also shows the gamut escape in highlights and looks pretty similar to the first one there. It also seems like a bit of an outlier – the shadows are quite a lot darker than any of the other renderings. I’m not experienced enough in ICC profiles to be able to tell what might be the reason for that. However, the whitepaper about usage of the v4 profile might be a good place to start if someone wants to find out.
-
sRGB (web-safe) with relative colorimetric rendering intent is essentially similar to the same profile with the perceptual rendering intent. This is to be expected since the profile doesn’t contain any “intent look-up tables”.
One of the discussions about LCMS2 you are referring to might be this one on GitHub. There it is stated that LCMS2 doesn’t do gamut-mapping at output or honor the intent. This seems to stand true in cases where a “matrix + curves” type profile is used. The necessary information (LUTs) to apply the perceptual rendering intent just isn’t present. Someone linked this comment from the author of LCMS2 where it is stated that LCMS2 applies the rendering intent if an intent table exists. This is pretty much consistent with your findings in this thread, and I’m quite glad to see it in action. So, well done! I hope others also find this informative.