Preview in RT more saturated than in output image

(Morgan Hardwood) #21


Verified how?

Please don’t call it aRGB. It’s AdobeRGB.

The monitor profile has no effect on the saved image.

If you mean that the pixel values are identical, then that is correct. They should be identical if the only difference between the files is the assigned profile.

Correct. The monitor profile has nothing to do with the saved image.

As it should.

As they should.

No. See “What colord does” as an example,

(Alberto) #22

If you are on Linux, this could also be helpful to clarify things:

(Hermann-Josef) #23

Thanks to Morgan and to Alberto for their feedback.

Okay, I just used the short version for AdobeRGB(1998) and promise not to use this again :slight_smile: .

I had used EXIFtool (and its GUI) to verify that all PhotoShop relevant tags were gone.

The monitor profile has no effect on the saved image.

So here is my great puzzle: What is the purpose of the monitor profile affecting the colours in the RT preview but not the output image? I always had thought that the preview should be identical to the output image otherwise I would be flying in the dark.

See “What colord does”

I had a look at this link but I must admit that I do not see what this has to do with the monitor profile affecting only the preview and not the output image.

@Alberto: I am working on Windows10 and try to understand colour management :slight_smile:


(Alberto) #24

The purpose of the monitor profile, together with the input profile, is – roughly speaking (forgive me if I’m a bit fuzzy here… someone else might chime in and make this much more precise, e.g. @Elle?) – to tell RT how to interpret the R,G,B values that consitute each pixel in the image and to translate them to instructions for the video card and/or monitor firmware so that they in turn become the expected colours that you see on the screen.
Without a monitor profile, you are not seeing what is intended, but rather some kind of approximation of it. The “accuracy” of this approximation might range from reasonably close to very far off, depending on the input space of the image and the settings of the monitor.


Good to know :slight_smile: , open a picture with embedded color profile with “windows photo viewer”.
Is what you see the same as the PSE preview ?
Is different from the Rawtherapee preview?

(Hermann-Josef) #26

Good evening Alberto,

what you describe is the functionality of the output profile. This should be automatically been applied by the operating system when an image is sent to the monitor. The pixel values in the image I am discussing are already in the AdobeRGB(1998) colour space and my monitor is calibrated in this colour space. So everything should be consistent. However, the preview in RT only matches the output image if I set the monitor profile in RT correctly.


(Elle Stone) #27

Hi @agriggio - monitor profiles themselves are blissfully unaware of whatever curves might or might not have been loaded into the video card - the curves are part of calibrating the display. The monitor profile might also contain a tag with tthe video card curves to be loaded, but that’s for convenience - ICC profile color-managed software doesn’t use this tag, even if it’s present.

