Color Management
sRGB, AdobeRGB OR ProPhotoRGB? My Color Management Journey
Tuesday, February 17, 2009
Perhaps the most misunderstood aspect of color management is the choice of a working space, and Color Management Urban Legends about working spaces are plentiful. I stated in the previous article I feel the ultimate color managed workflow requires setting the working space in Photoshop to ProPhotoRGB and conversion of RAW captures into 16bit ProPhotoRGB files. This is the workflow built into Adobe Lightroom, and works very well.
What is a working space and how do you use it? The only analogy I’ve ever come up with is in comparison to most sports. The working space is sort of like the rule book and field of play for the Color Management System(CMS). It defines the colors for the CMS, which using those rules modifies all of the color data to whatever device profile the data is being viewed in, and sets the boundary or limit to the available color pallet (gamut) for the application. As we work on our file within the editing program any change which creates a color that is “out of bounds” is remapped back in bounds by the CMS. The only way we can be sure we are not limiting ourselves is to make sure our color space is large enough to contain all of the colors we are working with. Currently ProPhotoRGB is the only standard working space which is large enough to do that.
For many years my prints didn’t match my monitor very well, so I was still working the same way as when I used a darkroom ... print a test, correct and print another test, rinse and repeat until it looks good. In the past few years, my personal focus has changed to landscape photography, with my goal always being very large and high quality images. I set about trying to get a better monitor to print match and found there is an incredible amount of information out there, with plenty of people offering all kinds of advice - much of which is contradictory. To make matters worse, nothing ever dies on the internet, so things written several years ago remains, even though technology advances require a different approach now.
Like many photographers, I didn’t pay much attention to working color spaces for a long time. Ignorance is bliss they say, and I really didn’t understand much about color management. I started with sRGB as my working space in Photoshop because it is the default when you install it. At some point I discovered my camera had a setting for AdobeRGB, so I switched my working space to match. I made the assumption that the “working” space was whatever space I captured the image in. I didn’t even realize RAW files do not have a color space (in the context of this discussion anyway), and the AdobeRGB camera setting I enabled only applied to any jpegs the camera made.
During this search I found several very helpful articles which I have linked at the bottom of the page. As far as working space choices, an article by Adobe Camera Raw guru Jeff Schewe demonstrated very effectively why ProPhotoRGB is important, even if the destination is for a web sRGB jpeg. I never miss attending Jeff’s classes at Photoshop World, he has a great knack of demonstrating the practical application of somewhat technical information. You may want to take some time and look it over now, or refer back to it after reading how it affected my thinking.
Schewe Photo -sRGB VS ProPhoto RGB
As I reviewed this information, a few things started to clarify in my understanding of color management.
1. The working space doesn’t have an obvious visual relationship to the various device spaces in our workflow, such as our monitor or our printer. It’s more like a container for our image data.
2.The camera can definitely capture colors which are outside of the sRGB and AdobeRGB spaces, and normally you will expand that range further when rendering the image in the RAW converter.
3.If you choose a working space smaller than the colors of your image when rendering from your RAW convertor, or as a working space in the editing program such as Photoshop, the Color Management System will compress and clip the colors so all colors will fit in the working space. Any color information outside of the working space is gone for good, and some of the data that was inside the space is permanently modified based on the smaller space.
4.Many normal steps in Photoshop will not be able to use any colors outside of the working space,artificially compressing and restricting your colors. Because the monitor is gamut limited, you may be deceived and think it doesn’t matter since it isn’t as apparent on the monitor, but in reality what you are doing is restricting all output to fit inside the limited gamut of your monitor. One of the most common mistakes in trying to set up color management is assuming the monitor is a good guide.
5.Most printers since the introduction of the Epson 2200/7600/9600 can print some colors which are outside of the AdobeRGB color space (and sRGB space). Current printers have a large number of colors outside of AdobeRGB, and it can be assumed this trend will continue as printer, paper, and ink technology progress. If you limit your editing to sRGB or even AdobeRGB, you cannot take full advantage of current and future output technologies. If you don’t limit your editing by using ProPhotoRGB you can easily take advantage of future advances by simply using the new device profile ... the CMS system will map your image colors into the new space and any advances will automatically be realized.
6.The Color Management System, if you set it up right and trust it, does just what it says .. manages the entire process. Your image will be mapped through the appropriate device profile whenever it is viewed, such as your monitor while editing or your printer when printed. The job of the CMS is to maintain the visual appearance of the image regardless of the gamut of the device. You don’t have to be overly concerned with the overall gamut of the space and any mismatches ... the CMS takes care of it for you.
With these thoughts in mind I continued to do quite a bit of research trying to understand the role of the working space. The more I felt like I understood how things worked and the more I began to trust it, the simpler it actually became. I’m not an expert, but my color managed workflow functions very well because I now understand what it is trying to do and how the pieces interact with one another. In my current workflow I still print a “test” print ... an 8x10 on Epson Premium Luster paper using an Epson 3800 printer. My monitor to print match is extremely close, and usually when I make a correction it is because I see a flaw in some of my editing, not a problem with the overall image color or saturation. When I am happy with the test print (very often the first one), I print the finished print on my Epson 11880 or Epson 7900 using Epson Exhibition Fiber paper. These printers have a larger gamut than my 3800, but by using good printer profiles, the match is very close. Side by side you can see some differences ... the expanded color range of the two large printers often reveals a slightly better image. Despite the subtle differences, the prints from all 3 printers are terrific and completely acceptable.
One of my obstacles to understanding and trusting color management was a failure to realize the working space is not an output space and nothing is ever viewed in the working space. It’s the container for the data for our image, and establishes the rules for the application when we open the image for editing. The Color Management system is the referee, and forces a color management aware application (like Photoshop) to play by the rules of the working space. As long as our image is opened in a program that is color managed, the image will be rendered in the appropriate output space when it is viewed.
The key is to actually let the system work as intended and not short cut it. In the case of the article by Jeff Schewe, he is comparing whether we make the edit’s in the confines of a limited working space that happens to be the same as the destination space (web sRGB), or if we perform those edits in a wider space and after we are done we then allow the color management system to map the results of all of our edits into the destination space. If we remember that even devices with much lower capabilities can still appear visually similar to wider gamut devices, we understand how editing on a gamut limited monitor doesn’t necessarily restrict our ability to maximize quality for devices with larger gamuts, such as our printer.
One of the problems with researching this information is while ProPhotoRGB has actually been around for a long time, the need for using it as a working space hasn’t been as important until more recent years. If 100% of the image data could be contained inside the AdobeRGB space, and if non of the output devices could exceed the AdobeRGB space, there wouldn’t be much reason to use a wider space when working on images. It really wasn’t until a few years ago, with the advent of the Epson K3 Ultrachrome inks as well as advances by Canon and HP, that printers began exceeding AdobeRGB enough to have a visual difference in output.

