I think it worked. I converted the photo to my screen’s profile and saved the file. Thank you!
I though that the colors should become less saturated but they look right in GIMP because GIMP is color managed.
You’re making me want to go get a large-gamut monitor so I can try some of this stuff. 
Geesh, there’s an emoji for just about anything…
Glad it worked!
2 Likes
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.