Color management 3 – monitor calibration

For the CMS to be able to present images with correct colors on the monitor, (wich is – in my view – a must for any image manipulation) it must have a color profile for the monitor. Certain monitors ship with a factory default color profile, what is better than nothing, but you can create your own.

The easyest way is to adjust your display. A good explanation about it can be found in this article at linux.com. Although i can’t really agree with every point of its theory, the solution works, and is more or less accurate. This method won’t create a profile, but merely adjust your display settings, but it is better than nothing.

A better way is software-only “calibration”. Theese methods involve evaluating with our eyes, wich are not the most accurate measuring devices in the universe. The most widely known software of this kind is Adobe Gamma. You can guess if it is avialable in linux or not ;-). But fortunately, Monica and GAMMApage do the nearly the same (I must admit that so far I have not tried any of them, and it is not clear for me if they are just altering settings of x, or creating a monitor profile. Basically, calibration is not equal to profiling and therefore they are not likely to be albe to create profiles) as well as LPROF (i will post my experinece with LPROF at a later time).

The best way is to use a hardware calibrating tool, a so called colorimeter. Unfortunately, theese devices usually don’t come with linux modules. There are two workarounds. First, LPROF, and ArgyllCMS can handle several colorimeters. Second, on dual-booting systems, a profile created on one os can be used on the other as well (more on this can be found on Nicolas Vilars’s page).

Let me explain the process of creating a display profile with a colorimeter. Colorimeters can be used to calibrate and profile your monitor. Theese two functions are to be separated.

Calibration is the act of bringing a device to a known operational state. In the case of a monitor this includes two things: setting the white point of the monitor, setting the gamma (mid-tone) of the monitor. (this is the step you can do without a colorimeter)

Profiling is a process where the colorimeter and a software are used to determine the gamut a given display. Usually a series of colored blocks are displayed on the screen and measured by the colorimeter. The software uses the difference between the measured values and the original input values to determine the ability of the monitor to reproduce a wide range of colors. This range of reproducible colors is called the display gamut, or display color space.

After that a profile is created for the display color space.

Advertisements

Color management 2 – workflow, profiles

Below can be seen the devices that participate in the color management workflow. Every device has its own color profile, and are connected by the CMS (btw, the Crystal Diamond Icons of KDE, of wich I used a few to create the drawing below are simply beautiful)

Color management workflow

Images mostly are created by digital cameras and scanners. Theese devices (or a lot of theese devices) append the color profile of the color space the image is taken in to the image file.

Image files can live well without embedded color profiles, but in a color managed workflow they should have one, because without it, the CMS won’t know how to treat them (files without embedded profiles are assumed to be sRGB). I mean if you are opening an image in an editor, the CMS – already having your display profile – are to make a conversion on the picture to the display profile for your being able to see the exact colors.

Actually, it is a bit more complicated. There is the so-called working space. It is not related to any of the devices, but it is the color space the image is during edit.

The process is the following: The image is first to be converted from the camera’s (scanner’s) color space to the working space (depending on settings, it is usually automatically done by the CMS). Every time the image is displayed, it is converted to the monitor’s color space. When printing, it is converted to the printers color space (printers usually have many color spaces (for every paper that can be used in a given printer there is usually a printer profile for every printing quality)). When saving, it is up to the user to choose a color space to save the image in (and the profile for that color space is then appended to the image file).

Different outputs may require different color spaces. For instance, when saving an image for web the best practice is to save it in sRGB color space. sRGB is a standard color space in use today that serves as a profile for the “standard” desktop monitor. This is the color space used for most consumer digital cameras and most “non-professional” workstation monitors, and represents most of what you see on the web. In comparison with other color spaces, it’s gamut is slightly narrow. When saving an image for further editing, sRGB – because of its narrow gamut – may be a bad choice, because you can lost colors. Let’s see why.

Color spaces

There are three types of color spaces, according to their gamut.

