What about digiKam? Do you have any ideas why could it be malfunctioning like this?
While the image still isn’t 100% match to what I see in darktable, it is much closer than unprofiled and I could see myself calling that good enough.
1 Like
I have an old Asus mini PC sitting in a drawer, unused. Perhaps I could try installing Linux on it an compare 
It’s not exactly high performance:
- i7-4510u (2C/4T)
- 8GB RAM
- GTX 750ti 2GB
… but it could be interesting
1 Like
absolutely lower limt
Not sure if this GPU would be used by darktable at all (driver support for this “old” GPU ?), 2GB too little.
Exactly…
Yep, not sure if this card is of any use.
No idea… Maybe it is applying a profile on top of the profile you selected in windows?
Maybe. But I don’t think it would look as if color management was disabled. It would be applied twice and likely too bright if I understand it correctly.
I’ll try and see…
This is what digiKam looks like for me. The images that pass the test are seemingly random? 
You are sure those images all have either a profile embedded or specified in the metadata?
And if both are present, they are compatible?
No program can be expected to guess the colour space used for the image correctly all the time; an RGB image in itself has no indication of the colour space used for the encoding…
So if your image is not encoded in the standard colour space for the file format, and the colour space used isn’t specified, what’s the poor program to do?
1 Like
I tested those images in XNView MP with different display profiles and they always passed. In digiKam… they sometimes pass, sometimes not - It almost looks random
Would you please download the test images and try them?
https://displaycal.net/icc-color-management-test/
The best way to test that the whole CM pipeline is working, are probably the stunt profiles here:
http://www.colorwiki.com/wiki/Stunt_Profiles
With those, there’s absolutely no question if they are used or not.
But it does sound like this is something that should be reported to the digiKam devs.
1 Like
Well, digiKam does not recognize those profiles. I’m sure that the folder is loaded and being read, but I can’t select the stunt profiles 
XNView, on the other hand, is able to use some (I tested three of them and the 45 degree shift doesn’t work, the other two do work:
Yeah, I guess it would be a good idea to report the issue…
I read somewhere that in dual monitor setup in Windows you need to set the mode to extend and not duplicate and drag your software to the other monitor to use the proper ICC for that monitor. That’s why Zi was asking …
Also for my profile those images behave differently when the preview uses scaling …in DT and in Xnview…so they might not be the best for assessing color management. In DT if I set HQR for the preview or bilinear for scaling the images pass…similarly if I keep away from bicubic and lanzcos in xnview again the scaling is not an issue. I know that you did try at 100 percent but the fact that you can see this maybe to differing degree depending on the profile and maybe the setting in the viewer suggest maybe trying different images
That’s how I set it
Well, I also test using the image I originally posted, I already know what it looks like with and without a color profile applied.
The thing is… XNView MP consistently fails applying my new Asus profiles, while having no problem with pretty much any other profile (like my Dell laptop profile).
DigiKam on the other hand struggles in a different way, but I was told it should be fixed soon.
Ya well I really dont’ know what to tell you…in summary what I see with my oem monitor profile, my displaycal profile and my calibrite profile using the device software is as follows…
DT which I know is color managed… images are fine when displayed at 100 200 or 400 etc…only scaling triggers that message to come up when not at a multiple of 1:1…
If I turn on the high quality preview…the image are fine and pass at all zoom levels with all scaling models. Also if I use bilinear for pixel scaling the image visibly degrades during scrolling but the message is not triggered with the default preview. Using bicubic or lanzcos with HQR off will trigger the message with any scaling…
So I know that DT is color managed. The behavior is the same with all 3 profiles that I have for my monitor from 3 sources and so in this case the test image is prone to scaling artifacts triggering that red message as far as I am concerned…
For me roughly the same behaviour in XNview…All images pass at 100%…one minor difference from DT is that at 200 or 400 they fail if scaling of the preview is other than none or bilinear… If set to none the image looks pristine while zooming and passes at all zoom levels. If I use bilinear the images pass but the test is visibly degraded by scaling artifacts as you zoom in and out… This again is the same for all 3 of the profiles that I tested …
So this is what I see. If you see something different yet again well I am really at a loss… So for me both DT and Xnview behave the same with these particular test images and the red message triggered to indicate a fail of CM is for me a function of the scaling settings for the preview in each of the software programs…
Maybe download some of those icc files that @Donatzsky mentioned and test them…
Me too, Todd, me too
I’ll try them later and check in again.
1 Like
Alright. Time to write an update…
I have installed Ubuntu Studio 24.04 with X11 on my Asus GR8, specs here:
And oh boy 
No problems whatsoever as far as color management is concerned. XNView MP, digiKam and darktable all work just as desired.
Nvidia 750Ti (…reported as 860M for some reason? Who knows what’s inside, but it’s almost the same GPU, so whatever…) works out of the box apparently
I’ll be honest I was not expecting that… well, at least System Monitoring Center reports Nvidia activity during darktable exports, so…
I did a very scientific comparison of performance to my Dell laptop running an i7-11370H (4C/8T) + Iris Xe 96 by pressing CTRL+E at the same time on both machines and … the Asus is noticeably faster 
Where do I find the log file after running -d perf tho?
Nvm, it is in the terminal window 
So far it is only installed on the HDD that the PC came with, but since it works very well, I might shove in an SSD and reinstall, since I haven’t done much to the system beyond some basic testing…
1 Like
Apparently it works out of the box on Ubuntu Studio 24.04… 2GB VRAM causes tiling, but it seems to be the fastest system I have ever used for darktable, anyways.
1 Like
Yes, a discrete GPU will almost always be better than not having one. 
now if you get one with enough vram that it doesn’t tile, it’ll be even faster.
3 Likes
Small update… I tried showPhoto on Windows and it doesn’t seem to have the same color management bug as digiKam, which is kind of weird? Like those two were installed together, but apparently they are different enough.
It’s considerably slower to open images than XNView MP, but for the time being (and likely moving my photo work to Linux), it’s great to know that I have a reliable way of viewing my photos on Windows.
1 Like
So, guys… the final update.
The problem was in the profile name – XNView MP on Windows couldn’t use the profile if it had upper index character in it. Quoting the XNView forum:
Renaming profile from …125cdm²… to …125cdm2… removes the problem.
So uhh this feels a bit embarrasing … but hey, it’s all good now! Thanks to everyone trying to help.
And to address this, yes, GPU operations are indeed much faster on GTX 750Ti than on Iris Xe.
But the thing is, the CPU is much slower (dual core i7 that boosts only to 3.1 GHz, which is close to the base clock of my laptop’s quad core i7) and things like masks, tone equalizer, etc. make DT feel significantly slower, so I might stick to Windows till I get a beefier PC. I looked at some second-hand PCs and there are really decent ones at around 700€.
1 Like