Working profile for darktable

Hello darktable experts,

Darktable default working profile is linear rec 2020 RGB. I have a few questions regarding this.

Is there a technical reason for this default compared to Linear ProPhoto RGB? The color space Linear ProPhoto RGB is slightly bigger (covers more gamut).

I have no specific case. I am just curious.

I suppose, in theory, optimum is to cover any input with the smallest possible color space which cover needed gamut, given quantized step sizes in the color space, when an output is created, like a 16 bit integer TIFF or 8-bit JPG. I mean, I think I understand why a bigger color space is not necessarily ‘better’. On the other hand, DT pixel pipeline is floating point and in theory linear rec 2020 RGB could limit gamut when Linear ProPhoto RGB would not.

I am aware that this goes on and on with ACES-AP0 and AP1 being bigger and bigger. Again, this question is more for my own understanding, rather than a concrete DT use case or example picture.

I normally archive output in 16 bit TIFF ProPhoto RGB.

I think once you go to some colorspaces you can get negative primaries and imaginary colors. When you look at REC2020 is is smaller that prophoto but it falls in the human vision boundaries and runs along the and parallel to the to these boundaries… I think that is why it gets used over the even larger spaces…but this might be oversimplistic…

I have stumbled with fully getting my head around working with color spaces. I defer to the developers of DT because they seem knowledgeable on the subject. There was a time when I used ProPhoto color space for editing in Lightroom and GIMP, but then I questioned why I wanted to work with a color space that no monitor could display. It felt like I was working with imaginary colors. Please feel free to criticize my uninformed opinion here if you have sound knowledge of working with color spaces. I am here to learn.

So you have head room to push your edit and not clip values at the profile boundary.

1 Like

Hello, Thank you for the feedback.

I am aware that green and blue primaries are outside visible colors in CIE 1931 chromaticity diagram for ProPhoto RGB color space. On wikipedia I found " During the development of the Rec. 2020 color space it was decided that it would use real colors, instead of imaginary colors, so that it would be possible to show the Rec. 2020 color space on a display without the need for conversion circuitry." However I do have a color managed system, so I have the conversion available.

Same here. I think the key issue is if a modern full frame camera (I own a 2017 Canon 5D mk IV) with raw data from sensor → black/white points → white balance → demosaic → neutral curves would have such a large gamut that it would clip gamut using Rec 2020. In this case ProPhotoRGB would be better as a color space for a DT pipeline working profile.

I agree. However I do understand that when I send a file to a printing company or when I display on screen then I have to adapt my archived file ProPhoto gamut to a smaller color space for printer/paper or monitor using rendering intent.

Perhaps key issue is, again, if raw files after black/white points → white balance → demosaic → neutral curves have such a big potential gamut that ProPhoto would be better. Any subsequent edits in pipeline would also have more headroom before clipping using ProPhoto.

How much of visible color can a modern full frame or medium format sensor cover? Which color space is needed from this point of view?

I think I recall reading that ProPhoto does not handle compressed shadow details very well… That popped up a few times but I have no explanation or I am not sure if it is even true…

You might spend some quality time with Elle Stone’s articles:

https://ninedegreesbelow.com/photography/articles.html

Section C has some good articles on working profiles.

Most mainstream software requires the use of a working profile. I think that’s unfortunate, as a well-constructed camera profile will allow one to defer any color transform until export or display, without the need for an intermediate transform to a working colorspace. darktable’s doc regarding working profile is a bit obtuse, indicating that a separate working profile can be specified per module (???) but it doesn’t say whether it can be turned off (??)

In rawproc, I work my images in camera space, no color transform until display/export. Works just fine. and helps to minimize the manipulation of the image data…

2 Likes

Where does it say that? It isn’t exposed to users as far as I know.

OK. Thanks. I will check.

A color profile is a standard, I find that appealing, but maybe for reasons outside the question in this thread. Some spaces have nice technical properties (more perceptually uniform). However, for the question discussed here, I tend to agree with your approach, that is no limits in intermediate pipeline.

EDIT:

I have rawproc on my system.

So far, I tend to favor ProPhoto RGB as DT working space, since bigger and less limiting gamut. It would be very interesting to know if linear rec 2020 RGB is all that we need given modern sensors and gamut needed to have margin for DT pixel pipeline processing (or, for any other reason that a DT developer can contribute).

1 Like

