Hello Thomas,

Thank you for contacting Intel Technical Support.

As far as I understand, you would like to disable the Intel(R) Color Correction feature that is present with the Intel(R) Graphics Media Accelerator.

Intel provides generic versions of the Intel graphics drivers for general purposes through the Intel Download Center. As such, these drivers are designed to take control of the system graphical properties and settings once they are installed. For this reason, it is not possible to disable the Color Correction feature. However, your computer manufacturer may have altered the features, incorporated customizations, or made other changes to the graphics driver software or software packaging that they provide for your computer. Since you need a driver that acts in a more specialized way, I suggest contacting your system manufacturer so that they can provide a tailored driver to fit specific necessities (e.g. being able to disable features).

Sincerely,

Ronald M.
Intel Technical Support

I uploaded the code here as well: http://pastebin.com/f7f05ddf. A sample for a batch file SetProfiles.bat may be found here: http://pastebin.com/f5fd795d1 .

Thomas

- XCalib.exe from http://xcalib.sourceforge.net/
- AutoIt from http://www.autoitscript.com/autoit3/

Save the following lines between -code- and -/code- in a text file called “ColorProfile.au3″:

#include
Opt(’MustDeclareVars’, 1)

_Main()

Func _Main()
If $CmdLine[0] 3 Then
MsgBox(0, “Set Color Profile”, “Instructions:” & @LF & @LF & _
“”"path_to_autoit\AutoIt.exe”" ” & _
“”"path_to_this_file\ColorProfile.au3″” ” & _
“”"name_of_monitor”" ” & _
“”"path_and_name_of_icc_or_icm_file”" ” & _
“”"path_to_XCalib\XCalib.exe”"”)
Exit
EndIf

Local $aDevice, $i = 0