Small-gamut spaces have gamuts comparable to CRT monitors. sRGB is the default color space for the www.

Medium-gamut spaces have gamuts somewhat larger than CRTs; comaprable to high quality (more than 4-color) inkjet printers. Adobe RGB (1998) is the most widely known.

Wide-gamut spaces have gamuts much larger than CRTs or inkjet printers, sometimes comprising colors the eye can’t see. ProPhoto RGB is an example. Since half or less of the total gamut can be reproduced on monitors or printers, using a wide-gamut space sacrifices bit depth. (in the case of ProPhoto RGB and 24 bit, the number of colors is 16,7M, but a few million of theese is outside the range that monitors and printers can reproduce. And even if future technologies can show you theese colors, you won’t see most of them, as they lie outside the visible range too).

Conversion methods

The heart of color management is the conversion or gamut mapping between color spaces. Gamut mapping is performed with one of the four rendering intents (gamut mapping algorithms) recognized by the ICC standard. The rendering intent determines how colors are handled that are present in the source but out of gamut in the destination.

Perceptual. The gamut is expanded or compressed during conversion between color spaces to maintain consistent overall appearance. Low saturation colors are changed very little. More saturated colors within the gamuts of both spaces may be altered to differentiate them from saturated colors outside the smaller gamut space. The only rendering intent that is at least mostly reversible. Generally recommended for photographic images.

Relative Colorimetric. Maps all out-of-gamut colors to the closest in-gamut color. The white point of the original gamut is moved to the white point of the output gamut and all colors maintain their relative position to the white point. Maps all out-of-gamut colors to the closest in-gamut color while maintains hue and lightness at the expense of saturation.

Absolute Colorimetric. Similar to Relative Colorimetric except that it does not necessarily map white in the source to white in the target.

Saturation. Maps the saturated primary colors in the source to saturated primary colors in the destination, neglecting differences in hue, saturation, or lightness. For block graphics; rarely of interest to photographers.

Working color space

Working space is the color space in what the image “lives” during processing. It has to match both the input and the output device’s color space.

A good option here is to choose a space that is comparable to (I mean, bigger, but not much bigger than) the color space of the output device.

For the input device, if it is a digital camera, than if you shoot jpegs, than the color profile of the images is most likely to be sRGB, or Adobe RGB (1998), so a medium gamut working space will do.

The situation is completely different, if you shoot raw. Raw is not a color managed format, but that does not mean that it wasn’t shot in a certain color space. It just does not contain it. Your digital camera has its own color space (or can has more, as image sensors behave differently under different lighting condition (fluorescent or tungsten)). At the input stage of your workflow, you should assign your raw images with the appropriate color profile of your camera. Noticed that I said “assign” and not conver to? It is because the file is – literally – already in your camera’s space (it was taken with your camera, wasn’t it?, just it does not contain any information about it), but the CMS won’t know it as long as you explicitly don’t tell it, by assigning the profile with the file. Raw converters usually do this automatically (they read the camera model from the EXIF metadata, and assign an appropriate profile (if have one)), so when your raw file gets converted to some other filetype wich can have an embedded color profile, it will be converted from the color space of the camera to the color space you choose.

But. CCD and CMOS image sensors usually has wide gamut color spaces, with parts that can’t be reproduced (and percieved). You can choose to convert it to another wide gamut color space, or to a medium gamut one. As I mentioned above, choosing a wide gamut color space for working space can lead to loosing information. But on the other hand, if the input is in a wide gamut space, converting it to a medium gamut space will lead to loosing info too. Web-wide arguments are going on on wether to use wide gamut spaces for working space or not. In my view, using wide gamut color spaces for working space only makes sense in the case of high bit depth images (and most raw files are 36 or 48 bit depth anyway, so why downsample them?). In the case of a 24 bit file, an image may suffer visible loss as the result of the conversion.

Color management 1 – basics

