Working profile for darktable

To consider this fully, one needs to understand the entire raw processing pipe…

First, from the time a raw file is ingested to the time the rendition export is puked to a JPEG, there is one rubicon that divides the image state: demosaic. Prior to that, it’s just a pattern of measurements, after that it’s the RGB triples. So, the term “raw” really applies to the left-hand side of the pipe, to those measurements. After that, the colors are now encoded but the essential part of the measurement is still intact, “energy-linear”. Accordingly, those colors still reflect the spectral resolution of the camera, so I will choose to describe them as “camera space”.

That’s also because the color management process is dependent on such an input description. A color transform requires metadata about the input data, which nominally are the primaries in the camera profile. Those primaries, nine numbers that are colloquially described as the “redd-est red, green-est green, and blue-est blue” of the profile are used as a matrix in a multiplication of each image RGB to transform the image data to the destination gamut. Matrix-wise, a camera matrix doesn’t look any different than a ProPhoto, sRGB, or other matrix, so it can be plotted chromatically (in that color horseshoe thing) like any of the others. When you do that, kinda looks like a ‘gamut’ but it really isn’t, more of a ‘scope of spectral response’.

So, in the act of making such camera profiles, the measurements don’t usually “ground-out” to full black and full white. Indeed, due to dark current coursing through the sensor electronics, you’ll never get a true 0,0,0 measurement of black in the scene. I know less about white in this regard, but Elle Stone in one of her articles described how to add hard-coded black and white entries to a target shot data to make a camera profile that is “well-behaved” with respect to handling all the colors. That’s the essential characteristic of working profiles, proper representation of color through the entire gamut, and the reason a lot of softwares use such in their pipeline. So, in those softwares, right after demosaic, the original camera colors are transformed to the gamut of a working profile and the RGB-oriented operations are applied from there.

Thing is, one can make camera profiles behave. So, bear-of-little-brain here thought, why not just ditch the working profile and save the color transform to the end of the pipe, when the data is either rendered in the display profile gamut or rendered to sRGB (or, choose your own poison) for export to a file. Ta-da, seems to work fine. Also, I think such destructive operations such as HSL saturation behave less-destructively when applied to the original “camera space” rather than some working space, or, horrors, the renditon space.

The upshot of all this is you really need to understand every step of the pipeline to fully comprehend the importance and impact of using a working profile…

2 Likes