Hi,yes, I knew about the issue you are warning me about, by reading Argyll's documentation. So I recently disabled all the processes you mentioned, just to be on the safe side. I don't know if nVidia solved the problem or not. Before disabling the processes I never noticed the OS flushing my LUT clean, but since I only use the external monitor for sporadic photographic work I never really thoroughly tested the issue. I will try to run some tests as soon as I have a chance.
Thanks again, Leonardo Facchin Il 10/13/2014 7:54 AM, Graeme Gill ha scritto:
Leonardo Facchin wrote: Hi,The laptop graphics system makes use of the nVidia Optimus technology.Beware - it's been reported that igfxpers.exe that gets installed with nVidia "Optimus" technology interferes with Video LUT loading. I'm told that you may have to disable both the igfx tray module (c:\windows\system32\igfxtray.exe) and the igfxpph Module (c:\windows\system32\igfxpph.dll) in addition to the persistence Module (c:\windows\system32\igfxpers.exe). I have no idea what effect that has on the system operation though. If nVidia have fixed these problems it would be good to know, so that I can update the documentation.The problem is that right now I'm totally lost and confused about how the "two" graphics cards actually interact with the calibration and profiling process. Let's assume that I could force both the relevant Adobe softwares to run with the nVidia GPU (which I did) and the Argyll CMS components to do the same (which I didn't: even if I associate the Argyll executables to the nVidia GPU, when I run them the GPU remains idle, at least according to the nVidia Optimus GPU State Viewer, a little software meant to show when the GPU is powered up and running).ArgyllCMS doesn't use the GPU, so I wouldn't expect an association to do anything.Still, how can I know how many LUTs the system can access and which graphics card control each of them? Could the two cards be sharing the LUTs? Does it even make sense?The Video LUT is logically associated with a Video output port, so if it's been implemented correctly, there should be only a single set of LUTs, probably in the Intel hardware if it's driving the HDMI port, but in any case there is only a single operating system API per display. Now, they may messed all that up (hence the feedback that igfxpers.exe is a problem.)I know that the easiest solutions would probably be to stick to the Integrated Processing Unit and be done with it, but on the one hand the total confusion is undermining my trust in the accuracy of my color managed workflow and on the other I just developed the curiosity to understand a little better how this system works.It's usually not that hard to figure out what's going on. Use dispwin -c to clear the VideoLUTs, and dispwin strange.cal to set a noticeable LUT. That will tell you whether calibration loading is working as expected. <http://www.argyllcms.com/doc/dispwin.html> Graeme Gill.
--La mia galleria fotografica su Flickr <http://www.flickr.com/photos/leonardo_facchin/>