P3 Color Pallet vs sRGB

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.

CLIPPING

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

---

THINK SMALL

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,656^1,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.

FOOTNOTES:

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.