Why use ProPhoto RGB?

When should ProPhoto RGB be used when converting RAW files?

I see that Bruce Fraser (may he RIP) used it in Real World ACR, and it is the default space in Lightroom, is it not?

Yet, my output is either for the web, for ink jet print, or for commercial print. Colors that are within the ProPhoto RGB gamut will be clipped in sRGB (web output) and Adobe RBG (photo print output).

Should I continue to use sRGB and Adobe RBG?

Default: Adobe RGB is a good color space.
if you have bought ProPhotoRGB then you can use it or Holmes color space.

Read this article:

http://www.jeremydaalder.com/singleArti ... rticleID=6

explains why it's often not a good idea to use it.

That article was written in March of 2005 - two years ago. There are more output devices today capable of a wider color gamut. The latest Canon iFP5000 can actually output 16-bit per channel color.

There's a good article on ProPhoto RGB on the Luminous Landscape site.

Understanding ProPhoto RGB

Perhaps the key point in the article is illustrated by the mouseover-based figure 3 under the topic heading ProPhoto RGB to the Rescue. The bottom line is that ProPhoto RGB comes a lot closer than smaller spaces such as Adobe RGB to preserving the range of colors captured by the camera illustrated in the figure, in this case a Canon 20D. (Presumably other DSLRs capture a similarly broad range of colors.)

That said, the article also explains the out-of-gamut problems one can run into with such broad color spaces. Thus, it is a mixed blessing, and using it can sometimes be more trouble than it is worth. The full benefit will only emerge when we have output devices whose profiles more closely match ProPhoto RGB.

One can start to develop a sense of what these spaces look like by downloading the Microsoft Windows Color Control Console and using the comparison tool to compare different spaces and profiles, much as Michael Reichmann has done in the above referenced article.

Microsoft Color Control Console

I have started doing all color editing (saturation, levels, brightness, colors, etc) as well as sharpening and other 16 bit work in ProPhoto RGB, and do all conversions of Raw into that color space. Once I have done all the processing work and am ready to either print or post I convert to the appropriate color space for that application. I'd rather preserve as much of the color gamut captured by the camera as possible while doing digital processing.

Even though that article by Jeremy was written some time ago, the points he makes still remain valid. Even if your camera can capture colors that lie outside of Adobe RGB (it can) and your printer can print those colors (it might be able to, esp. in saturated yellows), there is still the issue that your monitor can't display them properly. In other words, you can't get an accurate preview of your image on-screen when processing your image because the colors that you see are actually being limited by the gamut of your display.

In short, it's unclear if there is any benefit to processing colors that you can't see properly.

A significant fraction of the ProPhoto colour space consists of non-physical colours that cannot be reproduced. That's right, they're pigments of your imagination.

LOL! Nice zinger, Stephen.

Personally, I consider it a fidelity issue. DSLR cameras can capture colors outside Adobe RGB. If any image data is going to be lost, stripped, clipped or whatever, I want it to happen:

• a) Under my control, not the control of something over which I have limited or no influence.
  b) As far to the back-end of my workflow as possible, not at the front-end of the workflow where it cascades through everything after.

Daalder's points are true as far as they go, but it's like saying that a reciprocating saw is dangerous because it can cut through things so you'd better not use it. Understand it, know the strengths & weaknesses, and then apply it appropriately if it does the job for you. Personally I'm using ProPhoto RGB for everything right now, spurred into that as my default by deciding to adopt it for my HDR work. It's overkill to use it for everything, but it's not having any negative consequences that I know of.

The 8-bit thing is kind of a non-issue because anybody doing enough post work on files to see banding (and care about it) also knows -- or soon will -- to use 16-bit files. So that whole line of argument, while true, is a moot point IMO. Current gen inkjet printers have better gamuts than at the time Daalder wrote the article -- broad enough to take advantage of some more hues in a wider color space. Typically the lighter colors favor pigment printers and the darker colors favor dye printers, but both types of inkset can exceed Adobe RGB.

So the only real issue is what Eric points out, the difficulty in working with colors that you may not be seeing correctly because of limited monitor gamut. This is not an insurmountable problem, it just means again that you have to be aware of what's going on and be in control of the process. The CS2 color management dialog's setting "Desaturate Monitor Colors By X%" provides one simplistic mechanism for getting colors out of the monitor's gamut knocked down to a point where you can at least see them and work on them. It's crude but doable. Looking for gamut warnings while soft proofing can identify when some of these out of range colors may be happening, so you can take further steps to deal with them.

