I think that would depend on the usual suspects: the ICC / LUT profiles, rendering intent and black point compensation. It looks like sRGB is completely inside of AdobeRGB, so gamut shouldn’t be an issue. Of course, correct me if I am wrong.
Source: File:CIExy1931 AdobeRGB vs sRGB.png - Wikimedia Commons
If the image is already crushed to sRGB, what I want to figure out is how gamut to AdobeRGB could be extrapolated in a conversion. When you upscale resize an image, pixels are ‘made up’ to fill the gaps between the original pixels; I wonder if the same sort of extrapolation is going on in a conversion’s rendering intent.
Consider the xy chromaticity diagram, as shown by @afre. For an image within sRGB space, with no negative values, all pixels are within the sRGB triangle. When converting to AdobeRGB we want chromaticity to be unchanged because the screen is (we assume) AdobeRGB. So the resulting image will still be entirely inside the sRGB triangle. But the pixel values will have changed, pushed towards the white point, as if the colours were desaturated. But they have not actually desaturated, because “full saturation” is now with respect to the larger gamut.
Of course, an alternative conversion would mean a pixel that was 80% saturated in sRGB becomes 80% saturated in AdobeRGB. That would change the chromaticity, which @betazoid wants to avoid.
2 Likes
I would add that any crushing or clipping would not be recoverable, and I am unaware of any processing apps that are capable of reversing the negative out-of-gamut values. Therefore, I would suggest that @betazoid edits for the target gamut rather than for sRGB followed by a conversion. Moreover, I have doubts that converting an image to the screen profile is advisable.
well I just did this with this wallpaper. When I saved this photo in sRGB some months ago I did not know that I would buy a new screen. Besides I needed it to be in sRGB because I uploaded is somewhere where it needs to be in sRGB.
Brand & model of the new monitor?
BenQ SW240
OK. I just checked its data sheet. Sounds like a capable monitor.
Re colour gamuts: the monitor promises
- 99% Adobe RGB
(which is smaller than Adobe Wide gamut) - 100% sRGB
- 100% Rec709
- 95% DCI-P3
and if you work with, say, RawTherapee, you can of course pick any of those as output profile.
Did your model come with a shading hood? Using a shading hood can be very effective.
MfG
Claes in Lund, Schweden
The screen’s native color space is about 120% AdobeRGB (volume, not coverage of AdobeRGB, coverage is 97-98%), that is what I usually use. I can really see the difference between the AdobeRGB mode and the native mode. However, native mode is exclusively available with hardware calibration and the Palette Master Elements software only works on Windows and Mac.
The scree does not come with a shading hood. But you can buy one.
Without hardware calibration the color space is about 95-96% AdobeRGB and sRGB.
Ah, if the hood costs extra: no need to buy one.
You can easily make one yourself, using a part of
a cardboard box 
It is far more interesting to use your money on a ColorMunki, or Spyder, or something similar (just check what DisplayGui and/or Argyll recognize).
my measurements were done with a Spyder5 and Displaycal
I’ve written software (Putting OOG back in the box, and other software not yet published) that happily accepts sRGB (or other) values outside the range 0 to 100%, and can manipulate it in various ways to push it back inside gamut.
But if values have already been crushed to 0 or clipped to 100%, recovering that lost data is more difficult: we need to guess what the OOG values were before we can push them inside gamut.
I think I understand the original issue: If I have a photo in a color space that is significantly different form my screen’s color space I always need to convert it to my screen’s profile or a profile that is similar, if I want to see the correct colors without color management. Am I correct?
Bear-of-little-brain here would say, Yes.
If I have all this correct, that’s what the rendering intents control. And, it would appear that ‘relative colorimetric’ compels the scalng we’re discussing. ‘perceptual’ in a sRGB->AdobeRGB transform would just do nothing, as by definition all the original colors are still in the destination space’s gamut.
Yes.
If your display software has no colour management, then it ignores whatever profile the image might contain, and will pass the pixel values unchanged to the hardware (or next bit of software in the chain).
So the way to get correct colours is to convert your image to the correct profile for your hardware. You need to convert to the profile (which changes pixel values and embeds the profile), not assign the profile (which merely embeds the profile without changing pixel values).
The procedure I used to get the Windows Desktop to display normal colours on a wide gamut monitor:
- Convert the image to your monitor ICC/ICM profile
- Assign sRGB to the image.
It’s exactly the reverse of the procedure to get Windows screenshots to display properly everywhere else beside your monitor – take the screenshot file to an editor which allows first assigning your monitor profile to the file, and then converting it to sRGB.
I agree you first need to convert the image to the display profile. But when you do that, the Windows Desktop/wallpaper looks oversaturated when using such a photo. And it is oversaturated because the Desktop app doesn’t respect the display profile – instead it erroneously assumes that every monitor is a perfect sRGB monitor. So to trick it, after converting the image to the display profile, you need to assign sRGB to the image. The photo will look desaturated in any properly colour-managed program, but will look correctly saturated as the Windows wallpaper/desktop image.
The default Windows screenshot tool does the opposite thing – it grabs the image of your desktop but erroneously assumes your monitor is in sRGB mode (there are very few monitors which can be called true sRGB monitors – usually they are wide gamut monitors using their sRGB emulation mode). The resulting image has an incorrect colour profile tag assigned to it when you use any other monitor than a perfect sRGB display. So you first need to assign your display profile to the screenshot, and then convert it to sRGB, since most screenshots are meant to be shared online and potentially viewed with non-colour-managed programs.
I suggest the OP should try the convert/assign route with his wallpaper image on a wide gamut monitor, and report back.
Interestingly enough, there are several applications which seem colour-managed when doing only the first part of a simple CM test, e.g. the DisplayCal CM test. The first test checks if the program reads the embedded profile.
When you set this red (tagged grey) square from that test as your Windows wallpaper, you will see the grey square on your desktop, which means that the Windows Desktop app respects the embedded profile. But if do the second test (the monitor profile test) and you install one of the display test profiles from the DisplayCal page and set it as you monitor profile, the Windows Desktop app will fail the test (showing a strong colour cast).
Other applications which pass the first test but fail the second test are: Windows Photos (the default Win10 photo viewer!), Internet Explorer, Edge, FastStone Image Viewer (!). All of them show oversaturated colours when viewed on a wide gamut monitor, and shouldn’t be used on any monitor to evaluate colours in your photos.
Some colour-managed applications don’t like LUT-type display profiles, e.g. Windows Photo Viewer, Firefox, FastPictureViewer. When using DisplayCal to calibrate your monitor you can create a single curve matrix profile and feed it to those applications to make them work properly.
Programs like darktable, RawTherapee, XnViewMP, IrfanView, etc. can all be colour-managed if you set them up correctly, so they should pass both tests. However, darktable seems to dislike the embedded LUT profiles as well (possibly a bug).