I have RAW images and export them from Lightroom using the default sRGB colorspace and haven't ever had a need to change this for display on websites.

However, I develop websites and apps that run on macOS and iOS devices, and these newer models have displays that support the P3 color space. Safari for example will render an image tagged with P3 in fill wide gamut, and treat any untagged images as sRGB.

If accurate color rendering is important, and to take advantage of the extra colors that P3 enabled displays can render on these new devices, does the community think it's worth exporting images as P3 vs sRGB?

  • 1
    \$\begingroup\$ What makes you believe that that most visitors to your website have both an apple device that supports this colour space AND have that display calibrated for whatever conditions they're in? \$\endgroup\$ Commented Nov 16, 2016 at 0:59

4 Answers 4


Before you worry about whether you should export as P3, does your camera even export in P3? Most cameras today still only export in either sRGB or Adobe RGB.

However, if you're using an iPhone for capture (or any other camera that supports P3), then your images support P3. When a P3 image is rendered on an sRGB screen, software that works correctly will find the nearest renderable color for each pixel and display that. Is that good enough for your uses? Software that doesn't render correctly will simply interpret the values as sRGB and it will look different (maybe good, maybe bad, depending on what's in it and your personal tastes).

If you're thinking mainly about web pages, there are techniques you can use to detect the browser in use, and information about the display. (I'm not sure whether you can detect whether a display supports P3 or not from, say, Javascript.) You could show sRGB versions to people on browsers you know don't properly deal with color profiles, and show P3 to people on browsers which do handle it or at least handle color profiles correctly. It all depends on how important color fidelity is to your website.

For apps, it should be easier since you're running on the device and can query it directly. Your individual use case will determine whether it's important or not. I work on software where we have determined that it is important, and we now support P3. Know this - it is not easy to get correct and your users will likely misuse such support. Having good documentation and defaulting it to off is probably your best bet at the moment. But it is certainly possible and software is starting to support it. Now is a good time to at least start thinking about it.

  • \$\begingroup\$ Awesome thanks for the detailed answer! In the end I think P3 support is valuable (where hardware supports it) and is the future. So I'm going to ensure that the software I write doesn't flatten P3 images to sRGB when they get processed (such as making thumbnails). Already using <picture> elements and there is a color-gamut media query that can be used to serve P3 images. My use case is a CMS publishing tool, so seeing the extra colors would be a real bonus. Thanks again for the input. \$\endgroup\$
    – user32020
    Commented Nov 15, 2016 at 13:24
  • 5
    \$\begingroup\$ Cameras don't capture in either sRGB or AdobeRGB. They just tag resulting jpegs that way. Upon editing a raw file, one can choose whatever color space. \$\endgroup\$
    – D. Jurcau
    Commented Nov 15, 2016 at 15:34
  • \$\begingroup\$ As pointed out by @D.Jurcau cameras don't capture sRGB, AdobeRGB, or P3. They have their own spectral sensitivities which dictate their response to light and those values can be encoded relative to a set of display or intermediate encoding primaries. See photo.stackexchange.com/questions/64049/… \$\endgroup\$
    – agf1997
    Commented Nov 15, 2016 at 20:02
  • \$\begingroup\$ Fair enough - I've corrected the statement about sensors.. As far as I know, it would take at least a firmware update to get most cameras to export in P3, so probably not going to happen for most cameras that people have already purchased. But I agree that it's the future. (And probably, eventually, Rec. 2020 and maybe even ProPhoto someday.) \$\endgroup\$ Commented Nov 15, 2016 at 22:30
  • 2
    \$\begingroup\$ @user1118321 No firmware update is needed. The op was asking about RAW files, lightroom, and custom color pipelines. Lightroom can export P3 encoded files. Go to Export->File Settings->Color Space. P3 is in the default list but any space represented with an ICC profile can be used. If he's building a RAW processing pipeline the pipeline would look like rawRGB -> XYZ -> CAT -> P3 RGB. It's worth noting that in cinema P3 RGB usually uses the DCI whitepoint (x=.314 y=.351) and gamma 2.6 but Apple using P3 primaries with D65 the D65 whitepoint. I'm not sure what gamma they are using. \$\endgroup\$
    – agf1997
    Commented Nov 16, 2016 at 2:41

Images exported from lightroom are usually encoded relative to a particular displays characteristics and viewing environment (primaries, EOTF, surround, etc.).

sRGB is a specification of a "typical" desktop computer monitor. P3 is an encoding used in digital digital cinema and has the ability to encode more saturated colors than can be encoded in sRGB.

RAW images can easily be encoded as sRGB or P3. The key, however, is that the images should be encoded based on the capabilities of the display on which you plan to view those images. If you encode the image as P3 but then view those images of a sRGB monitor, they will look incorrect. And vise versa, if you encode as sRGB and view the images of a P3 monitor, they will also look incorrect.

Color management can help reconcile mismatches. For instance, if you send a P3 encoded images to an sRGB display, it's tagged correctly, and there's a color management system in place, the images will be converted to sRGB before being displayed. However, in that case the display is physically incapable of displaying the most saturated colors specified by the P3 encoding. The color management system will remap that color to a color within the sRGB gamut. If you send a sRGB image to a P3 display, it's tagged correctly, and there's a color management system in place, the image will look exactly as it would have on an sRGB display, but won't take advantage of the display's larger color gamut.

In many software systems (including many printer drivers), if the images aren't tagged, or there is no color management, the images will likely be assumed to be sRGB.

Long story short, the choice of how you encoding should be made based on the intended usage. If you know the display it will be viewed is a P3 display, encode as P3. If it is sRGB, encode as sRGB. When in doubt, sRGB is probably safer.



If in sRGB, your image can be rendered with the saturation & lightness you like and there is no clipping then you will not derive any benefit from a larger color space.

If in sRGB You Find
Your Colors Are Not Clipping,
Then the sRGB Space Is
What You Should Be Shipping


Remember that a larger colorspace does NOT mean "more colors" - a larger colorspace means the colors are farther apart. If you don;t have enough bits, then your delta E errors can become visible artifacts.

The "number" of colors available to an image is defined by the bit depth. An 8 bit-per-color-channel (bpc) image is 8x8x8:

  • An 8bpc image can encode a maximum of 16,777,216 colors.
  • A 10bpc image can encode 1,073,741,824
  • A 12bpc image can encode 68,719,476,736
  • A 16bpc image can encode 281,474,976,710,6561,2

While 16,777,216 may seem like a lot, also remember that an 8 bit image can only show 256 levels of greyscale which is far short of what the human eye can perceive. In fact, if the image were encoded linearly, 8bpc would be far from enough and visible banding artifacts would be plainly visible — the use of gamma encoding prevents this by weighting data toward darker values to exploit the non-linear nature of human vision.

To be honest, P3 and AdobeRGB are in some ways too big of a color space for an 8-bit container even if using a gamma TRC. If your images are not at least 10 bit, best practice is to stick to the color space that works best for 8 bit: sRGB.


1: A Dough Bee Photoshop "16 bit" mode is actually 15 bits, for 1,099,511,627,776 — be aware that if you open a 16bpc image from another app, APS will truncate it to 15 bit.
2: 16bit half-float EXRs have 1024 levels per stop, with 18½ stops above 18% and 11½ stops below using the normalized values for 28,991,029,248,000 (plus an additional 10 stops at lower precision).


Editing on P3 will be only reliable once most people will be using P3 capable devices.

Till then you cannot really tell how P3 media will be mapped on an sRGB device.

The shift to P3 needs to happen first on the hardware, then on the content.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.