Printing an image on a 9800 would result in great prints. If our working space was AdobeRGB all of the colors outside the wireframe would have to be pushed into the wireframe. With the 9800, such a small number of colors are affected very few prints would exhibit any differences (although some certainly might).
Because of this, there is a lot of information out there still recommending AdobeRGB floating around. As I said, nothing ever dies on the internet. In the past few years however this is being challenged for a very good reason ... it no longer applies.


Here are two comparisons of the new Epson 7900 printer on the same paper against AdobeRGB. As you can see, this printer is capable of producing a large number of colors well outside the limits of AdobeRGB, from greens to blues as well as oranges and yellows.

The original capture of this image is a RAW PhaseOne p45+ file, which has been rendered into a 16bit/ProPhotoRGB working file with Adobe Camera Raw. In Photoshop, some additional work was done (not much) until I was satisfied with the resulting image. For display on this web page, it was then converted into the sRGB space.
Does the web version lose anything? To be honest, it isn’t a lot different than the image on my monitor in Photoshop. (Of course, my monitor’s color space is very similar to sRGB so that makes sense.) But I can tell you it isn’t as good as a print ... not even close.
ColorThink is a great tool to compare this type of data. First, here is a graph of the actual colors of this image(solid area) compared to ProPhotoRGB (wireframe).

As you can see, the image colors easily fit inside this working space. No matter what I would like to do with my data, the color management system won’t have to impose any limitations. Some criticize that the space is too large and can cause posterization. This is why it is important to also be working with 16 bit files.

Here is the same image data graphed against the AdobeRGB space. As you can see, about 20% of the colors of the image exceed AdobeRGB. Had I used AdobeRGB as my working space, all of these colors would have been clipped or pushed into the confines of AdobeRGB, and some of the colors inside the space moved closer to the center to make room for the colors being pushed in.

