Recently got a wide-gamut monitor, an Asus PA 32 DC.

As I understand it, in Standard mode, the panel is running at panel native. With color-managed applications in MacOS, images tagged with a color space (e.g. sRGB) will be portrayed in their correct color space (the OS will transform from tagged color space to the panel native color space). Great.

Now, many wide gamut monitors come with an "sRGB mode". This is also known as "sRGB emulation" or "sRGB clamp". What I cannot discover anywhere on the internet is how exactly the monitor implements this.

Let's say in standard mode we are inputting for a pixel the color (255, 0, 0) [8 bits for simplicity]. The color output on the monitor is a saturated, panel native red.

Let's now put the monitor into sRGB mode.

If we input the color (255, 0, 0), does the monitor output this as the closest value to sRGB (255, 0, 0) that the panel is capable of reproducing? Or does it simply clip any panel native color code that falls outside of the sRGB color space?

The answer to this would shed a lot of light on what exactly the best practices are for how to set the ICC profile when switching between these modes. It's unclear to me if I'm supposed to change the ICC profile when I put the monitor into a color space emulation mode.

In theory, when you use the ProArt calibration tool in a given color mode, it should also spit out an ICC profile for you to use for that mode, but as far as I can tell, Asus provides no indication that you should change the ICC profile.

P.S. Anyone know of any blog posts that talk more about the nitty gritty of hardware color emulation/clamp modes and how they are implemented?


1 Answer 1



Technically, you need to change the ICC profile in the OS when you change any display setting. Even brightness. That is, of course, if your ICC profile is that accurate and you pursue colour accuracy. This is why professional displays usually have an option to lock all controls once calibration/profiling is done.

I don't know specifically your Asus, but normally displays that offer sRGB emulation do convert input colours, just like a PC during colour proofing would. So an input (255,0,0) could produce a less saturated red; say (244,4,1) internally.

A few potential conversion problems could arise in this mode.

  • What base are we starting from, i.e. what are the native colours, how red is the native (255,0,0)? This is the standard problem of profiling, and it is still applicable.
    • Professional displays which have built-in LUTs and know their own profile (they come with specialised software which manipulates the display directly instead of asking the video card to do it) can translate precisely: from the measured native colours to the known/standard sRGB.
    • Consumer displays presumably base off the factory calibration. In this case sRGB mode would drift together with native colours over time. That's (sort of) OK because this would happen with the "normal" display, and that's what this mode is emulating.
  • What is the algorithm, the so called rendering intent? This is usually trivial because the target colour space (sRGB) is narrower and is wholly contained in the native space of a wide-gamut display. Most trickery of colour conversion happen when you need to do the opposite: cram a wider-gamut image to a narrower-gamut display/print. In our task, the display mainly needs to ensure that (255,0,0) produced a red that is as close as possible to the specified sRGB primary red, and similarly for the other primaries. Other colours can be linearly interpolated between these.
  • What is precision of conversion? Many consumer displays are entirely 8-bit (even if they accept 10-bit input), which inevitably means that the narrower sRGB space will have fewer steps of each colour, and thus fewer than 16M colours. But for such displays, it would happen no matter how you'd try to emulate sRGB. Better displays have higher-precision processing.

I'm not aware of any standard for the display to tell back to the OS that it changed some settings, including the sRGB emulation. So if you switched to this mode using display controls, you need to tell the OS this fact by changing the current ICC profile. Ideally, you would profile each mode and have an ICC file for each occasion (and update them regularly). Yes, this is somewhat burdensome and prone to errors, which can be disastrous if you forget to change the profile and start doing colour-critical work.

It would be technically possible for a display manufacturer to provide a software tool that would manipulate display settings from the computer. It could then simultaneously change the OS profile and the display mode. I don't know if Asus has something like this.

The typical use (esp. home use) of sRGB emulation mode is to work with non-colour-managed software/devices, particularly video. Which is usually a non-colour-critical task to begin with. If you have a piece of software that bypasses the OS colour management and spits out uncorrected image (and you know that!), then you don't need to change the OS settings. If the source for such software is the standard sRGB or a related Rec.709 (usually assumed), then trying to display it in native display colours will result in oversaturated (and slightly colour-shifted) image. In that case you can just switch the display to sRGB emulation. Then this image will show more or less correctly, while all the colour-managed applications will look desaturated.

Also, note that good displays keep settings specific for each input. If you have two sources connected to the display (say, a PC and a video player, or two PCs), one input can often be set to sRGB and another to native. This is convenient, but you need to manage all that and know what's happening in each moment. Using several modes is always a responsibility, just like working with multiple units is.

  • \$\begingroup\$ It's a shame you didn't use as your example the failed $125-million Mars Climate Orbiter because spacecraft engineers failed to convert from English to metric measurements when exchanging vital data before the craft was launched... \$\endgroup\$
    – Michael C
    Apr 13, 2023 at 19:04
  • \$\begingroup\$ Thank you for the thorough response! I unfortunately can't upvote your answer until I get slightly more reputation :( \$\endgroup\$
    – mrzk
    Apr 14, 2023 at 3:35

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.