- This topic has 7 replies, 2 voices, and was last updated 7 years, 6 months ago by
.
-
Posts
-
Hi!
As the title suggests, I am having a bit of a problem with the profile loader. I have noticed this happening before, but it seemed rare enough that I didn’t care all that much. Now it seems to have become a little more “sticky” for me.
What is happening is this: I have a multi-monitor setup (running on Windows 10, if that matters), and in some cases the loader will not apply the selected profile on some of the displays (or it will fail to reset the video gamma table, depending on the option chosen – basically the display will remain “stuck” in whichever mode it was). The pop-up notification will report everything correctly: profile associations will be in order for all displays or it will claim to have applied linear curve to all displays, so as far as loader is concerned everything was applied successfully. Logs I have checked tell the same story – everything worked correctly. It’s clear enough visually, however, that nothing has changed.
If I load or reset the calibration and then restart the loader, then it will apply the correct setting once started. It appears to work on first launch, but will not apply/reset the calibration “on demand”, so to speak. Similarly, calibrations apply and reset correctly if I use that option in DisplayCal UI under the “Options” menu (the loader will override this once I quit), so the issue appears to be specifically with the loader.
I noticed that the troubles start when my display configuration changes. I switch one display on or off, the desktop will flicker (as it usually does), and on the next attempt to load or reset a profile it may no longer work on one of the monitors. As I said before, profile associations seem to remain intact even after this change. One thing I did notice that changes when this happens is the order in which the profiles are listed in the loader’s notification pop-up. This actually has an effect on what calibrations will apply, and which will not. I basically have to switch my monitors on and off in a certain sequence so I can “stack” the profiles in the correct order to get it working again 😀
I am hoping this is an issue with the software and can be reproduced, because I have been unsuccessful so far in trying to track down some possible conflict on my end.
Any help is appreciated.
I tried using that profile association fix option when I encountered the problem and it doesn’t seem to make a difference – I have the issue with it on or off.
Currently I have 3 displays connected (I have recently disconnected one, so you could say I had the issue with 4 as well). The GPU is GTX 980 Ti, although I suppose it is worth noting that one of the displays is currently connected to the Intel’s onboard GPU.
I have attached the log file. I can point out some things here:
From 2016-10-09 20:57:31,625 to 2016-10-09 20:58:21,631 FG2421 and Sony work correctly, Denon does not. At 2016-10-09 20:58:30,111 I switch off the Sony. As can be seen, nothing in display configuration really changes aside from FG2421 “moving up” in the list. From that point on, the profile loads and resets are not applied on the FG2421 via loader (can’t say about others – screen is off).
FG2421 and Sony are connected to the Nvidia GPU, Denon is on Intel’s.
Thanks for the quick reply.
At 2016-10-09 20:58:30,111 I switch off the Sony. As can be seen, nothing in display configuration really changes aside from FG2421 “moving up” in the list.
I can’t reproduce it here, but from the logs it looks the display is still active, otherwise it wouldn’t be listed.
2016-10-09 20:58:30,111 <wx._core.DisplayChangedEvent; proxy of <Swig Object of type 'wxDisplayChangedEvent *' at 0x19ed18> > 2016-10-09 20:58:30,141 <wx._core.DisplayChangedEvent; proxy of <Swig Object of type 'wxDisplayChangedEvent *' at 0x19ed18> > 2016-10-09 20:58:30,183 A change in the display device configuration has been detected. 2016-10-09 20:58:30,552 SONY TV @ -1920, 0, 1920x1080 2016-10-09 20:58:30,552 FG2421 @ 0, 0, 1920x1080 2016-10-09 20:58:30,552 DENON-AVAMP @ 1920, 0, 1920x1080
I have an idea what the problem might be, but it’ll require more testing. Please try 3.1.7.1 Beta, it has a small bugfix in regards to the way display changes are detected as well as much more verbose logging. For testing purposes, I’d recommend assigning profiles via Windows color management that make the difference in calibration very clear, so that it is more easy to track changes visually as well. DisplayCAL has profiles with strongly tinted calibration in various hues in the “tests” folder that you can use for that purpose.
I did some quick tests with the beta… It didn’t fix the issue, but I have discovered something new – one of the displays actually “adopted” a test profile as a linear gamma table despite the fact that I never changed any profiles on that display.
I have attached a log file with some of my comments in it. I can do (or attempt to do) some more structured testing with different profiles on different displays later. Right now it kinda looks like gamma tables get messed up somehow, or loader starts pulling profiles from wrong places.
I just realized that the “reset gamma ramps” setting always overwrites the cached videoLUT for the 2nd display, and that seems to be the problem you’re experiencing. Try 3.1.7.1 Beta 2.
Btw, disabling one display out of a multi-display setup can mess up profile associations if those displays are connected to the same graphics card, but this is a Windows bug and not related to the profile loader. You can confirm this by opening Windows color management settings after disabling the display (you’ll likely see the remaining display listed as “Display: 1 | 2 Generic PnP Monitor – <Name of your GFX card)”. The only way around this is to not only disable/turn off, but also disconnect the display, or use the DisplayCAL profile loader “Fix profile associations automatically” feature.
This did it – all profiles are applying and resetting correctly now. Thanks for all the help. This was probably the most efficient “customer support” experience I ever had… and I am not even a paying customer this time, which is remarkable in its own right – all your work on this project is definitely much appreciated.
Btw, disabling one display out of a multi-display setup can mess up profile associations if those displays are connected to the same graphics card, but this is a Windows bug and not related to the profile loader. You can confirm this by opening Windows color management settings after disabling the display (you’ll likely see the remaining display listed as “Display: 1 | 2 Generic PnP Monitor – <Name of your GFX card)”. The only way around this is to not only disable/turn off, but also disconnect the display, or use the DisplayCAL profile loader “Fix profile associations automatically” feature.
I remember reading about this in the documentation, so I kept an eye on the profiles. In my case all the associations survived different display configurations intact (as far as I could tell). Now that the profile loader appears to be in order, I can use its profile association fix to lock things down just in case.
This did it – all profiles are applying and resetting correctly now.
Great, happy to hear that. 3.1.7.1 stable release will follow shortly unless something else comes up.
Thanks for all the help. This was probably the most efficient “customer support” experience I ever had… and I am not even a paying customer this time, which is remarkable in its own right – all your work on this project is definitely much appreciated.
Appreciated, and thanks for your help in debugging this. In defense of “regular” customer support elsewhere, they are really needed, otherwise developers would be overwhelmed if they had to do that support themselves for a large number of customers. For a comparatively small project like this though, direct contact to the developer can definitely be a real benefit 🙂
I remember reading about this in the documentation, so I kept an eye on the profiles. In my case all the associations survived different display configurations intact (as far as I could tell). Now that the profile loader appears to be in order, I can use its profile association fix to lock things down just in case.
My general rule of thumb would be don’t enable it unless needed – shouldn’t hurt to have it on even if unneeded atm, though.
