It would be great if there is a web page with the (more or less?) consensual things discussed here. There are zillions of pages about color management, rendering intents, etc, but few explaining carefully which is a recommended workflow for a photographer, specially a linux one.
I’m not sure what you are referring to, but, yes, zoom affects certain tools in RawTherapee, and that is documented and visually informed via the 1:1 tag. Those are not bugs. But probably you are referring to something else.
I’m far from claiming that RT is bug free, but at least I’ve never encountered one that messed up completely the output of my pictures, like this one:
Notice that a bug report was issued and rudely closed without even looking at it (hence the number of open bugs is not a reliable metric):
Anyway, I do not use Darktable except on emergencies, so I could be very wrong. But I found this bug after playing with darktable for 10 minutes after a long time using RawTherapee.
I don’t understand why the histogram gets special treatment. The histogram presented for use should be based on an image in a particular tone and color state, however that image got there.
The article I wrote attempted to discuss the basic needs of color management in generic terms, without the baggage of a particular implementation. The OP is trying to understand it all, both concept and implementation, and it’s rather tortuous. I go back to dcraw as the illustration of the essential color management workflow, camera → output; everything else is amalgam to, and subdivision of, that essential operation, crunching down camera color to something that can be rendered somewhere…
Turning off opencl often cures many of these weird issues…
No opencl here.
As you already have realized, color management (or color in general) is at the very least an elusive topic, and needs lots of explanations, knowing lots of different notions about color theory, maths and, perhaps, common sense. I’m not going to enter that discussion (endless discussion, maybe…).
I’ll try to make easy explanations, as short as possible, but even then, this post is going to be lengthy. Sorry for that. And I’m going to explain things from the RawTherapee point of view. I have no clue about how darktable or other software manages colors.
As others have already said, you should always work within a color management environment if you care about showing the «right» colors. Not using a color managed workflow or exporting without an embedded profile is prone to errors and weird colors (it may not happen, but yo can’t be sure at all).
If you understand color management as «a way to convert colors between devices so all of them show the same hues», then the way it works is pretty simple (for us, users; it can be a nightmare for developers, though).
In a raw developer the image has certain colors, which we are processing and modifying to taste, but we can’t see them. They are in the so called processing engine. To be able to properly interact with the app tools, we have to see the image, so a conversion is made, from the profile the image is in (the working profile), to the display profile (that’s why a properly calibrated display is of utmost importance). Again: you will never ever see what is «in» the processing engine, but you need to get an accurate conversion of that image, so you can see as accurately as possible the colors the engine is dealing with.
If you are happy with the results, you export your image with a convenient profile, by means of another conversion from working profile to output profile, so colors remain the same as they were in the processing engine (let’s put aside out of gamut colors for a while).
Then, somebody else downloads your image, and by means of another conversion from the output profile to a display profile (the display used by that somebody), the image colors remain the same.
If you don’t embed an output profile, your raw processing app WILL apply certain profile to the image (in RT is sRGB, by default), but will not say anything to anybody about it. So it is encoded in certain color space, but nobody knows it. It’s like giving somebody some coordinates to find a treasure, but nobody knows which map they belong to.
Let’s say after that an application loads that image, and as there’s no profile embedded, it will ASSIGN an sRGB profile… There’s an important distinction between converting and assigning profiles: «converting» means recalculating the RGB values of each pixel, and even if they change, the color will remain the same. It is just that the coordinates of such color are different in a different color space, but the color remains the same. On the contrary, «assigning» means preserving the pixel values (the coordinates) and using a predefined color space. If the image has been encoded on sRGB and the assigned profile is the same sRGB, then you’re lucky. If not, then colors will certainly change. How much will depend on how different is the color space used for conversion from the one used as assigned color space.
Following the treasure example: you have given coordinates pertaining to Poland, but the treasure hunter starts using a map from the USA. Most probably he won’t find the treasure at all…
So, from my point of view you must always embed a color profile. That way you will at least be relatively sure about people using proper color management will see your image more or less like you intended. The rest will or will not see it like you wish, but you have no control over that. If you don’t use an embedded color profile, you won’t have any control over anybody looking at your image.
Now let’s talk about soft-proofing and the image rendered on display.
There is an unavoidable fact: your display will never ever show colors outside its own gamut. This seems a silly sentence, doesn’t it?
Usually your working profile will be a large one. Much larger than any display will currently be able to show. Professional display or not. You can’t see all possible colors from a large gamut. And usually you won’t see all colors of an output image, unless you have a good wide gamut display capable of showing 100% sRGB, and you save your image with an sRGB profile.
Why is this important? Because with your Dell display you will never see 100% of the possible sRGB colors (according to specs, it covers 99%). And if you wish to save your image with, let’s say AdobeRGB, then for sure you won’t ever see all the possible colors. The display usually will never show the output profile, even when soft-proofing.
In RT the conversion while soft-proofing may be like this (depending on the combination of buttons and settings): working profile > output profile > display profile.
Why is it like that? Because the display can only show its own gamut.
About browsers and the dreaded Chrome/Chromium (at least until version 85): some time ago I opened a thread about the convoluted way that browser handles (handled?) color management. In short: if you wish to be sure about Chrome rendering about the same colors as Firefox and RT, you better use a profile with a standard sRGB TRC («gamma curve»).
If for some reason you still wish to save your images as sRGB without an embedded profile, you better use an industry standard profile: sRGB IEC 61966-2-1:1999. This is the one which almost everybody will default to. But as I said, to me this is not advisable.
The profiles from Elle Stone are better in my opinion, but they will be slightly different from the previous one. I wouldn’t expect much of a change, but anyway, there will be some differences.
Finally, the rendering intents are there to cope with those out of gamut colors I didn’t want to talk about at the beginning. And they are important because, at the very least they are needed so you can properly see your wider gamut colors (from the working profile) within the narrower gamut of your display.
I have left out many topics and details here, but to process an image, maybe there’s not much more you need to know about. Well, it will depend on how accurate you wish your colors to be rendered 
Hope it helps.
“It would be great if there is a web page with the (more or less?) consensual things discussed here. There are zillions of pages about color management, rendering intents, etc, but few explaining carefully which is a recommended workflow for a photographer, specially a linux one.”
I think Glens link above is about as clear as you can lay it out. It seems its sometimes just harder to understand how all the software and hardware are playing ball together in this framework…
Also lots of great info and explanations found here It would be great if there is a web page with the (more or less?) consensual things discussed here. Overview of Color Management
Yes, I read that excellent page. Very nice analogy with peppers. 
Thanks for the extensive explanation, Xavier. The only thing that it is not clear is this:
In short: if you wish to be sure about Chrome rendering about the same colors as Firefox and RT, you better use a profile with a standard sRGB TRC («gamma curve»).
RT gives at least 4 sRGB output profiles:
- No profile (default to sRGB). This is discarded from everything just wrote.
- RTv2_sRGB
- RTv4_sRGB
- sRGB
Which one to use? Are you suggesting to use another one ?
I think this is the most common std…WIndows uses it by default i think if I remember correctly…
sRGB IEC 61966-2-1:1999
1 Like
In my naïve view, I think of histograms and colour pickers as measurement tools/devices.
I think normally I’d be interested in the following measurements:
- input or output of the currently selected module, in the respective colour space (normally, the working space, except for modules that perform colour space conversion; but I think normally one would ignore those, as it’s the processing modules we’re interested in). Input is, of course, always the output of some other module, so this can be simplified to output of modules only. This is like measuring the signal at some point between stages of an amplifier or whatever;
- output after the output colour space conversion (the data that will end up in my exported file, sans compression artefacts). That is like measuring the final signal (using a strictly resistive load - but I don’t know enough about electrical engineering, so I’ll stop).
Involving the display profile makes little sense. One rarely judges amplifiers by placing a microphone in front of the speakers. 
2 Likes
Use the RTv2_sRGB. Version 4 profiles are not yet widely recognized in viewers.
2 Likes
Sorry I didn’t explain it better. If you haven’t read the discussion I referred to, a color calibration device is needed (in my case an i1 Display Pro) to create a custom display profile.
If you don’t have one and don’t have any friend who can lend you one, then I guess (and it’s only a guess) that your best bet would be setting your display into sRGB mode, calibrate as best as you can your display (means playing with the buttons of your display to get decent contrast and brightness; there are online pages to do that), and set sRGB as your display profile system wide and/or your applications.
Then you would export images with sRGB as output profile.
Yes, that’s what I was trying to say.
But if you read the page on that link, you will see that it lists the specs, though you can’t download the profile itself. In their download page they offer you the 2014 v2 version of the profile, which I was shown some time ago to be a bit glitchy.
Using the appropriate button in RT (
) you can switch readings between working profile and output profile. Those readings are used to draw the histogram (either the working profile with a sRGB gamma curve applied, or the output profile with its own gamma), and to show pixel values in the area below the navigator window.
There’s nothing regarding the display profile there. But as you may understand, to actually render the image on screen, a display profile must be used, or the colors you see would have nothing to do with the real colors in the processing engine or in the output image.
So involving an accurate display profile makes all the sense, because without it you wouldn’t ever successfully edit an image, as you would not see the correct colors. «Aside from this», the display profile is not used in your image.
Think about judging your amplifiers with the light on (with a display profile), or in complete darkness (without display profile). The light is just an aid, but is absolutely needed.
1 Like
I was referring to darktable’s behaviour.
Honestly, that wasn’t clear, as this thread is about darktable, gimp and rawtherapee…
Yes, and primarily to see how it will look when output to a device/platform with a different gamut. But if your output profile is srgb, and you soft proof srgb, you will see no difference.
This is because what you see is limited by your monitor gamut. If your monitor can’t display more than srgb, then you will see no or only small difference between the two.
Sorry about that. I assumed that display profile being part of the chain from image to histogram would imply that I’m talking about darktable; but I should have been more explicit about that (there’s the famous catchphrase about assume making an ass of U and me). Sorry, @XavAL, for making you write an even longer explanation.
2 Likes
Indeed, got it.
Thanks to all for all the information!! I learned a lot from this thread, and my workflow is now better configured. 
3 Likes
I am having similar issue. I have calibrated my Dell display.
I always export for sRGB when publishing for the web. sRGB should look the same or at least very similar, but for me sRGB looks too much vivid. If I activate soft proof sRGB I will get darker shadows. That seems fine for me. But when I export to jpg with sRGB it is not close at all to the soft proof profile.
The only way for me to see what the exported picture will look like is to change display profile to sRGB.
Which one looks best below with the colours, if your display is able to show both AdobeRGB and sRGB?
Adobe RGB
sRGB
To what standard? It matters if you calibrate with sRGB as reference, or something else.
In any case, for a properly calibrated display, leave the display profile and preview display profile on ‘system display profile’ if you want accurate color representation.
It was my understanding that if you turn soft-proofing for sRGB on, and you are sure the sRGB profile is embedded in the exported file, and you view that file in a properly color managed application, it should look identical to the preview in darktable.