Calibrating the display can mean either loading corrective curves into the video card, or making changes to the monitor itself using whatever controls the monitor provides, or both ( Once the monitor is calibrated, then you make the monitor profile (not the other way around).

The color management system used by an ICC profile color-managed software then converts the image RGB values from the image’s assigned ICC profile to the monitor’s assigned ICC profile. These converted RGB values are the values that are sent to the graphics card, that in turn sends signals to the monitor (leaving to one side all the other layers of software involved in displaying images on a monitor screen).

As a complete aside, I’ve never thought about monitor firmware - whatever you do to the monitor controls does affect the monitor hardware, and for older monitors very directly. I don’t know anything at all about the role of firmware vs hardware for calibrating modern monitors.

If “PSE” is PhotoShop Elements, and if PhotoShop Elements works the same way as PhotoShop from CS2 (the only version of PhotoShop that I’ve ever used), then there really is no way to assign a monitor profile because PhotoShop uses the system monitor profile.

In Windows, it used to be the case that you could assign a system monitor profile by right-clicking on the Windows desktop and bringing up a GUI with settings pertaining to the monitor. But PhotoShop didn’t “pick up” changes to the system monitor profile until PhotoShop was restarted.

Sadly this lack of direct user control over choosing a monitor profile from within the imaging software has infested, er, rather, been coded into certain free/libre softwares, for example digiKam.

If anyone really does want to understand the interaction between monitors, monitor profiles, and ICC profile color-managed image editors, here is a little “experiment kit” that I put together:

Color Management Experiment Kit: If seeing is believing, how much does your monitor profile matter?

It’s worth spending some time getting a good understanding of what monitor profiles can and can’t accomplish. Yes, a properly calibrated and profiled monitor will show you reasonably accurate colors, but only within the actual color gamut of the monitor profile. So it’s also worthwhile spending some time “soft proofing” from the image profile to your monitor profile, by choosing the monitor profile as the output/soft proofing profile. PhotoShop used to let you do this, probably still does, but I don’t know about PS Elements. GIMP and PhotoFlow let you do this, I’m not sure about RT.

The kinds of questions that you want to experiment a bit to learn while using the monitor profile as the soft proofing profile are things like “If I’m editing in the ProPhotoRGB color space, what’s the reddest ProPhotoRGB red that my monitor can display?”

PhotoFlow raw processor has code that does an excellent job of working around various limitations in LCMS soft proofing algorithms. I’m not sure whether any other color-managed software that uses LCMS has incorporated any of the PhotoFlow code. If all your images are in more or less perceptually uniform color spaces (as for example regular AdobeRGB1998 or regular sRGB), and if you aren’t working at floating point with unbounded channel values, then most software that provides for soft proofing will work just fine.

(Hermann-Josef) #28

Good evening age,

open a picture with embedded color profile with “windows photo viewer”.

Using the standard photo viewer in Windows10 the image with ICC-profile does look different to what I see in PSE. It looks identical to the preview in RT only, if I chose as monitor profile “no profile”. However, the output file from RT with monitor profile set to AdobeRGB looks identical to the RT preview only if the monitor profile is set to AdobeRGB(1998).

Pretty confusing …



On windows 10 the standard app should be “photos” app, don’t use it.

Windows photo viewer is this

One more question sorry,
Is the preview in RT and PSE the same when you set system default in RT monitor profile?

(Hermann-Josef) #30

@age Thank you for clarifying the issue with the Windows viewer. I will have to find out how to get the colour managed viewer in Windows10. Google should know …

Is the preview in RT and PSE the same when you set system default in RT monitor profile?

Yes, for the eye it looks identical.


(Alberto) #31


hmmm, I think this is the source of the confusion. “output” refers to what RT generates, i.e. the output profile is the profile assigned to the resulting jpeg. but when you view said jpeg, then the rgb values of the image need to be translated to colours that your monitor can display. again roughly speaking (and thanks! @Elle for contributing!) this is done by first looking at the image profile to understand what these rgb values are supposed to mean, and then converting them to the closest colours the monitor can render using the monitor profile. it’s like translating from German to Italian when you only have a German/English interpreter and an English/Italian interpreter: you go from German to English with the image profile, and from English to Italian with the monitor profile. I know the analogy is not perfect but I hope it could still be helpful…

(Hermann-Josef) #32

Good evening Alberto,

yes, I fully agree. That is the standard procedure of colour management, going form the input profile via the PCS to the output profile (i.e. the monitor profile).

But my question is, why is the output profile being used in RT and influences the preview image, but not the output image? This is what I do not understand.


(Morgan Hardwood) #33

Another analogy, if the image editing workflow is an NPN transistor, then the collector is the working profile, the base current is the adjustments you make via an unmarked potentiometer, the emitter uses the output profile, and the monitor profile is a multimeter between the base and emitter showing you exactly what’s going on.

(Glenn Butcher) #34

Having just worked through my initial color management migraine, here’s a generic explanation that might help you put whatever RT is doing, in context.

Fundamental concept: ICC-based color management requires from the start for the image to have an associated color profile that is used to transform the image at various places for working, display, and output (well, display is really a form of output…). This transformation is simplistically thought of as, e.g., working->output, but is really working->CIEXYZ->output. Profiles thusly don’t have to know about each other, they just know how to get back and forth from/to CIEXYZ, the “mother profile” you can read about elsewhere.

So, your question relates to the difference between ‘display’ and ‘output’. I’ll assume you’ve been munging your image in whatever software using a decent working profile. You probably know that displaying your image with that profile ‘straight to the lcd’ looks bad, because your display’s colorspace is woefully inadequate to display the internal richness of the working image. So, prior to pushing the pixels to the lcd, your software transforms the working image to a display image using the calibrated display profile. Looks nice.

Now, you want to save your image for passing to friends and family, but you don’t know jack about their displays. So, you save/export your working image to a JPEG, because you know most folks can look at those, and you transform the working image to a ‘least-common-denominator’ output colorspace, e.g., sRGB. Really, if everyone in the whole world were using color-managed software that displayed 16-bit TIFF or PNG you wouldn’t have to do this transform, you could just save the working image with it’s working profile and your cousin’s software would do the working->CIEXYZ->display transform. But alas, we’re not there yet, maybe when we have self-driving cars we’ll have universal color management… :smile: .

sRGB actually does something else important besides following the image around with a corresponding color profile; transforming to the limited sRGB colorspace makes the image ‘default-displayable’ in non-color-managed softwares, (hopefully) approximating the colors you want folk to see. Even among color-managed viewers, not all is equivalent; some only completely recognize V2 ICC profiles and ignore V4 profiles or worse. You can see this with the old Windows Photos Viewer (not the Photos app) - save your working image to JPEG with a V4 sRGB profile, and this viewer shows it different than your RT display. Save it with the V2 sRGB profile, and now it looks the same. Download @Elle’s profiles and you can easily demonstrate this.

@Jossie, you probably know a lot of the above, so I apologize if the above re-treads your understanding. But it seemed your question relates to the difference in handling internal display vs export to a file, so I thought I’d walk those two paths in a single post. Sometimes, methinks the dialogue in forum posts doesn’t fully connect the dots (well, that might be my old-age dementia…)

Speculating, I think you might be experiencing the V2/V4 thing…

(Hermann-Josef) #35

Good evening Glenn,

thank you very much for your detailed explanation.

I think I have a some basic understanding of colour management: device dependent colour space (camera, scanner) gets mapped into the PCS and then into the (again) device dependent output space (e.g. the monitor). However, as fas as I understand, the latter process is automatically taken care of by the operating system and the CMM. Thus my question, why I do have to specify the monitor profile in RT with the possibility of making a mistake and having a preview different from the output image.

This afternoon I contacted Eizo since I had the feeling I might have done something wrong profiling my monitor. Among their feedback was the following statement: “The monitor profile need not be specified in any software. It is located always at the same path in the operating system and the software detects it automatically”. This contradicts the remark by Morgan in this threat above:

make sure that both programs use the same monitor profile (set it manually, don’t rely on auto-detection as that introduces a point of failure).

So obviously this is an open issue and at least I now understand how to set up RT to have the preview appear in the same colours as the output image.

Best wishes


(Glenn Butcher) #36

I wouldn’t make that assumption. In rawproc, my raw processing hack software, I have a property, display.cms.displayprofile, that points to my DispCal-produced display profile. Even if rawproc queried the _ICC_PROFILE atom (Linux), it’d still have to do the transform. AFAIK, any operating system’s color management delivers the registered profile for each display to the querying application, and the application does the colorspace transform before drawing the image.

Now, the thing I can’t do as an application is load and apply the video card LUTs, which are apparently in the calibrated display profile, and a thing I don’t yet understand. Time to re-read @Elle’s article,

So, I think you need to make sure 1) RT has the display profile configured, and 2) use V2 profiles for output.

