Hello, recently I noticed Rawtherapee uses relative colorimetric as its default rendering intent. I am not well versed in all the nuances with color science but generally it is recommend the use of perceptual rendering unless the photo contains a specific color that cannot shift such as spot colors. There are other cases when RC would be of use but as a default it seems like a strange choice. I was curious to see what Darktable uses and they have perceptual as the default.
Iâve found this to be particularly helpful, if only in the context of ICC profiles:
1 Like
Perceptual isnât all that itâs cracked up to be when it comes to ICC profiles. The nature of the profiles (where source and destination profiles are mixed and matched but subjective transforms such as perceptual are baked into each half) makes true perceptual mappings from a source to destination colorspace problematic. The actual result tends to be a fudge, with the possible exception of a perceptual transform created for a specific source & destination combo.
And putting this aspect aside, thereâs the whole question of whether such a subjective transform is an appropriate default for a tool that is meant to put the user in control of such adjustments. Relative Colorimetric is objective and therefore a more neutral base on which the user can make judgements about how out of gamut or under-utilized gamut colors should be handled. Automatically created perceptual intent transforms are a practical way of dealing with conversions to color spaces that the image creator hasnât anticipated.
3 Likes
Re: darktable. In the manual, it says
A selection box in the export selected module, the output color profile module, and soft proof gives you a choice of the following rendering intents
However, I donât see where one can choose the rendering intent in 3.4. Perhaps, it is because I am using Windows or donât have LittleCMS2 properly set up.
It is present in the export module. As usual, the tool tip is instructive.
For the record, Adobe products default to relative colorimetric. My impression is that perceptual moves too many colours around in order to increase the colour count and would therefore make colours inaccurate.
Thanks everyone for the clarifications. I see why relative colorimetric is the default in RT.
Blockquote
However, I donât see where one can choose the rendering intent in 3.4. Perhaps, it is because I am using Windows or donât have LittleCMS2 properly set up.
I was curious and did some testing. On 3.4.0 I had to enable LittleCMS in the settings. On doing so perceptual was the default in softproofing and under the output color module.
Since under export the default is set to âimage settingâ I am not sure what is used when LittleCMS is disabled as the settings in the editing panel are hidden though I guess perceptual is the default when it is enabled.
Itâs simple.
RelCol only changes colours that wonât âfitâ in the destination colour space, and those that will are left unchanged.
Perceptual changes ALL the colours by squashing and squeezing so that all colours fit the destination space and the relationship between all the colours is kept âperceptuallyâ the same.
In BOTH cases, colours that are changed are simply replaced with colours that WILL fit in the destination space.
The deltaE changes made by RelCol are invariably imperceptible to the human eye.
BUT, when printing an image with a narrow colour palette but large graduations within that palette, PERCEPTUAL can sometimes produce a very noticeable âtint shiftâ in the print.
It also depends on the paper you are printing on to.
But within the âdigital onlyâ image pipeline - eg JPEG production or TIFF archiving, using anything other than RelCol is a mistake.
6 Likes
If one is being careful and makes sure that colours do not go out of gamut then it wouldnât matter which you choose. The problem with perceptual is that you have no way of controlling what happens to the in gamut colours and the relationships when they are rerendered in the output space. They may look the same as they do in RawTherapee when opened in another program on your system or on somebody elseâs system, but they probably will not.
But isnât the problem also, that most users use sRGB or AdobeRGB, which as matrix profiles, do not allow the perceptual intent (being internally transferred to relative colorimetric anyhow)?
Hermann-Josef
Ah, scratches at a question Iâve long had, havenât yet taken the time to positâŚ
A ICC colorspace transform has two steps: 1) input â XYZ, then 2) XYZ â output. The matrices or LUTs in the respective profiles are about how to get their colorspace to/from XYZ, so they donât have to know about each other specifically. If the input profile uses a LUT to go input->XYZ, and the output profile uses a matrix, which one constrains the rendering intent?
In LittleCMS, a transform is defined with this call:
cmsHTRANSFORM cmsCreateTransform(cmsHPROFILE Input,
cmsUInt32Number InputFormat,
cmsHPROFILE Output,
cmsUInt32Number OutputFormat,
cmsUInt32Number Intent,
cmsUInt32Number dwFlags);
The fifth parameter, Intent, is passed one of the following:
ICC Intents:
INTENT_PERCEPTUAL 0
INTENT_RELATIVE_COLORIMETRIC 1
INTENT_SATURATION 2
INTENT_ABSOLUTE_COLORIMETRIC 3
(there are other enumerations, but theyâd just confuse the questionâŚ)
I donât think this is LittleCMS-specific, as we discuss the intent of a color transform as a singular thing, but it seems to me itâs a function of the profile with the least-capable information, no?
In such scenarios they are source profiles. So yes, they canât participate in an ICCV4 - PRMG style split source/destination gamut mapping, but nothing stops someone using an ArgyllCMS style perceptual mapping coded into the destination (i.e. display) profile.
No. The intent is requested of both source and destination profile transformations. If a profile doesnât support a particular intent, it defaults to what it does support. So if you request âperceptualâ of a matrix source and a cLUT destination with a perceptual table, then youâll get a relative colorimetric A2B conversion using the source profile and a perceptual B2A conversion using the destination profile. Tying the intent selection together for an overall transformation is an arbitrary decision typically aimed at not confusing users by asking them to understand whatâs going on. In the ArgyllCMS equivalent you get to choose the source intent and the destination intent independently.
Note that this is selecting the mechanisms used in the conversions, it doesnât guarantee the actual result matches any of the labeling! This is due to both the fact illustrated above that a particular profile may not handle all the different intents differently (as a matrix profile has to do and a cLUT profile might do), but also the fact that to truly implement an overall intent the two profiles have to work together in co-ordinated tandem, something that isnât likely given two arbitrary profiles. Getting a genuine perceptual transform out of a pair of ICC profiles is not very likely unless you have specifically setup the pair to do so.
2 Likes
Yes, that is my understanding too.
Thatâs not strictly true.
MOST people around the world use Lightroom, and as such, are committed to a ProPhoto workflow. Lightroom only works in ProPhoto in the background and MelissaRGB in the front UI.
As far as Iâm concerned, the AdobeRGB1998 space should be scrapped - itâs old hat now, and is simply out of step with current industry standards for archival purposes.
Couple that with the fact that most decent monitors can display MORE than AdobeRGB1998:
My monitor gamut(wireframe) is considerably larger than ARGB.
Archiving images in ProPhotoRGB:
Is industry standard practice
Preserves the greatest number of captured colours
Gives the very best control of contrast post raw - giving greatest flexibility in contrast adjustments and rendering intents for a print job.
Other archival spaces such as BetaRGB etc add benefit over ProPhoto when you are processing for Lumachrome printing, but in the general scheme of things, where people are printing to a more standard type of print media, ProPhoto does the best overall job of maximising captured colour preservation and transferring this to paper via a 16 bit print pipeline - in either RelCol or Percep rendering intents.
After 40 years in this business Iâve learned a thing or two, and one of them is that colour management is really simple - as long as you allow it to be so.
Theorizing, arguing the proverbial, and creating alternative methodologies are all well and good, but all they do is serve to muddy the waters and over complicate something which is essentially very simple.
And anyone who prints from an 8bit jpeg is crazy - they are only utilising a fraction of the available print colour space.
Partial rant over 
6 Likes
This thread was an interesting read. It was great to read descriptions about how the different rendering intents work from the perspectives of people who understand the math!
I used to work in the print industry running production copiers, large format inkjets, and large format black and white printers. These days I run a print production lab for the design department of a state college.
In the print industry, Relative Colorometric is regarded as the correct choice unless you really know what you are doing and have a very specific reason for using a different rendering intent.
Man, do I ever agree with this!
1 Like