I’m answering here a question raised in another thread which was out of topic there:
Short answer: Not too much. 
You could choose a large working profile like ProPhoto, use some software with a 32-bit floating point rendering engine (RT, dt, …), set the Relative Colorimetric rendering intent, and be gentle while editing your images. Most probably you will get what you need without worrying about OOG colors.
(Really) long answer:
Let’s start by acknowledging I’m just a plain user, and I’m reaching my grey zones, where I think I know the answers, but I can be wrong.
A lot has been said about color management even in this very forum, but I don’t think it would be bad to explain it again, from a different perspective: what a user expects, and what the user gets from software.
Let’s start by saying that working with digital colors is just working with numbers, no more, no less. Numbers doesn’t have limits, unless you tag them (real numbers, decimal numbers, negative numbers, …), so a user would expect that multiplying color values by a ridiculous number will just throw another color. Maths allow this, but sadly the truth is that you won’t get what you expect.
The main reason of all the color management problem is that we (users) wish to easily get what we think is a straightforward transformation. Far from the hard truth: our eyes-brain system performs complex psychophysical transformations that help us relate with the world we are living in, making changes in the real data our eyes get, so we have the information we need. That is, e.g. we have higher sensitivity to lightness than colors, so we can still see at dusk. And we have higher sensitivity to yellow greenish color (although I really don’t know why).
Among that, we can only see a certain range of colors, no further than violet (ultraviolets), no below red (infrareds), and scientists have plotted the colors we see into a 2D graph to ease the comprehension of color theory and the transformation of real colors with maths: the CIE xy chromaticity diagram (as you can guess, this quick explanation is really much more scientifically complex).
So we have a chart where colors are located with 2 values (x and y), and we have maths: where’s the problem, then? The problem is that to our eyes sometimes 2+2 is not 4, so the algorithms have to cope with that. The problem is now a bit more complex.
Is that all? Well, no. Now we start dealing with devices: sensors, displays and printers.
In an ideal world camera sensors would react to light exactly as our eyes-brain complex does. Far from truth: the different photosites aren’t sensitive to the same range of colors as our retina cells, and with the same intensity to lightness. And the sensor captures light in a linear fashion, while the eye-brain transforms the captured light into a short of gamma curve, mainly to enhance shadows without loosing much information from highlights.
And what our eyes really do is scanning small areas our visual field and sending the partial snapshots to our brain, which join them altogether in a short of HDR image. So coupling these behaviors to devices is really complicated.
Now, we have camera sensors that are able to capture a certain range of colors, usually represented in a CIE diagram as a triangle. Then we have displays that have to show images so we can see them, and they are also able to show only a certain range or colors (another triangle, or gamut). Finally, when we are happy with our images we want to print them in a device that inherently has a very different gamut that those of sensors and displays.
(image taken form EIZO website)
With modern cameras, we can capture a range of colors that exceed the gamut of even the best displays, but only in certain color areas, while lacking sensitivity in other areas (e.g.: a sensor may be more sensitive in blues, or oranges, while not being able to capture some of the highly saturated greens). On the other hand, with printers we will be able to get much more saturated cyans and magentas than on displays, because those are primary colors for printers, but saturated greens will be a problem.
Ideally we would use a working profile (a color space) that is much bigger than any sensor, display or printer gamut. Even one that holds the entire range of colors our eyes can see (ACESp0). But then we face the problem of the conversion between profiles and the fidelity of colors after each transformation: maths again. There’s a problem called quantization error, which generally speaking means that when converting one value in one range into another range, the resulting value is not equivalent to the starting value. In other words: when converting one color from sensor profile to working profile, the resulting color is not the same (to our eyes). When you convert it to the output profile, it’s again not the same.
The problem comes from the way primary colors are encoded within profiles (with hexadecimal values): the bigger color spaces (and profiles) hold much more colors than smaller spaces (sRGB is the most common), so when you convert a color from a bigger color space to the smaller one, there’s a chance that the resulting color will have a shift in its hue. Some say that’s not a problem with modern raw developers, because they work with 32-bit floating point numbers. That means to a plain user we have infinite decimals, so infinite values, but sadly that’s not true. It really means a lot more numbers than 32-bit integer numbers, but not what we would expect from real decimal numbers: there’s a limit in the possible values in 32-bit floating point numbers.
Anyway, in our images, as amateurs, all of this means that current raw processing software is absolutely capable of making us forget quantization errors, but if you are seeking the absolutely perfect precission of colors, you have to thread with care. And I’m not ready (I have no idea) to tell you how to get what you need, so you’re on your own.
For the rest of us, we have awesome raw processors, so we just choose a big color space and we’re done. Aren’t we? Not really. There’s yet the problem of colors that fall outside the gamut of the chosen color space. You may say that’s not possible at all, but it is, indeed: if for example you process an image as if you want to get from a disposable camera the quality you get from a professional one, well, you will be pushing values (and colors) a bit too much. In the end, remember that it’s all about maths, and you may end up with math operations that push a value outside the allowed range of colors. And here is when you take into account if your processor clips colors or not. Clipping colors means that when a certain operation throws a value outside the allowed limits, it just gets the maximum allowed value, no matter which was it’s calculated value.
The problem is: if you afterwards perform another aperation that brings back that exceeding value into range, if you didn’t clip it you will get the proper color. If on the other hand you clipped the value, when you bring back that value, the resulting color will not be the one you expected.
Example: you have a pixel with the RGB color (100,200,240), in a range that doesn’t allow values over 255. You push that pixel into (127,225,266), and the raw processor clips it, so as a result you get (127,225,255). If you further down in the pipeline of your software push back that pixel, on the unclipped scenario you would get (112,211,251), while with the clipped scenario you will end up with (112,211,240). A noticeable different hue.
Finally, if you’re not seeking precisely perfect colors, there’s a feature that comes to our rescue (at last!): the Relative Colorimetric rendering intent. Whenever there are colors that fall outside of the color space (Out Of Gamut colors), it makes a proportional transformation of the clipped colors and those that are near clipping, so they all can be seen without full saturation. The resulting color gradients will not be faithful to the original colors (will have a little shift), but luckily our eyes are not so sensitive to really saturated colors differences than we are to pastel tones.
So, summing up: unless you are facing a really demanding task, with color precission being a must, you will be fine with:
- a large working color space (ACES, ProPhoto, even REC2020)
- processing your images in a reasonable way (not crazy settings)
- always using Relative Colorimetric rendering intent. If you ever find some odd colors while editing, you may check the out of gamut colors with the appropriate button, and perform the appropriate editing changes to put everything where it belongs
I have more questions
Thanks!
), what you will see is the raw values with a little bit of processing (just a bit so it makes sense). And no matter what you do afterwards with the image, you won’t see any change in the histogram. So the raw histogram is good to know what you’re dealing with at the start of the processing, but little more. You will know if your image has clipped channels in the raw data itself, and maybe if the image is too underexposed. I use it mainly to know how clipped is the raw image.
) or the values the image would have if you exported it with the output profile.
), more or less… Again, you will get a feeling about how it will look, but it won’t be exactly the same as a real print.
