Confused about input color profile in DT

Processing
1

My laptop (SO Ubuntu 24.02 DT 4.81) is connected to a regularly calibrated ben-q sw240 monitor able to work in the Adobe rgb color space.
When I edit a raw image in the ‘input color module’ by default DT shows ‘standard color matrix’ as input profile (I can understand this!) but ‘linear REC2020 rgb’ as the working profile.
Taking into account that I want to export the edited image to be sent to an external lab as jpg (rarely as tiff) setting the output color profile to the Adobe rgb color space I wonder whether while editing is preferable to set the working profile of the input color module as Adobe RGB (with a consequent sizeable shift of colors in the image) or leave it as linear REC2020 rgb?
Thanks
Vittorio

2

The output profile has no bearing on what should be used as the working profile, except that the working profile should obviously be bigger. Adobe RGB is also not linear, so isn’t even suitable as a working profile in darktable.

Unless you have very good and well-founded reasons for using a different working profile, and fully understand the implications, don’t change it.

3 Likes
3

Images are usually stored as RGB triplets, with values spanning a certain range. But without something to say what those triplets mean, you cannot know which colours are present (*). So you need something to translate the RGB values to colours as you see them. That’s what colour profiles are used for.

The three profiles have different functions:

  • The input profile describes what an RGB triplet from the input file means in terms of a standard colour model, the colours are then translated to the working profile. Which profile to use depends on the input: for a camera, it’s either the standard colour matrix, or a dedicated profile for the camera, for a jpeg image it will usually be sRGB.
  • The working profile is where you do your editing, as darktable works internally with floating point values, you want this profile to be as large as possible, and linear (so most operations reduce to additions and multiplications and combinations are predictable). That makes sRGB and AdobeRGB bad choices for the working profile.
  • Most working profile are much too big for use in most output formats (for several reasons), so you will want to use a smaller output profile to export your files. Which is best depends on the use of the output, for most print shops sRGB is best (for that purpose!), or AdobeRGB if the printer or shop can use it.

So darktable “translates” as needed between the different colour spaces, and there’s no special relation between the choices for input, working and output profiles.

As @Donatzsky said, unless you have a good reason to change anything, leave them at the defaults. (Changing the output profile to e.g. AdobeRGB when your printer wants it, is a good reason.)

(* : different profiles also cover different parts of the colour space we can see. Have a look at this wiki page: the “horse shoe” shape represents the colours we can see, the various triangles show what part of that is covered by some popular colour spaces). As most file formats use integer values, you only have a limited number of “steps” for each colour component. So you want a large space to cover more colours, with risk of banding, and a small space to get subtle colour graduations, with the risk of ‘out of gamut’ colours… No one claimed this stuff is easy :wink: ).

An extra complication are device profiles. While they are also called profiles, they have a completely different function. Never use one of these as a working or output profile…

3 Likes
4

So basically, sRGB is “small” because for 24-bit RGB formats it captures most colors with relatively little banding?

5

Perhaps a little bit more clear wording would be to say that sRGB is defined to be small in order to prevent banding when only 24-bit color is used - and also taking into account which colors would have been possible on typical displays of that era (think of CRT displays from the 90s).

1 Like
6

So if 48-bit color formats were the norm, a larger space would be commonly used? That is, if the displays could also handle such tasks

7

No, it’s small because it covers only a small part of the color spectrum. It has nothing to do with the encoding.

Look at the diagram here:

Notice how the distance from each corner of the gamut triangle to the white point changes depending on the color space. With 8 bit encoding we only have the 0-255 integers to cover the distance, while with 16 bits we would have 0-65535. This is why, with the same number of bits, a larger gamut might have more banding.

Notice there isn’t really anything stopping you from, say, encoding an image with 8 bit ProPhoto RGB. It just doesn’t make any sense to do so, because it would likely cause too much banding.

1 Like
8

Output profiles are really about the rendition medium, where the image gets displayed. The ideal is to have an output profile with gamut and tone curve that represents the displayable gamut of the destination medium, and tone-curves to handle any non-linearity of the medium. So, if a printing concern offers profiles for their printers, it is best to use them. If the say just give us sRGB or AdobeRGB, do that, as they should map that to their printers, or set the printers to correspond to that.

sRGB is only medium-specific in that it approximates CRT displays of the day, and still works to an extent because a lot of consumer LCDs have been programmed to mimic that CRT gamut and tone response.

9

Hmm I didn’t exactly say what i wanted to. By “most” I meant most colors that avergae human may need, so you’re not missing out too much.

By looking at the diagram it seems that there’s a huge portion of blues, cyans, greens and yellows missing in sRGB. But when I intend to share images online and maaaaybe sometimes have them printed, sRGB should be good enough, right?

10

So far all the color profile topics discussed above seem clear to me. But what I don’t know if my thinking is correct about is the following. Maybe some of you can give some hints and correct me …

The output profile is made to adapt from the intermediate to the viewing device. In case of a regular display, it may be sRGB, so let’s assume this for the following thoughts. This will account for the display’s behavior and therefore is kind of the inverse of the display’s response itself. If the goal is a print, and I get the profile from the print shop, this is then the same, it’s the inverse of the whole influence factors on the print color, e.g. ink color and paper color. In case the color space of the print medium is a subset of sRGB, it should not matter if I use the profiles from the print shop or hand over an sRGB picture and the print shop does the conversion and trimming (if the same algorithm, or, rendering intent, is used). If I want to view a preview of the printed picture on the display, I would have to use the inverted profile of the print shop, but after destructive conversion loss was applied by the regular print shop profile. So the difference between a preview of the printed picture and the picture in sRGB is the gamut loss from the conversion. Otherwise, it should be the same.

