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 …
Hermann-Josef
On windows 10 the standard app should be “photos” app, don’t use it.
http://forum.luminous-landscape.com/index.php?PHPSESSID=qh8uosfeahrv0dahdqngk0iv67&topic=117152.20
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?
@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.
Hermann-Josef
hi,
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…
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.
Hermann-Josef
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.
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… 
.
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…
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
Hermann-Josef
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, Monitor profile, calibrate, system install
So, I think you need to make sure 1) RT has the display profile configured, and 2) use V2 profiles for output.
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.
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
Hermann-Josef
Excellent!
Moinchen, @Jossie!
You can be happy that you have an Eizo monitor
– they are usually very good!
MfG
Claes in Lund, Schweden
@Jossie I’m curious, and unrelated to this discussion, with my EIZO I had this strange problem that I found it difficult to get sharp eye focus. No problem focusing on the same image on an adjacent non-IPS screen. Do you experience the same issue?
@Claes Well, I won a bet with my wife and then I got permission to buy the Eizo 
@Morgan_Hardwood No, I do not have this problem, at least I am not aware of it. If I view the screen at proper angle through my glasses the image is sharp.
Hermann-Josef
To my experience, it’s one of those things that you read and read and read about, and come away feeling not much smarter. Then, you play with it a bit, and the relationships start to make themselves evident, and it’s really not that tough to comprenend. Then, you go and tell everyone what you understand, and they look at you “like a dog watching TV”… happy to be there, don’t understand a bit of it. And so the cycle goes…
Good evening Glenn,
I agree that it is a struggle. But there are a few books out there which helped me at least to see the underlying principle. The book by Fraser, Murphy and Bunting (2005) is really good explaining the principles. However, if it comes to the technical details, this is not the right place. I am still looking around to find a book at the intermediate level, i.e. not that technical as the ICC specification itself but more detailed than Fraser’s book.
Concerning the topic of this threat:
In SilverFast’s preferences for the colour management I have for input → internal and for internal → monitor the choice between “none” and “Image Color Matching (ICM)”. I had assumed that ICM is the system’s responsibility of transforming to and from the PCS and not the responsibility of each individual application. But this was just my guess, which does not hold in general, as I have learned.
Hermann-Josef
I’ve found @Elle’s articles to be the most help: Articles and tutorials on Color management. Still, I have to read them multiple times to get the drift. After that, messing with the settings and seeing what happens has been the most instructive thing. Then, I wrote my own software and use the LittleCMS library to do the heavy CMS lifting, which has been very instructive, but not what most people want to take on.
It all started to gel when I purchased the XRite ColorMunki Photographer kit, which includes the puck colorimeter as well as a 24-patch ColorChecker Passport. With these, I made profiles for my camera and displays, and now my desktop lcd looks the same as my Surface tablet lcd. That exercise for me really made the whole profile chain make sense.
To get technical requires math skills at which I’m quite rusty, matrix math and such. But the concepts the math supports now make sense, mostly from watching the tools behave with both nominal and non-nominal input.
For what it’s worth…
Good morning Glenn,
yes, @Elle 's webpage is very good. It is about the same level as the book by Fraser et al. I quoted. I already had some nice insights browsing through these webpages .
My interest in colour management started with the question to understand how red and green pixel can make a yellow colour. I had written image processing software for more than 30 years, albeit for astronomical images, which is quite different from the images we are now dealing with. A short introduction about how to implement colour management in Java can be found in the book by Burger and Burge (2016), which is a valuable resource for all sorts of algorithms. Unfortunately I only speak Fortran, perhaps I am too old for C++ or Java 
.
Best wishes
Hermann-Josef
My first language was CoBOL.
I kept technically current by teaching; the day job didn’t afford such. As a university department chair, I learned Java when my adjunct instructor quit the first day of class; I couldn’t find anyone else to teach the class, so I did it, and had to concurrently learn and teach Java, week-by-week.
I’ve only recently learned C/C++, first to translate a Java demo of a patent, and I’ve really cut my teeth on it with this image processing thing. @floessie schooled me on the ways of C++ in writing my image library.
Programming is what I’m using to keep my mind sharp, as I turn 60 next week. Color management has proved the most challenging aspect to master, but it’s a sweet victory…
And the very best to you,
Glenn Butcher