While 1
$aDevice = _WinAPI_EnumDisplayDevices(”", $i)	; get display device data
If Not $aDevice[0] Then ExitLoop	 ; done if all devices processed
If BitAND($aDevice[3], 4) = 0 Then	 ; we need only real devices
$aDevice = _WinAPI_EnumDisplayDevices($aDevice[1], 0)	; get the name of the connected monitor
If StringInStr($aDevice[2], $CmdLine[1]) Then
ShellExecuteWait($CmdLine[3], “-s ” & $i & ” -c”, “”, “”, @SW_HIDE)
ShellExecuteWait($CmdLine[3], “-s ” & $i & ” “”" & $CmdLine[2] & “”"”, “”, “”, @SW_HIDE)
ExitLoop
EndIf
$i += 1
EndIf
WEnd
EndFunc ;==>_Main

This script is called the following way. I just give an example with shortened paths.

“x:\path1\AutoIt3.exe” “y:\path2\ColorProfile.au3″ “SyncMaster 226CW” “z:\path3\MyProfile.icc” “n:\path4\XCalib.exe”

Where

- path1 is the path to the AutoIt3.exe file.
- path2 is the path to the script file.
- “SyncMaster 226CW” is the name of the monitor the profile corresponds to. To make things easier only a significant part is needed here.
- path3 is the path to the color profile file.
- path4 is the path to the XCalib program file.

I hope things became clear this way.

I put 2 calls like these into a .bat or .cmd file to re-adjust the profiles for both monitors with one click. If you use different monitors at different times (e.g. for a notebook that is used at work and at home) you just place the calls for more monitors into this file. Monitors that cannot be found will be ignored.

Hope that helps someone.

Thomas

- XCalib.exe from http://xcalib.sourceforge.net/
- AutoIt from http://www.autoitscript.com/autoit3/

Save the following lines between and in a text file called “ColorProfile.au3″:


#include
Opt('MustDeclareVars', 1)

While 1
$aDevice = _WinAPI_EnumDisplayDevices("", $i) ; get display device data
If Not $aDevice[0] Then ExitLoop ; done if all devices processed
If BitAND($aDevice[3], 4) = 0 Then ; we need only real devices
$aDevice = _WinAPI_EnumDisplayDevices($aDevice[1], 0) ; get the name of the connected monitor
If StringInStr($aDevice[2], $CmdLine[1]) Then
ShellExecuteWait($CmdLine[3], "-s " & $i & " -c", "", "", @SW_HIDE)
ShellExecuteWait($CmdLine[3], "-s " & $i & " """ & $CmdLine[2] & """", "", "", @SW_HIDE)
ExitLoop
EndIf
$i += 1
EndIf
WEnd
EndFunc ;==>_Main


This script is called the following way. I just give an example with shortened paths.

“x:\path1\AutoIt3.exe” “y:\path2\ColorProfile.au3″ “SyncMaster 226CW” “z:\path3\MyProfile.icc” “n:\path4\XCalib.exe”

Where

- path1 is the path to the AutoIt3.exe file.
- path2 is the path to the script file.
- “SyncMaster 226CW” is the name of the monitor the profile corresponds to. To make things easier only a significant part is needed here.
- path3 is the path to the color profile file.
- path4 is the path to the XCalib program file.

I hope things became clear this way.

I put 2 calls like these into a .bat or .cmd file to re-adjust the profiles for both monitors with one click. If you use different monitors at different times (e.g. for a notebook that is used at work and at home) you just place the calls for more monitors into this file. Monitors that cannot be found will be ignored.

Hope that helps someone.

Thomas

Interesting – it definitely solved it for me. Clearly there’s more sauce involved with this goose than meets the eye. Wish I knew what to suggest.

@All

I’ll give you you’d think Microsoft and Intel would be joined at the hip and testing this as part of hardware certification. I still think the majority of the blame falls on Intel – clearly its their driver insisting on loading the LUT when it shouldn’t load the LUT (unless you specifically tell it to)(that is, if you haven’t manually adjusted the gammas in GMA, it should just leave the LUT alone). At a minimum they (Intel) should just give you the option to enter the custom profile into the GMA.

That said, yes, Microsoft should have seen and fixed this given the quantity of systems using Intel based graphics out there. I think part of the issue is honestly there are relatively few people who calibrate their monitors. Moreover a lot that do are Apple users.

I don’t really care who’s problem it is, I’m going to see if I can get a ticket in somewhere. What’s reprehensible is how hard it is to find a way to give feedback to these companies that has a chance of being viewed…

As a workaround it would be in interesting if someone has an idea how to bypass the driver’s behavior or how to disable it.

@Matt Fahrner:
I understand what you want to say. But I think from a software developer’s point of view I have to agree with Wibbly. MS simply has not done their homework. And Intel hasn’t either.

BTW, I didn’t mention earlier, but in my case “igfxpers.exe” was disabled already. Only “igfxsrvc.exe” is still running. But this module is needed to recognize a monitor change. So disabling this would be counterproductive somehow.

Thomas

I know what you mean, but how does what now appears to be faulty drivers/processes (igxfpers.exe) make it past MS’s compatibility tests? I would say it *IS* a MS problem for sure. They are allowing/passing software that is incompatible with the way Win 7 operates the LUT table.

It turns out it wasn’t, and perhaps isn’t, Windows 7’s fault. It looks like some cards, particularly Intels, load their own gamma parameters whether you like it or not. So, in my case what I was seeing was on boot the colors come up correctly via Windows 7’s color management (without having to use “ColorVisionStartup” to load the LUT for my custom profile), however a few seconds later it would get overridden with the uncalibrated profile.

Well I did some digging and it became clear that the problem seemed to be something starting up *after* Windows 7 loaded the LUT. Moreover if I set the RGB gamma in Intel GMA control panel to bizarro values and rebooted, well low and behold those bizarro gamma values were the ones getting shoved in after the correct custom profile.

So that pretty much cinched it that Intel’s driver was mangling the LUT. More Googles later and I ran into this:

> just wanted to tell how I stopped losing the gamma when I restart the computer.
I learned from this blog to uncheck igfxpers.exe from the autorun.
> (Start > Run… > msconfig > Startup)
> http://neosmart.net/blog/2007/windows-vist…amma-table-bug/

From:

http://www.neowin.net/forum/index.php?showtopic=808104

And oddly enough, disabling “igfxpers.exe” via “msconfig” does the trick. This makes sense – Windows 7 loads the LUT at boot, later as you’re logging in “igfxpers.exe” starts up and trashes you LUT.

Now, for most PCs, disabling “igfxpers.exe” is said to be safe, however been warned for UMPCs it seems to be used to switch Intel GMA “Scheme”s at boot from low to high resolution and can cause problems if you disable it. However normal PCs should be a non-issue (to note, I ran the Intel GMA control panel to look up the “Scheme” info I just wrote and it just trashed my LUT again! – clearly it’s Intel’s stupid control stuff).

Anyway, now the problem seems to be finding a way to report this bug with Intel (to note some NVidia cards also seem to use “igfxpers.exe” causing similar problems). And if by some miracle I can find a way to report the problem, getting them to care is probably even harder!

To speed things up: what exact functionality is required?

John —-

Of course I’ve read about you and some others using DisplayProfile. I tried that, too. It works, but I find it very uncomfortable because I always have to click on the appropriate profile. And using more than one monitor with different combinations becomes very uncomfortable with DisplayProfile because I have to move the program’s window to the correct monitor …

That’s why I thought it might be useful to write a script as I mentioned. This script could find out what monitors are connected and which profile has to be assigned to each one of them.

Thomas