If the print shop color space is not a subset of sRGB, then there might be colors in the picture that could be handled by the print but not the display. In this case, it would make a difference if I hand over the sRGB, as then, colors are lost. However, these are colors that I was never able to preview, and therefore it might be beneficial to avoid them and handing over an sRGB picture might be the safer choice.

Therefore, high gamut displays make sense if the intention is to output to a medium which has itself a high gamut, at least in some areas. However, in the color ranges of the output medium that are well below the gamut of the display, the difference between edit and preview might be high, and it is advisable to use a preview based on the print shop profiles, as otherwise the gamut loss would not be accounted for in the edit.

Do you agree with these findings or am I missing something?

And if the findings are, at least partially, correct, is there a way to see from the profile data which scenario I have in a particular circumstance, such that I am able to avoid any surprise regarding colors on the output medium?

Edit: Adding to the last sentence: In darktable of course. It’s clear that a direct comparison of the profiles can reveal these issues, but can this be seen inside darktable?

11

I think you’re almost there.

I think of it this way: the output profile gives bounds and meaning to the RGB triplets that represent each pixel in the file. If you have a file that is 2x1 pixels in size and is RGB, the first pixel is 125,125,125 and the second pixel is 230,230,230, you can only know what shade of gray those are if you know the output profile.

A display’s maximum gamut may conform to sRGB, but the display needs its own profile in order to normalize it’s physical changes in order for its color and contrast to be correct. When you generate an ICC profile for your screen, or your printer provides you one, that profile describes the output space of that device. In darktable, you can use the softproof feature to load that devices profile and emulate it on-screen so you can achieve a pleasing result.

Colors are not “lost” but rather those colors that are in gamut for the printer will not be used without a color space conversion and/or changing the rendering intent. It depends on how your print shop’s software is going to handle that.

At least theoretically, you always want to edit in a large space, and if you can also view in a large space, that can also be benifical. When you’re going to output to a medium with a lesser gamut, then use the softproof. You should always be able to go from a high gamut to a lower gamut and end up with something that looks good on the first conversion.

1 Like
12

Yes, that’s likely what I meant. If I edit on a wide gamut display, I could cover these colors, but not if I export to sRGB, and if my workflow is based on sRGB (i.e., the sRGB softproof is always on), I cannot have any out of gamut colors of sRGB on my print (assuming everything is calibrated), even if they appear in the processing pipeline somewhere between input and output color profile.

Sure, within the pipeline, you want to have more wiggle room such that the rendering intent is not applied after each operation, as out of gamut colors (regarding output profile) may only exist somewhere in the middle of the pipeline and may later be brought back into gamut again, e.g. by an output transform (sigmoid, filmic etc.).

From your answer I read that my understanding of the topic is clear so far, so thanks for taking the time! Now I have to better apply it in practice, which is not as simple as the theory.

A little side story: I have been at an exhibition of Steve McCurry in the Ernst Leitz Museum in Wetzlar, Germany a couple of years ago, and I am still so impressed by the photographs I saw. I mean, photographs that I already knew for years (I have seen many of them in the original magazine prints or on the internet), but besides the impressive size of the prints, the color was several levels above everything I had seen before, the pictures really stood out color-wise. I really need to figure out what made the difference, many of the pictures were shot on film, but not all, and I wonder what the processing chain was that made them so beautiful. They were printed by whitewall, maybe they have a secret sauce they put in their printers? Who knows …

13

I am going off on a tangent here, so please forgive me. I edit my raws in DT and export as 16 bit tiffs in Adobe RGB in case of further editing later on in GIMP. So I was wondering what profile you would recommend for further edits in GIMP.

14

If you’re not going to do any more intense color or luminance manipulation, then 16 bit tiff is fine.

If you want to do more in gimp, then 32 bit and use a linear profile, like Linear Rec2020 or Linear ProPhoto.

15

Thanks for the reply @paperdigits I recently discovered the xcf export option from DT which is great as well for the 32 bit file

1 Like
16

One point to keep in mind: there are two very different “profiles” in play here:

  • colour spaces like sRGB, basically device independant, which describe the meaning of RGB triplets (or YMCK, but that’s not really relevant for darktable) as observable colours (based on a model of human vision, etc.)… key is that those are device-independant. Those are often called “profiles” (also within darktable…) but should be called “colour spaces”
  • correction profiles, specific for a given device (this can be a model of screen, or better, an individual screen, or a printer/ink/paper combination). Those profiles indicate where and how the colour rendering differs from the rendering according to the colour space used. They are not colour spaces, and by definition device-dependant.

So you convert your image to a colour space on export form darktable, and then, at the moment the image is printed or displayed, the proper device profile is applied.

Device profiles should not be applied on saving an image: different devices may need very different corrections, so applying the correction for your screen may be (and probably will be) wrong for anyone else. They would have to undo your correction (to get to standard colours) before applying their correction. Not a nice look if they forget to undo your corrections first…

5 Likes