You've got other control points, including selective color adjustments and choice of color space conversion rendering intent that can affect how any super-saturated colors are dealt with. If you really want a richly colored image in Adobe RGB (or sRGB), you can do RAW conversion into ProPhoto RGB and then convert it to a narrow color space with better control over what happens to out of gamut colors in between. During RAW conversion itself, if gamut clipping is going on when using a smaller space, about all you can do is live with it or globally reduce saturation on the image (which is a poor second best). So over all the situation is not ideal, but I wouldn't say there is no use trying to work in a wide gamut space.

Have a look at this page for Joseph Holmes' overview of various color spaces, including his own custom ones which I've been considering adopting for awhile now. (Mainly stopped because I can't select them as my RAW conversion target in ACR.)
http://www.josephholmes.com/propages/2DGamutPlots.html

Here's what he says about Adobe RGB vs. ProPhoto RGB:

Adobe RGB (1998)
You might ask yourself, what does the gamut of 1950s color television have to do with the gamut of subject colors delivered by today's digital camera systems? Adobe RGB is famously said to have been created accidentally by combining two existing television gamuts into one working space: the red and blue of PAL/SECAM and the green of NTSC (1953), from which it is indeed made. For an accident, it performs well, but its match to real-world colors captured by digital cameras and processed in the camera or with RAW converter applications is far from optimal and its gamut is too small to consider it an accommodating general-purpose imaging space. It's tone curve is a gamma curve which gets much too flat near black, and its white point is D65, making it pointlessly different from the PCS white point of D50 and causing a slight risk of white point adaptation error. I think it's obvious that it should be replaced as a standard space for digital capture.

Pro Photo RGB
Pro Photo, from Kodak's color scientists, is a well-conceived space for storing a very large range of colors. My principle complaint with it is that is uses a gamma tone curve, and that all gamma curves are less than idea for encoding data because they become too flat near black and fail to match perceptual linearity very well. It's unlikely this will hurt you noticeably in a 16-bit workflow, however.

Here is what he says about a couple of his custom color spaces, DCam 3 and DCam 4, in comparison to Adobe RGB and ProPhoto RGB:

DCam 3 vs. Adobe, Lab Projection
This Lab projection is more perceptually accurate and shows the large conceptual differences between my DCam series (here the DCam 3) and this space which is so commonly used in digital imaging, including digital camera capture. Needless to say, my research indicates a wide gulf between the requirements of ideal digital capture and the currently dominant sRGB and Adobe RGB working spaces.

DCam 4 vs. ProPhoto
Though DCam 4 looks a little smaller than ProPhoto, if anything it will hold a few more relevant colors than ProPhoto, and uses a better tone curve. Both spaces are very good general purpose, huge gamut spaces, however. My spaces (except for Ekta Space) all share my perceptually uniform tone curve for optimal output mapping.

Holmes does advocate not using a massive gamut color space for images that don't need it, which is why he's produced a range of custom spaces DCam 1 through 5 with gamuts ranging from small to large. There are many images that would be fine in Adobe RGB, and in fact many that may be fine even in sRGB.

For another reference, see this article written for Adobe by Andrew Rodney, who is a proponent of ProPhoto RGB (when used properly):
http://www.adobe.com/digitalimag/pdfs/p ... lspace.pdf

Like Joseph Holmes, at the end of this article Andrew Rodney concludes:

As you’ve seen, selecting a working space is based on several parameters. Understand that while using a working space that might clip some colors or sending a smaller gamut image to a wider gamut printer may not utilize all the colors possible, using sound color management will still produce acceptable prints. You will not use all the colors you captured or could have reproduced.

If your goal is to use all the colors you can capture when you output your files, the role of the working space is important. However, it should be clear that a very large gamut working space isn’t automatically the best option for all situations or something you can "set and forget."

We should note there's a difference between the color space selected for the image, and the working space used by image processing applications. As pointed out, Lightroom internally uses something like 16-bit ProPhoto RGB as its working space, not giving the user a choice of picking anything else. The LightZone application does the same thing, using something like 16-bit ProPhoto RGB with a linear gamma curve, and no choice. Regardless of what color space best fits an image at the end, I don't think there's any reason not to work on images in 16-bit ProPhoto RGB or something else with a similar wide gamut, in order to preserve fidelity through the middle of the workflow.

This is another one of the "last few percent" quality issues that may never impact most people in a way they care about. But it certainly will impact some people some of the time, and a few people a lot more of the time.

I agree with pretty much everything stated above, Royce. (Lightroom and ACR do indeed use a 16-bit internal space with the ProPhoto RGB primaries but a linear gamma instead of Gamma 1.8.)

I continue to use PPRGB on the principle of being able to contain everything, and since I use 16-bit editing anyways.

However, from both a scientific and practical perspective, I confess that I have never seen a concrete side-by-side print example that demonstrates an image showing more saturated colors or color detail when using ProPhoto RGB compared to when using Adobe RGB as the working space. (Recall: theoretically, the only difference you should see are in the colors that lie outside the Adobe RGB gamut and fall within the printer gamut: namely, yellows.)

madmanchan wrote:However, from both a scientific and practical perspective, I confess that I have never seen a concrete side-by-side print example that demonstrates an image showing more saturated colors or color detail when using ProPhoto RGB compared to when using Adobe RGB as the working space.

Sounds like we're basically on the same page. I've not tested many files but I've seen it a couple of times in my sunrise/sunset HDR images.

Just googling around, here's a guy who tested and found a difference:
http://dimak.blogspot.com/2005/07/pract ... ersus.html

(Recall: theoretically, the only difference you should see are in the colors that lie outside the Adobe RGB gamut and fall within the printer gamut: namely, yellows.)

Well, yellows plus whatever is mixed with saturated yellow, yes? Depending on the inkset we may see this in other hues, e.g. I've not yet seen a serious look at the 12-ink mix of the Canon iPF5000 but it wouldn't be surprising if its gamut is wider elsewhere. Dye based printers have an advantage in darker colors, so people printing on them may see a benefit in blues.

Technically, benefits may occur not just for colors outside of Adobe RGB but within the printer's gamut. There is also benefit with colors captured by the camera that are outside of Adobe RGB. Whether you can print them or not, by not clipping them in an initial conversion to Adobe RGB it provides the opportunity to scale them and preserve some detail in super-saturated areas of the capture. This is possible in areas different than just yellow.

As a counter point to my own thoughts for those looking for balanced reporting , Mike Chaney (author of Qimage) feels Adobe RGB is sufficient. Here's a writeup from him:
http://www.steves-digicams.com/techcorn ... _2006.html

However, despite his main conclusion, Chaney's article does show gamut comparisons of the Canon EOS 5D, Adobe RGB and Canon i9900 printer. There are slices of both yellow and magenta that the 5D can capture and the i9900 can print, but which are clipped by Adobe RGB. The printer has range to print a big slice of cyan/green that is also clipped by Adobe RGB; however that slice is mostly/completely not able to be captured by the 5D and would have to be induced in the image file by a saturation boost to show up in print.

So to me there are 3 key reasons to use something like ProPhoto RGB in a 16-bit workflow:

• 1. Preserve colors captured by the camera that can be printed by the printer, which fall outside of Adobe RGB.
  2. Scale colors captured by the camera that can not be printed by the printer, to preserve detail in very saturated hues that would otherwise be clipped by Adobe RGB.
  3. Artificially introduce colors via post-processing that can be printed by the printer, but fall outside of Adobe RGB.

Yes, this is a good point, Royce -- the idea of preserving colors during the capture process so that they have a chance to be scaled during the output process (assuming a good printer profile!).

It is important to keep in mind that the only way to benefit from this scaling is to use the Perceptual rendering intent. The color detail would most likely be lost with Relative Colorimetric.

Yes, Perceptual can be used to ramp down the colors using the color management system. But one can also scale them back manually with selective adjustments to reign in the saturation only in the out of gamut areas. Several different ways to go... as long as the colors are there to be worked on in the first place.

I agree, Royce, but can be difficult in practice because these colors are precisely the ones that cannot be seen accurately on the display (because they lie out of gamut). So it's a bit of a crapshoot.

(On the other hand, it's a reasonable argument that leaving the scaling/desaturation/compression up to the Perceptual intent is also a bit of a crapshoot ... )

Eric -- true. Even the new wider gamut monitors appearing, which can display close to full Adobe RGB, don't help with this yet. How long before we can approximately see ProPhoto RGB, I wonder? Of course we know that just because we can't see something doesn't mean we can't work with it in a useful way.

Anyway, to talk about actual results rather than just theory, I picked a single image this morning and ran some comparison tests on it, using ProPhoto RGB and Adobe RGB (1998). Just for laughs I threw in an sRGB version as well. This is a single test case from my own work but I'm relatively confident I could find many more that show a difference, if I went looking.

The test image is a 3-exposure HDR file. I converted the original exposures in Lightroom with basic settings, exporting each image 3 times... once in PPRGB, once in aRGB and once in sRGB. Other than choosing a different output color space, I used identical conversion settings. I then used Photomatix Pro to merge to HDR and tone map using the Details Enhancer with moderate settings. Again I used identical settings to process each color space version of the file. Finally, I loaded the tone mapped files into CS2, placing all 3 color space versions of the file (each converted to PPRGB) on a layer of one image. I did some comparisons using the difference blending mode to show what changed. No finishing work was done on the test image, e.g. spot removal, levels, curves, noise, sharpening, etc. So what will show is simply the difference created by using one color space or another for the original RAW conversions.

Test image in sRGB: Test image in Adobe RGB (1998): Test image in ProPhoto RGB: None of the three test images really looks that different than the others (keeping in mind that I had to down-sample and convert everything to sRGB for posting here). The PPRGB version does appear a bit lighter since that color space uses a gamma curve of 1.8 instead of the 2.2 used by the other two color spaces. Now let's see what a CS2 layer comparison shows for differences between the files.

Test image in ProPhoto RGB vs. sRGB: Test image in ProPhoto RGB vs. Adobe RGB (1998): Both differences show quite a lot of change, most of it subtle. Unfortunately it's tough to see here; looking at the master file on screen it's easier to tell. In any event, the strongest difference is in reds and indicates that ProPhoto RGB is holding red channel detail that gets compressed or clipped by Adobe RGB, while sRGB of course clobbers even more of the color. Much of the subtler differences in the image comes from the difference in gamma curve. Since ProPhoto RGB uses a gamma of 1.8, it compresses shadows less and opens up highlights less than other profiles that use a gamma of 2.2. Whether you prefer one or the other is a bit of a taste issue, but the true difference in a 16-bit workflow is not a big deal because there is a lot of tonal resolution with either gamma. Personally, I have a mild preference for gamma of 1.8 since it compresses shadows less. If I want them compressed more, I'll do it myself in my post-processing.

How much of this difference can show up in a print? I checked the soft proofing condition in CS2 based on my Epson R2400 and my own custom profile for Hahnemuhle Fine Art Pearl paper, using relative colorimetric, black point compensation, and simulate paper color. Soft proofing the sRGB and Adobe RGB versions of the image and checking for gamut warnings, there are no out of gamut colors. This means pretty much all of those images' colors should make it through to print.

Here is the soft proofed gamut warning for ProPhoto RGB: This shows that the most intense reds in the clouds (marked by even stronger red, the default color CS2 uses for out of gamut pixels) will not print on the Epson 2400 with this profile. So I'd have to do a bit of work to bring those colors down a touch, unless I'm happy with what happens to them by the automated color space conversion during printing. Printing with relative colorimetric will clip the out of gamut reds to the most saturated red available on the printer, leaving everything else alone. Printing with perceptual will scale the reds a bit to fit the out of gamut ones while preserving some tonal differences between those most saturated reds and the other reds, at the cost of shifting more colors.

Hopefully this simple case illustrates that there can be a benefit to working with ProPhoto RGB. As I've said before, it's a "last few percent" kind of difference rather than an earth-shattering one. But for the most part in a 16-bit color managed workflow, including soft proofing to check prints before making them, use of ProPhoto RGB adds little or no overhead (unless you want to manually correct for out of gamut colors), and has no real downside that I can see. That's why I use it by default now. For anyone thinking about whether to use it or not, try checking some of your own images using this sort of approach and see what you think...

Excellent set of examples, Royce.

Two questions for you:

1. I'm perplexed by the third image (in PPRGB) being lighter than the other two. Since you performed a conversion from PPRGB to sRGB, the conversion itself should have taken the gamma differences into account, so there should be no difference in lightness. Why the difference here? Does Photomatix recognize color spaces and take the gamma differences into account?

2. Nearly completely off-topic, but since the name came up in your post: how do you like the Fine Art Pearl paper?

Interesting reading Royce, though I think the following quote from the Daalder paper should still be applicable:

"ProPhoto IS the right choice in some cases. But understand why you are using it and the consequences of your decision, and you will get better results."

And also this one if you are using a lab:

"Labs (at least in Australia) regard ProPhoto as the digital equivalent of Swahili. If you have a need to use ProPhoto, supply the final file to them as AdobeRGB. "

Also:

"Really, if your original capture does not contain tones out of the gamut of AdobeRGB, then there is no point whatsoever (and quite a few negatives) in using ProPhoto as your colour space unless you plan to artificially manipulate the saturation of your image to a considerable degree. "

and

"Photoshop's tools offer only one level of finesse regardless of the colour space we are using. ProPhoto is so wide that sometimes even the minimum 1% change in Photoshop is too much. 100% stretched out over such a vast space makes 1% a significant change. "

The main point is that some people may understand the issues and be prepared to experiment and push the envelope to get that last 1% in their print. If you don't understand the issues fully, like me you are probably better sticking to Adobe RGB until you see a need to switch over and are prepared to do the work needed to take advantage of the larger colour space.

madmanchan wrote:1. I'm perplexed by the third image (in PPRGB) being lighter than the other two. Since you performed a conversion from PPRGB to sRGB, the conversion itself should have taken the gamma differences into account, so there should be no difference in lightness. Why the difference here?

Converting from one profile to another preserves the visual appearance of the image as closely as possible, as I'm sure you know. So the reason the sRGB version of the PPRGB image looks lighter is because the original was lighter. I glossed over this in my notes. See next.

Does Photomatix recognize color spaces and take the gamma differences into account?

Sort of. All common HDR formats (Radiance RGBE [.hdr extension], OpenEXR [.exr], etc.) are linear and none of them support ICC profiles. To get image data linear as needed for HDR merging, Photomatix first does some stuff to decurve the gamma, etc. when you feed it TIFF's or JPEG's. It's supposed to use the gamma in effect for the tagged profile (if any), or you can tell it to attempt to calculate a response curve by analyzing all of the input files. You can't actually give it a gamma value directly.

If you merge to HDR and then tone map without closing the app, Photomatix tries to maintain sufficient in-memory state to generate the final output TIFF with the correct profile, including interpretation of the right gamma curve. However if you save the merged HDR to an HDR file, then load it back later to produce a tone mapped TIFF, the profile info is gone; there's currently nowhere to keep it within the HDR file itself. Photomatix may add it to XMP metadata or something in the future. But for now the TIFF's in this case come out untagged and you have to remember to assign the correct one to get things to look right.

Anyway, because of this stuff and possible different workflow by me from one sample to the next, there may be some goofy things going on... that's why I glossed over it in the previous post since it's not germane to gamut clipping. Possibly I should have looked for a non-HDR example to avoid this bit of confusion, or not mentioned the difference in lightness. You caught me out.

2. Nearly completely off-topic, but since the name came up in your post: how do you like the Fine Art Pearl paper?

I like it a lot. I've got some comments on it in another thread or two. Very nice stuff.

ChrisRoss wrote:Interesting reading Royce, though I think the following quote from the Daalder paper should still be applicable:

"ProPhoto IS the right choice in some cases. But understand why you are using it and the consequences of your decision, and you will get better results."

I agree with that 100%. The same is true for all of this CM stuff, however. How many people aren't aware that Adobe RGB & sRGB are clipping colors that were captured by their camera and could be printed by their printers, but are lost because they are out of gamut of their chosen working color space? That could be considered a negative for using sRGB and Adobe RGB by default for everything. Does it matter? For some images, yes... but only if you care about that little percentage of image quality.

And also this one if you are using a lab:

"Labs (at least in Australia) regard ProPhoto as the digital equivalent of Swahili. If you have a need to use ProPhoto, supply the final file to them as AdobeRGB. "

Actually I think it's even questionable advice to send Adobe RGB to a lab, in many cases. Generally, most that specify the color space ask for sRGB, so that's probably the only safe generic one to use for jobbed out printing.

Also:

"Really, if your original capture does not contain tones out of the gamut of AdobeRGB, then there is no point whatsoever (and quite a few negatives) in using ProPhoto as your colour space unless you plan to artificially manipulate the saturation of your image to a considerable degree. " [...]

I differ somewhat on this point. I don't agree that there are "quite a few negatives", with the caveat of using a 16-bit CM-enabled workflow. Of course if you're not using a 16-bit CM-enabled workflow, the chances of stumbling into ProPhoto RGB are extremely remote anyway. But as commented in my earlier notes, I feel most of Daalder's negatives are not really negatives, in the sense that you simply need to know how to use ProPhoto RGB. That's not a "problem", that's just knowing how to use the tool. The only real "problem" as such is that we can't accurately see the ProPhoto RGB gamut on our current gen monitors.

The main point is that some people may understand the issues and be prepared to experiment and push the envelope to get that last 1% in their print. If you don't understand the issues fully, like me you are probably better sticking to Adobe RGB until you see a need to switch over and are prepared to do the work needed to take advantage of the larger colour space.

Agreed. I advocate ProPhoto RGB, or indeed any other advanced CM work, mainly for folks who are more or less comfortable with CM from capture to print, and want that last little bit of image quality. Like I said in my first response, "Understand it, know the strengths & weaknesses, and then apply it appropriately if it does the job for you."

Thanks for the clarification on the gamma situation, Royce. I've also used Photomatix a few times, and I do recall the step about inferring the tone response curve as it builds the linear HDR image from the separate input files. Couldn't remember if you could manually enter a gamma value.