Let’s start with a few questions: are the colors of a display “right”? Have you seen tv-s in a supermarket, all showing the same programme? Did their colors look the same? No? Wich one was “right”?

In an ideal world, every scanner, camera, printer and display would show or percieve the colors in the same way. But in our real world, every single device renders a different shade of red for the R=128, G=0, B=0 RGB value. Getting a print that looks exactly (or at least pretty much the same) like the image on screen needs a lot of tweaking. Or applying some form of standardisation in the workflow. This is called color management.

Although i don’t want to be too scientific in this post, but there are a few definitions regarding color management wich are often cause of minor confusion and needs explanation.

Computers and digital cameras can’t percieve all the infinite number of colors we are presented with. They all store information digitally, and they need a system that describes colors by means of numbers. There are quite a few approaches to this problem, theese are known as color models. For instance, RGB. In RGB, combining pure red, green and blue together will result in white; the absence of all three primary colors results in black. RGB was designed with displays in mind, and it doesn’t work well for printers since they have to combine various inks to get what they want. On a printer, absence of any ink results in white (or the color of the paper, if it is not pure white). Printers work opposite the way monitors do to produce color and usually printer inks come in colors opposite the primary colors used by monitors. The CMYK color model consist of cyan, magenta, yellow and black inks combined to produce the various shades. A color model only determines the values that describe the colors (red, green and blue; or cyan, magenta, yellow and black, or whatever) and does not specify that to a particular combination of theese values what exact color will be the result.

Every monitor produces different range of colors. Gamut is a term to describe the range of colors a given device can produce or describe. This is the color space of the given device. It describes the specific colors the device can produce for any combination of red green and blue (in the case of an RGB device), or cyan, magenta, yellow and black (in the case of a CMYK device), or other numbers. It maps sepcific values of a color models to specific colors.

Every RGB device have its own unique color space.

Ok, but if a color space maps numeric values to specific colors, then there should be a universal color space to extract the specific colors from. And there should be a system that maps the specific colors of my printer to the universal color space (and vice-versa) and does the same with my digital camera, and monitor and scanner. This is the Color Management System (CMS). And it does its job by means of color profiles.

A color profile is a file that stores data on the relationship of a given color space (color space of a monitor for instance) and the above mentioned universal color space, wich is called profile connection space. A color profile maps the colors of the color space it represents to colors of the profile connection space.

The CMS is usually part of the operating system (afaik not in the case of linux), or is part of a software (Photoshop has its own CMS for instance), or (in the case of linux) comes as a separate engine that can be implemented by other software (like Little CMS).

One thing is important to note. Profiles only describe the color space of a device. They don’t change the device’s color reproduction capability.

to be continued…

Loading display profiles

An article is being made on color management, I’m currently gathering the sources. But until it will be published, here is one thing to start with.

Calibration of a display, and creating a profile for it on linux is not as easy as on other operating systems. There are only a few software to calibrate a display with a colorimeter (ArgyllCMS, and LPROF as far as i know).

I borrowed a display calibrator device, but none of the above mentioned softs can deal with it. But a display profile created on an other os can be loaded on linux! As far as the display and the video card is the same, the profile will be useful.

For loading the profile, I use xcalib. The de-facto standard directory of color profiles is /usr/share/color/icc, so i copied my profile there, and after compiling xcalib, i wrote a script that loads my monitor profile. Then i added it to System/Preferences/Sessions. Every time i log in, the profile is loaded.

I know that this post is floating in the middle of an empty space yet, but soon the post on color management will make it more clear .

edit on 17.10.2007.

Somehow on my new hardware (AMD X2 64) and with gutsy, i was unable to compile xcalib. It is likely to be some 64 bit issue, but anyway, i use Dispwin now, what is part of  ArgyllCMS. I downloaded the argyll precompiled executables, copied the dispwin to /usr/local/bin (i don’t know much about the file system standards, maybe it is not the best place, but it works) changed the attributes of the file, and written a script that loads my profile.