Here is the image compared to the sRGB(wireframe) space. Even more of the colors are outside of the space. The actual photo on this page has been converted to this space, so all of the colors of the image outside the wireframe graph have been pushed in so they fit inside the sRGB space for display on the web. The Color Management System has done a credible job of doing this so the web image looks OK, but in reality there are colors missing from the image that you cannot see in a browser. The important thing is rather than clipping and constraining the colors as I worked on the file, which is what happens if we set our working space to the smaller space, the conversion is done after the file is finished, allowing a more pleasing rendition of the file. Since the image itself is stored as a 16bit/ProPhotoRGB image, all of this information is still available for use on other devices that have better gamuts than sRGB.
So what happens when using a better output device, such as my Epson 7900 printer? This is challenging to show on the web ... it is much easier to see when you can drag the graph around in ColorThink. However, this graph at least gives you some idea of my point. Here we have plotted 3 spaces. Adobe RGB is the blue wireframe, the image data itself is the solid grouping of dots, and the 7900 space is the magenta wireframe.

You can see there is a large number of colors in this image between the blue and the magenta wireframes. These are colors which are in my image, and can print on my printer. Had I used AdobeRGB as my working space, all of this color would have been lost ... pushed inside the AdobeRGB space. The image would have still looked OK, but much like the web jpeg those printable colors wouldn’t have been on the print. True there are some colors needing pushed into the printer space, but even so many less colors are affected, and most of the colors being pushed will still be outside of AdobeRGB when moved into the printer space.
Does it make a difference? In this case it absolutely does. There are some delicate tones in the aspen leaves, pale oranges and reds that are not visible unless the file is printed on a newer printer. I first noticed it when I printed the image on my Canon ipf6100 ... I was surprised how much different it was than the print from my Epson 9800. The difference between a print from the Canon and the new Epson 7900 is not as striking, but even there I can see a little more color in the leaves. Because more of the colors can be printed, fewer colors need to be pushed into the space, allowing more detail in the yellow leaves. Yes ... the printer can render more subtle gradations because it has more colors to work with instead of a big mass which has been clipped into the same or nearly the same color.
I often see discussions claiming you don’t need to use ProPhotoRGB, some even showing various “examples”. It’s a little humorous, because how can you really demonstrate this with a bunch of pictures that are limited by the gamut of a web browser? Normally what you find is they are just bypassing parts of the color managed workflow ...pushing everything to the lowest common denominator such as the monitor profile or sRGB. The final part of this series, Color Management Urban Legends, talks about some of these and why they really don’t add up.
The most common argument against ProPhotoRGB has to do with the space being too big. Each color space is described by the same amount of reference points. If we make the space larger, the distance between those points increase. Andrew Rodney uses the analogy of a balloon covered with dots. As we make the balloon larger, the dots get further apart. If the dots were actually distributed 3 dimensionally inside the balloon, you can visualize how these would also get further apart. The assumption is as these reference points get further apart, the space will introduce banding, and be detrimental.
Most of the articles that really try and legitimize this theory are pretty dated, and they don’t supply any answer for those that want to take advantage of newer printer technology. It does little good to expand printer gamuts if we intend to force all of our image data into a space that clips the extra color anyway. This entire issue is actually “theoretical” ... while it may actually be true, it is so small you can’t actually see it.
As I said, I’m not a color scientist. I’m not sure exactly how the data in the profile is used. However, it seems that for this to happen, the space would actually have to describe every color, not just reference points, and those colors would have to spread out far enough so that a visible difference can be seen. Each pixel of a 16bit file contains 1 of a possible 281 trillion colors ... yes trillion. I don’t think a profile can map each of those individual colors. What it can do is contain reference points, figure out where a particular color falls in relation to various reference points, and use that information when mapping to a new space using that spaces corresponding reference points. I’m sure it isn’t as simple as that, but to cause banding would require the distance between the colors of the file to be far enough apart to be visually observable, not the space between the various reference points. The colors are not forced to reference points, they are all available. Personally, I don’t think this is possible if we have 281 trillion colors to work with. With an 8 bit file where we only have around 16million colors to spread around perhaps. Working with an 8 bit file in ProPhotoRGB may indeed be problematic ... AdobeRGB is probably a better choice here. But anyone seeing banding or other similar issues in subtle tones when using 16bit ProPhotoRGB images and ProPhoto as the working space in Photoshop has a problem somewhere else in the workflow ... the RAW convertor, the original camera data, some poorly done adjustment layers. Using ProPhoto RGB as the working space is not the cause. Sure you may “fix” it by forcing your image data into a smaller working space, but this is a work around, and places limitations on what you can do.
Enough about this from me. Here are some good articles that were very helpful to me in my learning process ... better written than mine. Hopefully my journey of color management understanding has been a little helpful.
The Role of Working Spaces in Adobe Applications by Andrew Rodney
Understanding ProPhotoRGB by Micheal Reichmann
Why Use the ProPhotoRGB color space? by Uwe Steinmueller
“Fall Path”
Hasselblad H1 with PhaseOne P45+ back
150mm
1/10th at f/8
ISO 200