Color Managed Monitor II

OK, let’s carry on our adventures in the wonderful land of color management on Linux. We were talking about the monitor part of the CMS and we saw how to produce a ICC profile and load it in the video card. Today will be a lot easier with more screenshots: how to use it full steam in a color aware application.

We said earlier that Cinepaint is currently the best choice for serious photographic works. So we will see how to do color management with this software, also the same principles are available in The Gimp and others. Once you have an ICC profile for your screen and you have loaded it in the graphic card, you are ready to fire a color aware application and enjoy “true” colors – let’s say, “as close to the truth as possible” colors.

The first thing you want to do is tell Cinepaint which profiles to use and what to do with them. You do that in the preferences, as in the below screenshot, which is also a chance for you to see Cinepaint in all its (GTK2) glory:

Cinepaint CMS Preferences

You first go in the Folders tab and under color management, you make sure that the folder containing your monitor ICC profile is there. By the way, the consensus (as far as I know) is to put systemwide ICC profiles in /usr/share/color/icc and your own ICC profiles in ~/.color/icc. That is where Cinepaint looks for profiles by default.

Now if you move to the Color Management tab, you can now configure how Cinepaint will deal with ICC Profiles:

  • You first tick Colormanage new display By Default to tell Cinepaint to go ahead and use CM.
  • The Assumed Image Profile is the profile which Cinepaint will use by default with the images it opens. It should match the profile you chose in your camera – basically AdobeRGB (maybe sRGB).
  • The Editing Profile is the profile which is used as standard profile for the image color transformations. AdobeRGB is a safe choice once again (although other choices with wider gamut exists, such as Wide Gamut RGB).
  • The Display Profile really is the monitor profile. So chose the ICC profile for your screen – watch out, even if my profile is called something like Samsung_27_12.icc, it always appears as ColorPlus since Cinepaint uses the author tag to display the profile name and not the profile file name. It is a bit uncomfortable if you have several monitor profiles: they will all appear as “ColorPlus” so you have to figure in which order they appear from the alphabetical order of the filename. Not ideal.
  • The Proof Profile is used for printing simulation, we will get there later.
  • The Default Rendering Intent tells Cinepaint which policy (yes you should know what that means by now) to use when translating colors from one profile to another. Perceptual is the logical choice there – even if it says relative on the screen shot.
  • I don’t have a clue what Default Transform Calculation does, so I leave it on CMM default🙂
  • Black Point compensation tells Cinepaint whether it should remap the darkest point of one profile to the darkest point of another. Whether this is a good idea or not is debated, but as far as I understand, it is more important for press or offset printing (where gamuts are really small) rather than screen or inkjet printing (what we deal with it here). So mine is ticked🙂
  • The Behaviour bit deals with what Cinepaint should do when a new image is opened: for me it assigns the assumed image profile. The logic behind that is that my camera is set to produce AdobeRGB files and that Cinepaint should assign (ie consider the image as being produced in) AdobeRGB. So that looks logical.
  • In case of mismatch between the assumed profile and the profile that the image reports (say the image is sRGB and my assumed image profile is AdobeRGB) it prompts me about what I want to do. Basically that means that when you open an image where profiles mismatch, you get a pop-up asking you if you want to convert the image to the new profile or change the editing profile (from AdobeRGB to sRGB in this case). This should normally rarely happen, so not much to worry about – we will talk about converting images from one profile to another later, on the subject of printing.

All that stuff really looks complicated and (very) verbose. However, once you have sane defaults and a stable workflow, CM is transparent. You work on your images as usual but the CMS is doing its job: you know you see the “true” colors on your screen, you know your prints will look very close to what you have on your screen. So don’t get discouraged. It is tough to get a proper setup and understand the principles / concepts, but once the initial setup is done, you don’t touch it anymore and the reward is well worth it.

A nice little one from Ardeche, to get us going🙂

Ardeche