Rec2020 covers the Pointer’s gamut almost 100% and is real, so there is little practical need for more.

What is pointer’s gamut? Aha! Color Gamut | Cinepedia, “Michael R. Pointer published in 1980 a maximum gamut for real surface colors, based on 4089 samples, establishing a widely respected target for color reproduction. Visually, Pointers Gamut represents the colors we see about us in the natural world”. I learned a new fact. Interesting.
…
EDIT: Color Gamut | Cinepedia “Colors outside Pointers Gamut include those that do not occur naturally, such as neon lights and computer-generated colors possible in animation”.

The set outside Pointers Gamut but inside visible range seems to be not empty. We enter the arena of artwork and illumination.

OK, Rec2020 covers Pointer’s gamut almost 100%.

But, what is the drawback of a larger space with a fraction of imaginary colors during pipeline processing? Some processing might perhaps need a bit of margin, even compared to Pointer’s gamut and rec 2020.

If I am in gamut, but in imaginary intersection of visible color space and ProPhoto gamut, will that not be managed when mapped to final output color space and rendering intent?

I think, from what I have learned so far, that DT will not start to malfunction if I set working profile to ProPhoto RGB.

Darktable offers a choice of working profiles (see module “input profile”), and “linear Prophoto RGB” is one of them. So no, I don’t expect dt to malfunction with that Prophoto space. And as we are working in floating point, resolution isn’t a real problem either. (resolution == colour difference between neighbouring RGB values).

As usual, one factor in determining what’s the optimal space is the kind of images you work with. Nature images have probably less extreme colours than theatre and such (blue LED spots…).

But Prophoto RGB would seem to be potentially troublesome as output profile, and in general, when you export to an integer format, the smallest possible colour space seems the best choice (as that gives you the least chance of banding).

its my understanding that unless you’re dealing with an already formed image (log, jpeg), real camera raw is not an image yet. (some dngs are already formed and not real raw data). The image is debayered into whatever space the software chooses. Each camera manufacture will have their own formula of choice for its interpretation (black magic film v5, log flavors, rec709, ect), but a knowledgeable person choosing a different interpretation does not make it invalid. just choosing a wider gamut can cause issues if the software is not up to the task of not just deal with the imaginary colors but also pulling those colors into the lower srgb domain that most people choose as output. Doing this can usually cause clipping, shifting and brightness issues if not handled well.

At the end of the day if you like your formed image your good to go , but I think rec 2020 is a storage color space that I can use if I want to push an exr and work in other software in the future. keeping the raw around is great because of new ai tools like dxo photo lab, it does wonders on some of my images.

OK, I agree.

Yes, I only use 16 bit TIFF with ProPhoto RGB for archive. I convert to other profiles for printing and web display.

OK and where does DT stand, when it comes to the issue you highlight? Will in gamut, but imaginary colors in ProPhoto RGB cause problems for some DT modules or other aspects of DT processing?

But that’s not in contradiction with using the sensor space as working space, as you have exported the image when you store it. So the conversion to a standard space happens there (and indeed, using a standard colour space for storage is probably the better choice).

1 Like

I can’t say for sure but if you see no issues on your end and like the pictures you’re developing then I wouldn’t worry too much about. I just cant’ say if having wider than rec2020 is providing any real benifit as a working space accept for situations where I might want to output to prophoto, but maybe others might know more.

Sorry, I am an engineer. I analyze system pipelines for a living :slight_smile:, but technical color management is not my area of expertise.

I also think that the end result aesthetics is what counts: Have a creative idea, use the camera, process, print and frame.

correct me if I’m wrong but there is no sensor color space, just data that the camera manufacture turns into an image based on their liking or use case, but if you’re not getting it after they turn it into an image it’s just data to be developed. (not a formed image)

1 Like

Well, you have three primaries (the red, green and blue filters), with a given range. That seems enough to define a colour space, after demosaicing of course (before that, we don’t have RGB triplets to define colours). The key is the presence of three primaries. The colour space defined by those primaries is translated to the working profile in the “input profile” module in darktable, using the “standard color matrix”.

While we are dealing with raw files, the camera manufacturer hasn’t done anything to the captured signal (in theory…). Specifically, they don’t turn those data in an image “based on their liking or use case” (unless you all of a sudden switch to talking about the in-camera jpeg), darktable does, and you should be able to impose your likings or use case.