Choosing a working colour space for photography: sRGB, AdobeRGB, Wide Gamut RGB or ProPhoto RGB

There are four prominent colour spaces in wide use these days for photo processing:

• sRGB (1996; HP, Microsoft). This is now an industry wide standard for monitors, printers and the web: IEC 61966-2-1:1999.
• AdobeRGB (1998; Adobe). This is now industry standard IEC 61966-2-5:1999 and is sometimes called opRGB. Inventor: Thomas Knoll.
• Wide Gamut RGB aka Adobe Wide Gamut RGB (2010; Adobe)
• ProPhoto RGB (2011; Kodak). Aka Reference Output Medium Metric RGB or ISO 22028-2:2013. ProPhoto RGB was Kodak Corportation’s last contribution to photography before bankruptcy. Inventor: Dr. Geoff Wolfe.

Almost all Adobe users are familiar with the confusing and prominent dialogues about colour space when setting up Photoshop or opening up images.

These dialogues are important but can be streamlined out of existence¹ as DxO does in PhotoLab which is a RAW development tool (i.e. all the incoming images should have been generated by a camera sensor and not synthetic file creawtion). In PhotoLab 4 one simply opens one’s RAW file. The image is converted to AdobeRGB for arithmetic calculations, while the result is displayed on your screen in your monitor profile. In most cases, your default monitor profile should be a version of sRGB.

I highly recommend doing your own screen calibration though. Default monitor profiles:

1. go off over time as the monitor ages
2. are not that accurate in many cases to start with (although more and more companies like BenQ and HP are creating individual profiles of panels before they leave the factory)
3. are often not true sRGB as straight sRGB does not pop enough when in the store. Online and spec buying has sobered up many of the monitor companies whose default profiles are no longer over-saturated.

When I profile my monitors with an X-Rite i1 and DisplayCal to sRGB, the results are much different and more natural with most of the monitors than Apple’s default profiles for those monitors.

Should a photographer worry about what colour space his or her RAW development tool calculates colour? The short answer is no, as long as the working colour space is not sRGB which does significantly constrain calculations with potential visible results. On the other hand, evaluating the changes on sRGB monitor is not really an issue as one can see the results of those calculations very well in sRGB. Moreover, in most cases, the final product of a photographer’s labour over his or her photos will be shown in sRGB. Most monitors default to sRGB, the internet defaults to sRGB. Woe betide a photographer who posted his or her images before 2020 with any other colour profile. Recent versions of Chromium, Safari, Opera, Firefox and Chrome do support colour profiles according to my testing today. Firefox 75 from April 2020 which I happen to have here did not.

This means a working colour space for a photo application of any of AdobeRGB, Wide Gamut RGB or ProPhoto RGB would be fine. The profiles with which RAW photos come in to a top tier RAW development application does not matter as Adobe Lightroom, Capture One and DxO PhotoLab all create their own colour profiles specific to each camera.² What matters is the colour space in which the calculation is done. It should be as wide as possible but the conversion between colour spaces must be arithmetically perfect. If there are any bugs in conversion, they will affect your image more than which RGB the working space is.

Since the creation of AdobeRGB in 1998, there have been loud gurus like Scott Kelby running around calling sRGB StupidRGB and promoting first AdobeRGB and then ProPhoto RGB. Many tech gurus are just cheerleaders to encourage punters to constantly update whatever cameras, monitors, OS, software they currently work with. More spend in the sector equals more money in the sector and bigger endorsements for tech gurus or more affiliate revenue.

Pointless fussing over colour space and invisible colours is pretty much The Emperor’s New Clothes brought to life for a modern age. Intermediate photographers are easily sucked into believing mixing colour spaces would make a significant difference to their photography. The sexy names of those alternative colour spaces, AdobeRGB and ProPhoto RGB, make for a charming mystique.

