<p>If AP0 are the primaries used for rendering, then colours outside the sRGB space will work fine (assuming the colours are still within the AP0 space of course). If you allow users to pick colours in AP0 and then render with sRGB primaries, you will either end up with invalid colours (outside the zero to one range) or gamut clipping.</p>
<p>Assuming AP0 is used internally for rendering, then whether or not there will be data loss depends on the pipeline.</p>
<p>If a user picks a floating point colour outside the sRGB space and it is converted and stored as an integer value in sRGB (for example a PNG texture of whatever), there will be a loss of colour gamut but very little loss of precision. If it is stored as a floating point texture in sRGB (such as OpenEXR), texture values outside the gamut end up being negative or greater than one but that is actually fine as long as they end up in the zero to one space again for rendering when converted back to AP0.</p>
<p>If values are stored in integer format in AP0, you will keep the gamut but you lose precision. Because the AP0 gamut is larger than the sRGB gamut, you need more bits to store colour with the same degree of precision. When rendering in a wide gamut, I recommend using floating point for colours whenever possible. Using low dynamic range integer texture formats in sRGB is fine as <em>inputs</em> (normal JPG or PNG textures). Precision loss will be minimal.</p>
<p>Attached are two test renderings. Both of them use the same sRGB 8-bit integer image as input, but one is rendered with ACES primaries and the other with sRGB primaries. Both of them are saved in sRGB. They are a little bit different. This is because the ACES version has rounding errors from having a low precision integer image converted from sRGB to ACES and back, while the sRGB version has less conversion here and there. If floating point colours / textures are used, the precision loss is far less.</p>
<p>sRGB:
<a href="https://i.sstatic.net/Wedb1.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Wedb1.jpg" alt="sRGB version" /></a>
ACES:
<a href="https://i.sstatic.net/wTxPd.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/wTxPd.jpg" alt="ACES version" /></a></p>

CC BY-SA 4.0
2023-03-14T12:44:17.800Z
2023-03-14T12:44:17.800Z
SimonL
<p>I'd like to know the correct when of converting ACES AP0 color space into sRGB.  Let's say artists decide to pick colors outside of sRGB in AP0, will ACES handle this situation correctly, meaning no loss of detail in the image as it tries to map colors not found in sRGB into sRGB.</p>
<p>If anybody out there knows which file in their github page I need to look at I'd appreciate it.  Thanks!</p>

CC BY-SA 4.0
2023-04-13T13:11:15.733Z
It isn't clear if you are looking for a code solution or guidelines or some other solution, could you please clarify?
pmw1234
<color>
Converting ACES ap0 color space into srgb?
user19685
# Converting ACES ap0 color space into srgb?

(Asked by: username_0 on 2023-03-08)

I'd like to know the correct when of converting ACES AP0 color space into sRGB. Let's say artists decide to pick colors outside of sRGB in AP0, will ACES handle this situation correctly, meaning no loss of detail in the image as it tries to map colors not found in sRGB into sRGB.

If anybody out there knows which file in their github page I need to look at I'd appreciate it. Thanks!

**Tags:** color

> **Comments:**
> **username_1**: It isn't clear if you are looking for a code solution or guidelines or some other solution, could you please clarify?  

---

## 1 answers

### Answer by username_2 on 2023-03-14. Score: 0

If AP0 are the primaries used for rendering, then colours outside the sRGB space will work fine (assuming the colours are still within the AP0 space of course). If you allow users to pick colours in AP0 and then render with sRGB primaries, you will either end up with invalid colours (outside the zero to one range) or gamut clipping.

Assuming AP0 is used internally for rendering, then whether or not there will be data loss depends on the pipeline.

If a user picks a floating point colour outside the sRGB space and it is converted and stored as an integer value in sRGB (for example a PNG texture of whatever), there will be a loss of colour gamut but very little loss of precision. If it is stored as a floating point texture in sRGB (such as OpenEXR), texture values outside the gamut end up being negative or greater than one but that is actually fine as long as they end up in the zero to one space again for rendering when converted back to AP0.

If values are stored in integer format in AP0, you will keep the gamut but you lose precision. Because the AP0 gamut is larger than the sRGB gamut, you need more bits to store colour with the same degree of precision. When rendering in a wide gamut, I recommend using floating point for colours whenever possible. Using low dynamic range integer texture formats in sRGB is fine as *inputs* (normal JPG or PNG textures). Precision loss will be minimal.

Attached are two test renderings. Both of them use the same sRGB 8-bit integer image as input, but one is rendered with ACES primaries and the other with sRGB primaries. Both of them are saved in sRGB. They are a little bit different. This is because the ACES version has rounding errors from having a low precision integer image converted from sRGB to ACES and back, while the sRGB version has less conversion here and there. If floating point colours / textures are used, the precision loss is far less.

sRGB:
[![sRGB version](https://i.sstatic.net/Wedb1.jpg)](https://i.sstatic.net/Wedb1.jpg)
ACES:
[![ACES version](https://i.sstatic.net/wTxPd.jpg)](https://i.sstatic.net/wTxPd.jpg)


---