13 Responses to Color Managed Monitor II

  1. sds says:

    Joel, I was wondering why you are not using your camera-specific input profile .icm instead of the Adobe RGB?

    Also, a bit off-topic, as a fellow Pentaxian — are you following the discussions on pentaxforums.com?

  2. jcornuz says:

    Hi there,

    The camera is set up to produce either AdobeRGB or sRGB files, so there is some color transformations already going on inside the camera. And the goal of the editing profile is to be a standard across cameras, scanners, etc.

    The use case scenario of a camera profile is if you work from a RAW file to which you apply your camera profile and which you then save (after dematricing) as a TIFF file in AdobeRGB. But I am not even sure how much gain there is there – if someone knows better?

    I do read pentaxforums but I don’t write there🙂

    Take care, fellow Pentaxian…

    Joel

  3. Seb Przd says:

    Joel,

    first of all, congratulations on your blog. It is an incredibly useful (and growing!) reference for linux and photography. I used argyllcms to calibrate my screen on the basis of your posts on the topic.

    I downloaded Firefox 3 and installed Gimp 2.4 to test color management from end to end – so you could say that I am a big fan of this “Helpful stuff” – from my point of view the “I hope” can be deleted now.

    I have a question however on Gimp 2.4 and color management (maybe Cinepaint is similar). When the screen is calibrated (with dispwin) and I set Gimp to use the icc profile of the screen to display the images, the colors are too intense. Since the images are sRGB, I can compare with Firefox and gqview, and there is a difference. When I set the display profile to “none” in Gimp, the image shows with the “correct” colors in Gimp. Am I doing anything wrong?

    Merci d’avance!

  4. jcornuz says:

    Hello Seb,

    Thanks for the compliment🙂 You are raising an interesting issue: how do I know what to trust when renditions are different?

    My advice would be to use Cinepaint as a base (see here for details about enabling CM in Cinepaint) since it has had CM support for quite a while. Compare the result with Gimp and Firefox (with the monitor profile loaded). I don’t think gqview is CM aware…

    Depending on the picture / colors, the difference when you tick Enable CM can be minimal or very important – especially if you boosted the colors in a non CM environment and then move to CM. So it can be that your “correct” colors are in fact over-saturated due to processing them in a non CM aware environment:-/

    I hope this makes sense.

    Take care,

    Joel

  5. Dariusz Garbowski says:

    Hello Joel,

    GQview 2.1.5 is color aware — there’s a small icon in the bottom-right corner where you can enable color management and switch between different profiles (e.g. if you have multiple monitor setup). You can manage profiles on the “Advanced” tab in preferences.

    In my personal opinion, GQview rocks!

    Dariusz

  6. […] get an icc profile which you can load with dispwin or xcalib (for screen calibration) as well as your graphic application (for profiling – if the application supports it). Check this entry if you need to know more about […]

  7. Ricardo says:

    I’m quite new at photography, and I’m trying to setup a color managed work flow, but there is something I don’t understand. Maybe this is not the right place to ask, but here it goes.

    I just got an Eye one display, and I used it to profile my screen using Linux. I can load the profile using dispwin, and I can see the difference in the appearance of my photos. What I don’t understand is why do I have to load the display profile again in any color aware program (Digikam in my case). Is not the profile already loaded? I have found many pages that say that I don’t have to load the profile in digikam (as it is already loaded), but I have found also some pages that say I have to. What is the correct way to do this?

  8. Davros says:

    Ricardo: My explanation will lack technical accuracy due to a little ignorance and much lack of articulation, but I believe it will still help. Pardon me as I introduce the explanation by reviewing facets of colour management that you already familiar with. Apologies in advance, perhaps Joel’s normally helpful crowd will contribute to the point where I can refine this and then re-write it to be a helpful and more accurate explanation in the future.

    Every element of the workflow needs to know what profile to work with in order to allow it to have a common frame of understanding of colour with every other element in the workflow. Each application and each piece of hardware (scanner, camera, printer, whatever) is its own element in all of this. Your monitor is just one of the pieces of hardware involved. Through some part of the operating system (a graphics driver, the desktop environment, the deep internals of Linux, something OS related) your monitor is controlled and utilizes your profile loaded by dispwin (or equivalent). The individual applications on your system do not know this, they must be told how to understand the colour in the same way your monitor understands it. Dispwin will adjust how your monitor is controlled for the benefit of your eyes, and the colour profile will tell individual applications (if they know about it) how to understand the colour for the benefit of internal calculations (decoding, manipulating, saving, etc).

    Linux is behind on colour management, but blogs like this and efforts by various programmes such as Graeme Gill and Kai-Uwe Behrmann are changing it for the better. Most operating systems have a method for feeding the monitor’s profile to all the installed applications. You have to tell programmes like Cinepaint, Krita, GIMP and Digikam what profile to use because they do not know that dispwin is using one to adjust the monitor. Things may look fine for you with your profile active, but when one of those programmes does something to an image, the colour will not be consistent when it is sent somewhere else, printed, used in another programme, used by the same programme down the road, etc, etc, unless the application has a colour profile to work with and knows about it. Each programme and each piece of hardware (the monitor) are separate elements in the workflow and each element needs to know about the appropriate colour profile.

    As I mentioned, things are improving. One example of improvement is the Oyranos project. It is being worked on by only one person, so it is slow going, but when it is done, it will allow the user to simply select the appropriate profile and not worry about it again. No need to tell each individual application anything, they will already know. Other operating systems all require that individual applications use a colour profile for consistency, but they automate telling those individual applications, Oyranos in theory will do the same for GNU/Linux.

    There may be Linux programmes that already search for a colour profile. Perhaps some versions of the same programme do while others do not. There is no official spot in the FHS (Filesystem Hierarchy Standard) for ICC profiles (although a defacto standard of /usr/share/color/icc is around) so it is also possible that some programmes look for those profiles automatically but are checking the wrong spot. I am not aware of any specific examples of any of this, but it offers a possible explanation of why you read contradictory instructions about telling certain programmes where to find the profile. All of the graphics applications you use will need to be told about the profile in order to achieve consistency, it is just a matter of whether or not they already know through self-detection.

    I suggest going into Digikam’s preferences and setting your profile as appropriate. I am hardly a Digikam expert, but I believe that there will be no harm in setting the profiles as appropriate even if Digikam already knows about it.

  9. Ricardo says:

    Hi Davros

    Thanks for your explanation. My question was raised, because I assumed that any program not using color management output the image in an standard RGB color space (I assumed it to be sRGB, but there is no reason why this must be the case), and that the X server with a loaded color profile would correct this image to show it right to on the display. I also assumed that if the program is color aware, I can activate the color management for the program, and it would correct the image and show the image fine on an uncorrected X server (without color profile loaded). But what I don’t know is what would happen if I load a color profile in the X server and I select color management for the monitor in Digikam. Will the correction be applied twice?. From what I can understand from your explanation the safest bet is to activate in Digikam, and not apply color correction on the X server. Am I correct?

  10. Davros says:

    Any programme not using colour management interprets colour in whatever random wacky way it feels like. The X server should have a profile (loaded through dispwin or something similar) for your monitor. I am experimenting with digikam usage but I am not that familiar with it so I may be missing something with new versions. Again, I am confident Joel’s helpful crowd will chime in if need be. A normal graphics programme that is colour managed will ask for the monitor profile so it understands the monitor, not controls it. It will be able to get the colour out to you in a consistent way because it now knows what your monitor does. It will also normally ask for a working colour space choice. This is a working space that determines what colour gamut you will work in and will be used for internal computer calculations. Digikam is different in that the manual says “The Use color managed view is an alternative to using Xcalib or Argyll.” I have no idea what they mean or how that could work. My first instinct is to think that if you have xcalib (dispwin) running anyway all the time, not to bother with having Digikam do anything that could control the monitor. Then read up about all the different colour spaces and pick a good sounding working one. (Bruce, ProPhoto RGB, Adobe RGB, sRGB, whatever.) However, as I said I do not know exactly what Digikam is doing when it says its colour managed view is a replacement for xcalib, so my advice may be way off.

  11. Erwin says:

    A late reply, but I have to date found no conclusive instructions on Digikam/X and monitor color profiles. I enable both: I load my monitor profile into X (through DiscalGUI) and enable color management in Digikam (as well as in GIMP, Rawtherapee and so on). Since images now look the same in Digikam and Eye of Gnome (which uses the monitor profile that X uses), I believe this is the correct approach.
    However, one painful issue remains: browser compability. I usually upload my pictures from Digikam to Flickr. On a calibrated monitor in a Windows-environment, these pictures look perfectly fine. On the other hand, viewing them in Linux on both Firefox (color management enabled none the less) and Chrome (non color management enabled, so therefore to be expected) yields oversaturated and darkened results.

  12. ninez says:

    Hey there,

    Handy info, Cinepaint wasn’t picking up my profiles, so i saw this article and the ~/.color/icc and voila!

    although this article is a little dated, i think i will link to it from my youtube, if that is okay?

    awesome stuff

  13. Understanding an IP Address

    Color Managed Monitor II | Linux Photography

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: