Color Management Myths 26-28

From ColorWiki

Jump to: navigation, search
Reserved Article

This page is a
Reserved Article.
For more details see
Reserved ColorWiki Articles

ColorNews

This reserved article originally appeared in CHROMiX ColorNews Issue 19 on July 20, 2005.

Click here to see the original in its original context.
Email
colornews(at)chromix.com to subscribe to the ColorNews newsletter.

by Steve Upton


Contents

Myth 26: Graphing profiles

"Graphing Profiles to see their gamut gives pretty much the same results in the different tools that are available."

ColorThink plots gamuts using the device->Lab (ie CMYK->Lab) "proofing" part of the profile. Like when you soft proof, we ask the profile "if I send 100% Cyan, what color will I get?" - only we ask it for a large number of these colors and we get a good estimation of the behavior of the device. If you built the profile yourself and have access to the original measurements, you can plot them along with the ColorThink profile gamut and they will match up quite closely (if it's a good profile). When we do this "proofing" conversion we use the absolute colorimetric rendering intent which gives us accurate paper whites and ink blacks.

The ONLY way to show the actual gamut of the device is to use the Absolute Colorimetric intent when calculating. This pulls the white down to paper-white and shades it accordingly. None of the methods of viewing profiles in the ColorSync Utility allow this.

The ColorSync utility allows you to view the "gamuts of profiles" by either clicking on them in the profile list (which shows the perceptual mapping) or clicking on the various A2Bx tags when you open a profile. When you click on these tags in the profiles, the CSU shows you the perceptual, saturation and relative colorimetric gamuts. What do they represent? Well, they show how colors in device-space (CMYK, RGB, etc) will appear when converted through the profile.

Does this mean anything? Sort of, but only to a very experienced user. People typically want to know:

  1. how is my device performing and
  2. how is my profile performing when printing? (which is the opposite, Lab->device conversion)

So, ColorThink answers #1 (and is the only grapher I know of that does it this way- why I don't know) and graphing a color list or image and applying a profile to get vectors answers #2.

The ColorSync Utility doesn't answer either of these questions... not that what it's doing is technically incorrect.... well perhaps it is: - each "unit" in Lab is supposed to represent the smallest color shift the eye can see - in any direction (lightness, saturation, hue). The lightness axis L goes from 0-100 while the a and b axes go from -128 to 127. This means the box defined by the ICC for Lab is not a cube but is wider than it is tall. There is no valid reason to stretch the vertical L axis to be the same size as the widths of a and b but many graphers do this including the ColorSync Utility. This results in "tall" gamuts and ColorThink's are "flatter". As far as I can determine, flatter is correct. Yet most other graphing tools I've seen stretch the Lab space into a cube, producing tall skinny gamut volumes that don't make sense (at least to me).

Other graphers like Monaco, GretagMacbeth and others plot what I call the "rendered gamut" of profiles (as opposed to the device gamut). Using this method, Lab values are converted through the profile to device colors and then back to Lab. If very saturated colors are chosen at the outset then this round-trip method will squish them into gamut and then a gamut volume can be graphed. This volume can be useful but does not describe the device behavior alone - it really shows what the profile will give you if used to print to the device (and specifically how the very saturated colors will print).

This may seem like splitting hairs but it's not. Many printers receive CMYK files separated by unknown profiles. A device gamut will describe the maximum space these images can occupy, a rendered gamut will not and, in fact, some image colors may appear outside of the rendered gamut. Another way to think of this is with the example of ink limiting. If you build a CMYK profile that has a total ink limit of 200% you will probably limit the gamut of files printed using that profile. When graphed in ColorThink you will see the gamut of the device, all the way up to 400% coverage. In other tools you will see the rendered gamut, which will be smaller, especially in the darker colors.

A bit long-winded I know but that's the way it is with color..I hope this helps.

Myth 27: Why would anyone ever want to choose a working space that is larger than you can print?

This is a classic question and one that we receive only slightly more often than "Why does my printer keep recommending such small working spaces?"

The roots of these schools of thought are in the perspective of each user and how they tend to want to recommend (push) their workflow to other people. In studying color reproduction challenges over the years, I have broken workflows down to three distinct groups (I am exaggerating them a little):

Input Centric

This is where people want to capture as much of the original film (or scene) as possible. They choose large working spaces (much larger than the monitor gamut) and archive high-bit images for the day when printers catch up with their desires. Monitors, printers and presses are necessary evils that all degrade the appearance of their work. If they have the ability they will fill a whole CD with one scanned image. You might guess that this is where photographers often reside.

Output Centric

This is where the final print is the deciding factor in workflow decisions. Working spaces like ColorMatch are considered plenty big enough to contain all the colors one would want to print. So working spaces are chosen that will contain the gamut of a press and nothing more. Much of their work is done in CMYK (in-gamut by definition) and they wonder why anyone would bother capturing color that can't be printed. As you can imagine, prepress and printing folks are in this group.

Display-Centric

This is where people just want what's printed to match what's on the screen. Computer artists, 3D artists, video editors and consumers tend to fall into this group. All work headed for the web also falls in this category. sRGB is typically chosen as the working space as it tends to match the display gamut fairly closely. It doesn't contain any more colors than the display can show so there are fewer surprises.

The truth is that each of us will find ourselves in these different roles at some time. There's nothing wrong with being in any of the groups and people may change groups depending on their budget or project. It's fair to say, however that folks who are entrenched in any one group have a lot of trouble understanding the other groups.

Ever try to get an offset printer to try to understand your photographic decisions? or vice versa?

So if John is an "Input Centric" and your are an "Output Centric" you will probably never see eye-to-eye on working spaces AND you may each be using spaces that are good for your respective pursuits.

In color management there is often no single correct way to do things. What we do suggest is a few things that will apply to all:

So, it's important but there are other very important things that can make or break your color.

Myth 28: The PowerBook G4 displays 16.7 million colors (or any display, for that matter)

This is not true. Don't confuse RGB number combinations with the number of perceivable colors.

I can send 16.7 million different RGB NUMBER combinations to a PowerBook display (3 channels with 8 bits per channel) but it will only display 518,733 different colors. This means that 16,258,483 of the RGB numbers are basically "wasted". Another way of looking at this is to say that the entire gamut of 518,733 colors is chopped into 16.7 million separately addressable "chunks". Problem is, the difference between each of these chunks is smaller than is perceivable by humans. So if you glom chunks together until each blob is just barely perceivably different than the next, you'll end up with 518,733 of them.

That explanation is a bit of a stretch but sometimes it helps to break these things down to understand them. (pun intended)

This confusion is another example of the difference between RGB and CMYK values and actual colors.

Another example of this is with CMYK devices. I can send 100,000,000 CMYK values to print on newsprint (100x100x100x100). Does that mean I'm going to get that many actual colors? No, of course not. If I send those CMYK values to a sheet-fed press on glossy coated paper will I get that many colors? No, but I'll get more than I did from newsprint. I'd probably see even more from an inkjet. While I can address the colors on a press using CMYK combinations, each CMYK combination will not produce a unique color.

Thanks for reading,

Steve Upton


For more Color Management Myths, see Color_Management_Myths_29-33

List of all color management myths

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox