I know. But it is important to see if the rendering is correct, and if not, how/why it is wrong. Such a test profile only tells you if there is any color management at all.
Probably one could also do tests with special test images.
Ya for sure I was meaning as a gross check just to confirm that when you used a profile that the app or os used it⌠then you could go on to test profiles and verify correct colors and colorspace conversions
Well I think itâs a real problem that XnView is closed source and we have no idea what it is actually doing. Anyway, color management does not work if you donât set a screen profile inside XnView. If there is no profile, something is definitely going on, because there is a difference between sRGB and AdobeRGB, but the colors are not correct. At the same time, the same two images look exactly identical in Gwenview.
And, I want to stress one more thing: there is absolutely no documentation about this. There is no changelog for XnViewMP version 1.7. If I had not tested this, nobody would know about it. This just kind of secretly happened.
I use that viewer but on Windows⌠I usually specify the icc in any program that lets me and never trust the use system option⌠even though I set it in Win CM settings which are always a bit weird to trust with the wcs settings and all.
Well, closed source has definitely won this race.
xnview always was a great program. already loved it on windows.
Ok, I think this is a KDE Plasma thing, because the colors are also correct in darktable, if a profile is set inside darktable, if Plasma color management is active. But XnView is native, it needs no XWayland, whereas darktable does.
Edit: and color management also works with RawTherapee, which is Wayland native.
Youâve been able to load ICC profiles on Wayland for a number of months, and while that is nice, it is not a complete color management solution. Its part of it though.
Yes, but until now, there was no (visible) difference between AdobeRGB and sRGB on Wayland, now there is. Everything was shown as sRGB.
And if you set a profile in KDE 6.0 + in the client, you had kind of a double color management.
Itâs a terrible site, but somewhere on there you can find various test profiles:
Houz has also made some test profiles that you can find here:
this actually works on sway-git too
Although sway seems to load a calibration curve at start which gives the entire screen a blue cast or so, and makes it a bit darker, even though the profile does not include a calibration curve afaik.
But everything that is color managed (uses profiling data), i.e. at least image files that consist of pixels and contain info about the color space, seem to look more or less ok.
Ok, I donât know what I did yesterday. I was probably too tired. I think there is still a double color management. I did more tests today.
Sorry guys, I think I was wrong.
Apparently in XnView, the two photos look different if color management is completely off, i.e. if XnView ignores the embedded profile.
And the difference is also visible in Firefox if color management mode is set to 2, but that is wrong.
I donât know, I am confused.
Yes. Youâll see a difference between setting different color profiles in the app, but the result is incorrect.
Another thread on mastodon which gives some clarity and also highlights that HDr is more priority than colour profiling workflow that we need.
But it seems it will eventually happen.
Latest comment on the CM&HDR protocol by Xaver/Zamundaaa looking to define requirements for merging the protocol and overview of current status: Draft: staging: add color management protocol (!14) ¡ Merge requests ¡ wayland / wayland-protocols ¡ GitLab
Seems KDE has implemented most aspects of the protocol, but there needs to be a client implementation for some of the features.
I experimented with profiling in the Wayland session again, and it turned out to not be that complicated. I wrote up a little something to explain it: How to: Profile your display in the Plasma Wayland session | Xaverâs blog
Now weâre just missing whitepoint adjustment and automation for the manual parts of the process
Thank you very much for this step by step @Zamundaaa I will test it in neon live iso.
White level and white point should be turned on with displays where you can set this in the on screen display, i.e. with the monitor buttons.
Setting the correct white level (80-120 cd) is particularly important and must never be turned off.
This definitely works on kde plasma 6.
However, it is also possible to set the white level with the help of displaycal before the actual profiling.
Well thatâs hardly surprising, since HDR is (can be) used in video codecs. The vast majority of Wayland users are far more likely to encounter HDR video than they are to encounter (and even less likely, notice/appreciate) color-profile-managed still images.
Nearly every image is color managed, having an embedded color profile, its just that 99% of them are sRGB or the application rendering the image assumes and renders sRGB.
There are certainly way more color managed, still images on the internet than not. Whether they were produced in a color managed environment and a true to what the author intended is another thing completely.