Chasing invisible colours can afflict years of their creative lives, cost them many thousands of euros and leave them with worse images (the toll of constant conversion and mixed colour spaces). I’d hate to see that happen to more victims or to see PhotoLab kneecapped to chase unicorns. To effectively process wide gamut colours one must be able to see those colours.

I vividly recall how Kelby’s cajoling about colour spaces created horrific image compatibility issues for me between Apple’s Aperture, Adobe Lightroom and the web. It was almost impossible to reliably post photos to the web or have them show the same colours in Aperture, Lightroom, Photoshop and Preview.³ Had I stuck to sRGB as my output format, my images would have consistently looked good on the web and across all my applications. These colour space conflicts between Adobe software and other applications are still bedeviling Capture One users in 2020.

Happily, PhotoLab makes it very easy to pursue a pure workflow from acquisition in either sRGB or AdobeRGB. As my monitors calibrate to 100% sRGB and just 80% AdobeRGB (and due to those bad experiences in the past with mixing colour spaces), I stick to sRGB. The workflow is even purer with AdobeRGB. Acquisition, RAW development, output can all be in AdobeRGB. Remember, specifying AdobeRGB in your camera as the acquisition colour space does not result in capturing any more data as the RAW data is the same and PhotoLab and other good RAW development tools ignore the attached profile when handling that RAW data and convert the RAW data with their own profile for that specific camera. I.e. when you choose AdobeRGB in your camera it does make a difference for jpegs but does not change RAW files.

Some PhotoLab users clamour for soft-proofing in their RAW development tool. CaptureOne and Lightroom both include soft-proofing. I don’t think it’s necessary for a RAW development tool to include soft-proofing as soft-proofing even when built-in is complicated and requires creating additional files.

In both CaptureOne and Lightroom, it’s necessary to make two copies of one’s image. The first copy, let’s call it the Master would be for screen and web. When this version is prepared and finalised the image should be duplicated and the second copy must be corrected for print or other purposes. Each printer and paper would require its own version of an image. The advantage for built-in soft proofing is that the preparation for print would be with the same tools one uses in RAW development and starting from the RAW image rather than a fully rendered tiff. On the other hand, one could get very used to preparing an image for print with a dedicated tool like Photoshop or Affinity Photo, both of which include excellent tools for adjustment. Soft-proofing for print should not involve huge shifts of colour or light – it’s just tweaking which should not compromise image quality when starting from 16-bit TIFF.

Here’s what tilltheendofeternity wrote about his own RAW and print workflow in PhotoLab:

For me PL2 is a start point as it produces the best RAW development of any app. After that I send the image to either NIK plugins, Luminar or Affinity for further work

I have a hardware calibrated monitor (100% sRGB, 98% Adobe) and the print company is use for prints specify all files to be sRGB. I soft proof using Affinity and the icc profiles supplied by the print company for the papers they use. So far, it all works fine as a process.

I would much rather have luminosity masking as that has the potential to impact every image that I work on. Soft proofing only matters when I physically print which isn’t that often.

Affinity Photo is just €50/$50 and it’s cross-platform. Anyone who wants soft proofing for printing literally can acquire such a tool (along with a first rate bitmap editor to replace Photoshop including HDR and panorama tools) for less than the price of an update.

There is a persuasive argument to be made on paper that the working colour space for PhotoLab should be ProPhoto RGB:

When you post-process a photo, you have to choose which working space you’re in. This is the color space your post-processing software restricts you to use; no edit you make can lead to a color found outside your chosen working space. In general, it is ideal that your working space is ProPhoto RGB when you edit a RAW photo. That’s because RAW photos often contain colors outside of both sRGB and Adobe RGB color spaces, especially in high-saturation shadow regions.

Two years ago DxO developer Wolfgang made a call for some real world example images where the AdobeRGB working colour space affected final output:

Indeed, it is currently impossible to get colors out of PhotoLab that are not contained in AdobeRGB. We are aware that this is a limitation, but frankly, there are not many colors in nature that do not fit inside AdobeRGB. If you encounter images that contain colors outside AdobeRGB, please share them so that we can raise the priority of this topic.

There was relative silence on this topic (one post referenced a theoretical gamut chart with no images). Anyone who wishes to martial support for changing the handling of colour spaces in PhotoLab come with some real world images which suffered from being processed in AdobeRGB and then printed. Such examples would require downloadable printable files please as screen tests show invisible colours when converted to working monitor space.

Wolfgang made a case against exporting in ProPhoto RGB:

Technically, you can choose any ICC color profile for export, including ProPhotoRGB. But as you say, doing so does not make much sense. The ProPhotoRGB export will only contain colors that already existed in AdobeRGB. – I use this ICC color profile feature when preparing images for a printing service that provides ICC profiles (e.g. Picto). – For post-processing the image in a 3rd party image editor (e.g. Affinity Photo, Adobe Photoshop), I recommend to stick to AdobeRGB as it contains all information that is available in PhotoLab and avoids additional conversions.

Of course if PhotoLab’s working space were ProPhoto RGB, that would be the right space in which to export. Switching the working colour space to ProPhoto RGB would mean master photos should never be exported as jpegs. Jpeg format only supports 8-bit colour while ProPhoto RGB only supports 16-bit colour. This means all masters should be exported in TIFF or PSD format. This is a lot of extra space. A single TIFF from one of my D850 files results in a 272 MB file. The same image as a jpeg is 53 MB. Of course these file sizes don’t matter for an art photographer but would quickly create storage issues for wedding, event and sport photographers.

Colour spaces are an arms race:

• sRGB is 35.9% of visible CIELAB
• AdobeRGB is 52.1% of visible CIELAB
• Wide-gamut Adobe RGB is 77.6% of visible CIELAB
• ProPhoto RGB (Kodak) is 90% of visible CIELAB

If DxO were to change their working colour space every time an improved colour space became fashionable, there would be far more issues with correct colour processing (gamut mismatches are awful) and no real world improvement. It’s possible the world has caught up to the point (advanced colour spaces are highly dependent on monitors on which to see that space and make the adjustments and pro printers able to print those colours), it would make sense to make the working space in PhotoLab ProPhoto RGB.

For simplicity’s sake, the switch to ProPhoto RGB should be an absolute one when it comes. Allowing users to choose working colour space is pointless complexitiy. Changing working colour space does have serious consequences. Previous conversions would look different. There are small differences in rendering between PhotoLab 2, 3 and 4 already so proofing and readjusting old images in current versions of PhotoLab is already a necessity.

If you are using another RAW development application than PhotoLab, happily there aren’t many decisions to be made. The working colour space is also chosen for you.

• Adobe Lightroom uses a working colour space called MelissaRGB which includes ProPhoto RGB primaries (thus color gamut) and a linear gamma 1.0 TRC. Previewing is done with Adobe RGB (1998)for all modules except Develop.
• CaptureOne claims to process in a given camera’s native colour space. I have my doubts that it’s not really ProPhoto RGB with a conversion as that would make the claim more or less true as ProPhoto RGB includes 100% of visible colours. Capture One still have to convert back out to the monitor and sRGB. Doing all that conversion without a core colour space would be challenging. Capture One admits that for local color edits and conversion to black&white they must use a standard colour space.⁴

Until then, if you can’t see it, you can’t correct it. DxO PhotoLab makes it possible to more reliably create more great images by making good choices for photographers and allowing us to get on with creation and spend less time squinting at colour space and gamma charts `and more time staring at our images.⁵

For those working with images in a video, it’s best to export them in sRGB as most editors will expect sRGB and will adjust the image for the working colour space of the edit. Reliably seeing the correct output for video editing requires an external monitor running off a dedicated broadcast video card on Apple at least. But that’s a tale for another day.

Notes