@RawConvert so I must conclude that in order for those differences to show, the eventual output profile needs to be very much smaller than the one worked in. Which still doesn’t quite make sense …since saving in sRGB _ is _ saving in a profile a lot smaller than ProPhoto which RawTherapee works in. 
Well very similar yes! but there was also discussion of printer profiles and screen profiles and I think (rightly or wrongly) that complicates things. I thought I’d try the absolute simplest case, sRGB output jpegs…
They are not out-of-gamut areas. They are areas where one or more of the channels are clipped. The level of grayness of the indicator shows how many channels are clipped. White = 3/3 clipped, light gray = 2/3 channels clipped, darker light gray 1/3 channels clipped. The indicators are affected by the “Use working/output profile for main histogram and navigator” setting "Use working/output profile for main histogram and navigator" affects more than that · Issue #4067 · Beep6581/RawTherapee · GitHub and only seem correct when that option is enabled.
Converting from the working profile to the output profile using perceptual rendering intent should prevent clipping and should look different than when using relative colorimetric if the profiles have the required conversion tables. Matrix profiles only support relative and absolute colorimetric intent mapping, while LUT profiles can support more. I don’t remember off the top of my head which profiles RT has.
Either this feature is broken, or the profiles are matrix, or the profiles are LUT and lack the table for conversion to perceptual.
An old adage goes, “When in doubt, @Elle”
https://ninedegreesbelow.com/photography/icc-profile-conversion-intents.html
As I already said in the other thread, and as @Morgan_Hardwood also stated, differences between relative colorimetric and perceptual intents will show up only if the output profile provides an appropriate gamut mapping table. Matrix profiles DON’T provide such tables, so choosing perceptual intent results in the CMS to fall back to relative colorimetric. I’m 99.9% sure that the sRGB profiles provided by RT are of matrix type…
The RawTherapee sRGB profile is a matrix profile.
In the article to which @Morgan_Hardwood linked in the previous post, I tried my very best to explain in as few words as possible 
why perceptual intent doesn’t work with matrix profiles. If anyone reads the article and has any questions, I’d be happy to try to answer.
In the meantime, here’s an article that shows an example of what “clipping” looks like when a very colorful ProPhotoRGB image is converted to sRGB:
This pixls.us post/thread might be helpful:
Correct, only for printer soft-proofing.
Ok, so is it appropriate to raise some feature requests / enhancements? If so, I’m happy to create some. My suggestions would be -
- RT should be able to show the user what out-of-gamut parts of the image are present in respect of the conversion from working profile to output profile, providing this profile is sufficiently complete e.g. has perceptual intent data. (The conversion from camera input space to working profile might also be relevant but I don’t feel qualified to propose anything on that).
- RTs main output profiles, e.g. the sRGB and adobeRGB equivalents, should be enhanced to include all the data needed to support standard colour management and processing.
- RT should not allow the user to specify rendering intent or black point use in the Color Management tool if the output profile chosen does not support rendering. In this case it should show Relative Colorimetric with Black Point Compensation? but with these greyed out. (What about the gamma items?)
Do these seem reasonable?
and so on. Thanks, that’s good to know. I tried the “use working/output profile…” setting and can see it makes a difference.
Colour management is a difficult subject to get to grips with in some ways. One way of looking at it which might help is that it’s a mechanism that allows conversion between different colour spaces and intents.
One package all people tend to have now that is colour managed is a browser. If an image is loaded it will convert to sRGB providing there is a profile in it. It will use that profile to determine what to do. No profile then it assumes sRGB. It does that because of the millions of older photo’s on the web that don’t have a profile. There may be some new ones too. A web search can bring up pages of the same shot using the usual profiles sRGB, aRGB and Prophoto. They will all look the same if things are colour managed. The reason for that is pretty simple - no one in their right mind would produce a shot intended for the web that needed heavier saturation than sRGB can provide. There are some colours in say aRGB that are not reproduced that well but a casual viewer probably wouldn’t notice. I’m thinking of a teal colour in particular. Many monitors will be way out anyway.
RT uses a workspace ProPhoto colour space. The reason for that is that it has a greater bit depth so as tones and colours etc are shifted about they can be restored. If it was using sRGB and some one made a 1/2bit change it’s gone due to rounding errors so can’t be bought back.
On the other hand an sRGB images can be edited far more than many people suspect even in an sRGB colour space. There just isn’t so much scope. If people use the GIMP and look at histograms they will see gaps in them. Done properly this wont be visible when the shot is viewed. Push to far, make more and more re-corrections and it will be. The idea with the GIMP from raw was that ufraw would be used to produce a shot that the GIMP could edit further.
RT can set an output profile. I’ll assume that this could be any of the ones that are available. Say someone chose aRGB and also had an aRGB monitor. They wouldn’t normally adjust the view to the same level of saturation as they would for a print. The print needs it because it’s using reflected light which isn’t as “efficient” as a monitor. I’m not going to bother urinating into the wind on the subject of wider colour spaces - aRGB and sRGB. This link and one off it is a pretty extreme view but accurate if commercial printers are used or as I have found home sRGB printers.
http://www.kenrockwell.com/tech/color-management/is-for-wimps.htm
RT only shows out of gamut colours when proofing prints. The best way I can explain how this is used came from some one who does use prophoto printers. Poor name really. They just have larger than normal printer gamuts. The saturation is simply nudged. Otherwise the print will look awful when it’s actually printed. This will have been on a set up for fully handling 10bit aRGB. The same would apply to proofing aRGB on an sRGB set up. A profile for the paper that it will be printed on will also be needed to cause the monitor to display correctly. It’s a process that needs some hands on experience.
People are also inclined to forget that all use mixes of rgb and have different colour step sizes and in essence some offer higher saturation levels than others.
When I can set an intent if I can I use absolute colormetric as I was advised to.
John
Except if you use Chrome/Chromium, which is most people.
I couldn’t manage to read the whole thing, it was just too wrong.
In fact, you can show out-of-gamut colors even if there is no perceptual intent table in the colorspace. Even more, the out-of-gamut warning will be more accurate when using relative colorimetric.
The way out-of-gamut warning is usually implemented (at least in LCMS and in my own image editor, for RT I’m not 100% sure) is to make a round-trip ICC conversion of the type working_ICC → output_ICC → working_ICC, and compare the initial and final image data. If there are differences, it means that some channels have been clipped in the first conversion, i.e. some pixels are outside of the output colorspace gamut.
If you use a perceptual intent in the first conversion, colors near the gamut boundary (but still inside the gamut) will be slightly distorted, and will give differences in the comparison which are somehow uncorrect - think of this as “false positives”.
If RT is providing, as I expect, well-behaved matrix profiles for output, there is nothing one can add to make them “support standard colour management and processing”. They already do, and perceptual intent is simply not foreseen for matrix profiles in the CM. On the other hand, matrix profiles provide the most accurate conversion between one colorspace and another, because the conversion is based on matrix multiplications and not on LUT interpolations (whose precision for example depends on the number of points in the 3D LUT).
This is a valid request, although black point compensation is not as issue and is supported for all profiles, so there is no reason for including it here. Standard matrix profiles usually have a black level at (0,0,0), so no black point compensation is needed when going for example from ProPhoto to sRGB.
Agreed, that’s simply crap 
I guess that a color-managed browser will convert the image to your display profile, using what is set in the system-wide preferences. It might correspond to sRGB if your monitor is not calibrated…
Here you are confusing bit depth and gamut. Those are two separate things: you can edit an image at 32-bit floating point precision, or a ProPhoto image at 8-bit precision.
If the processing is done in floating point precision, as RT and most of the modern editors do nowadays, you can probably apply the same conversion back and forth a million of times without any noticeable degradation. What you are referring to are issues which were valid when processing images at 8-bit or 16-bit integer precision. By the way, in such cases going to a wider colorspace usually makes things worse, and that’s why sRGB has been invented in an era when floating-point processing was still too heavy resource-wise.
Again, what you describe is a limitation of the bit-depth of the image, not the colorspace. Your example is probably referring to the editing of a Jpeg image, which provides even less than 8-bits per channel.
If you start from a RAW file and do the processing in floating-point precision, you will hardly ever see gaps in the histogram.
The absolute colorimetric intent is a very special case, and is useful in rare occasions. It skips the chromatic adaptation in the conversion from one colorspace to another, and is likely to provide shifted colors. Don’t use it unless you really know what you are doing…
Most web browsers are not color-managed.
No such thing.
No one, except for the growing number of people with OLED smartphones who can actually view DCI-P3, Adobe RGB and other gamuts bigger than sRGB.
Colorspaces don’t have bit depths, and RawTherapee has a floating-point engine, IIRC as does LCMS2.
It’s the job of color management to make sure that the printed image matches the on-screen image, it’s not the user who is supposed to “adjust the view to the same level of saturation”.
That might explain why your photos above have a green tint where white should be. Absolute colorimetric is used for matching paper whiteness to screen, don’t use it as your monitor profile’s rendering intent.
That’s a really nice and concise definition!
Looks like if some one asks about a complicated subject there is no point trying to explain it especially if people choose to be pedantic about what was intended to be a rough outline.
The best answer is for such people to explain it all themselves.
John
The devil is in the details!
1 Like
Thanks for these comments. I’d like to modify my 3 suggestions to get them sensible, hopefully with concensus, then developers might decide if they want to implement them. However I’m a bit confused about what you say.
I see the neat trick for identifying conversion differences, and then when you said “If you use a perceptual intent in the first conversion…” I thought things were going well. You also said “…if the output profile provides an appropriate gamut mapping table”, so I thought this was extra data that could be bolted on to the profile, as I had imagined.
But then further on it seemed a Perceptual conversion was not possible – you said “perceptual intent is simply not foreseen for matrix profiles” and “there is nothing one can add [to the profile?]”
So I’m left wondering how could Perceptual conversion be achieved. Is it a matter of programming a calculation process which will work with current profiles, or do the profiles also need changing, or what?! I don’t think I can move forward on this until I understand if/how Perceptual could be implemented. For example, though you say item 3 is a valid request, I’m thinking that if Perceptual “just” requires a new calculation process, and it can be done with any output profile, then item 3 would be irrelevant!
I must learn not to dabble in these discussions! 