(Morgan Hardwood) #37

As we’re talking about saving images for typical use and not soft-proofing, “into the device-independent output space” (sRGB, AdobeRGB, etc.). The monitor profile is usually not the output space. The monitor profile is there to make the colors you see on screen match the colors you’re actually working with as closely as your monitor allows you to.

As we’ve covered already, converting colorspaces is not the color management service’s job. The color management service is the waiter not the chef. It’s there so serve you the right profile and to say “Excellent choice, Sir”. Unfortunately, they often end up sitting on your plate.

Sounds like a standard macOS/Adobe reply. Even if it was true for all software it would still be wrong, as there are very valid reasons for using a monitor profile other than the system-wide one.

Auto-detection is not an issue - my remark was strictly within the scope of testing, where eliminating all uncertainties is paramount. RawTherapee auto-detects the monitor profile. It does so correctly. It also gives the user the freedom to use a different monitor profile than the auto-detected one.

(Hermann-Josef) #38

Thanks to @Morgan_Hardwood and @ggbutcher for the clarification. Obviously I had the wrong procedure in mind as concerns the application of the monitor profile. I will have to learn more about colour management in depth, I am afraid, to understand this topic better. For the time being I will set the monitor profile in RT to the Eizo profile as this gives the correct colours in the preview – correct meaning for me the same as the output image, which is in AdobeRGB.

Best wishes


(Morgan Hardwood) #39



Moinchen, @Jossie!

You can be happy that you have an Eizo monitor
– they are usually very good!

Claes in Lund, Schweden