Installed ICC Printer Profile Not Available in Win 10/64

[John Hollenberg]

I can't figure out what is causing this problem.  Took an ICC printer profile for my ipf6300 from my old Win 7 system.  Right clicked the profile and then selected "Install Profile".  Profile is now in the proper directory (c:\windows\system32\spool\drivers\color).  However, profile is not available in Lightroom (even after a reboot of the computer).  It also doesn't show under "Color management" on Windows 10.  Never had a problem in Win 7/64.  Does Windows 10 require something else be done?

Thanks.

[John Hollenberg]

OK, wasted a bunch of time due to idiotic Windows 10!  Finally discovered the solution (by accident):

1) Right click profile and select properties
2) Note that Windows 10 has decided to block this profile because it came from another system!!! Check "Unblock" and apply the setting
3) Delete the copy of the profile in the \spool\drivers\color after noting that it contains 0 bytes
4) Reinstall the unblocked profile by right clicking
5) Open Color Management in Windows 10 and select the ipf6300 printer from the dropdown
6) Click on "Add" and then select the printer profile

As I said, a colossal waste of time due to idiotic Windows 10!

[Mark D Segal]

John, I suspect what's going on is security-related, because the profiles are treated as System files. With Mac it's normally very simple: just copy the profile to Library>Colorsync>Profiles and it shows up in LR and PS readily. However, I once discovered it is first necessary as a one time operation to give the Profiles folder "Admin rights" (Read and Write), because it is a System folder.

[digitaldog]

IF it is a CMYK profile, in the later versions of LR, not going to show. CMYK support was removed. Can you see it in Photoshop if you have that product installed?

[John Hollenberg]

Mark, yes it was security related, but Microsoft snuck that into Windows 10 (not a problem in Windows 7).  I had a devil of a time figuring out the answer, didn't find it from extensive use of google.  Stumbled on the solution accidentally.

Andrew, profile is RGB printer profile.  After the above convoluted steps I can now access the profile in Lightroom.

[Mark D Segal]

I hear you. Both Apple and Microsoft do things with these operating systems from version to version which they aren't very diligent at documenting for users - especially the more arcane stuff that can really hang-up the specialized audiences who depend on it. It's unfortunate.

[GWGill]

Both Apple and Microsoft do things with these operating systems from version to version which they aren't very diligent at documenting for users - especially the more arcane stuff that can really hang-up the specialized audiences who depend on it.

Blocking ICC profiles is about as logical as blocking .jpg files. They aren't executable code, they are data files with a well defined format, and if you don't trust your own ICC profile parser,  blocking ICC profiles is not a fix!

[Mark D Segal]

Blocking ICC profiles is about as logical as blocking .jpg files. They aren't executable code, they are data files with a well defined format, and if you don't trust your own ICC profile parser,  blocking ICC profiles is not a fix!

I think their logic is that anything getting into the heart of the operating system should require some form of access protection/permission, as the system is "theirs" and the profiles are "ours" - external till they become internal, so that puts the onus on the user. I'm not defending it, just trying to surmise why they do it - everything has a reason whether we think it is a sensible one or not.

[John Hollenberg]

The problem isn't that the ICC profile is blocked, but the fact that it is blocked silently with no easy way to discover why the install doesn't work.  Microsoft should have put in a warning when attempting to install that allows the user to decide whether to block or unblock.

[Mark D Segal]

Understood; at least with OSX, when it happens, one does get a notice that access to the Profiles folder requires permissions.

[Royce Howland]

Thanks for this thread. It's the first I've heard of this new Win10 "feature". As with others, I'm a bit mystified about what problem Microsoft thinks is being solved, at all. Especially since Windows itself make so little use of ICC profiles, leaving nearly everything related to colour management to applications. Frankly I hope it stays that way.

Even if there's some kind of rationale to the new "security", silent profile install failure seems like a poor method of doing whatever they think they're doing. Hopefully they'll make the user interaction side of security more robust and informative...

[Mark D Segal]

Especially since Windows itself make so little use of ICC profiles, leaving nearly everything related to colour management to applications.

Not quite so. The input and output profiles needed to print the photos are part of the colour management system and they "talk to each other" through the computer operating system's CMM (colour management module) in the PCS (profile connection space). It's at the heart of the colour management process.

[Royce Howland]

In Windows, colour support is very passive, nothing like the active colour management capabilities of ColorSync on Mac OS X. From what I know, the Windows CMM is basically just a pre-installed software library that's called under the control of applications needing it to perform colour management functions. But that's not necessarily all that common. For most people running an Adobe Photoshop or Lightroom workflow with application-managed colour, they are by default using the Adobe-supplied ACE CMM. As another example, Qimage also uses its own included CMM (if I recall based on LittleCMS). The Firefox browser doesn't use Windows CMM either, as far as I know it has its own. Etc.

There are many CMM's and the Windows-included one is only one of them, nor does Windows in any way force that theirs is the one used by applications. So as it nets out for people taking even a slightly active role in colour managed output on Windows, I suspect there are relatively few situations where people would be relying on Windows' internal colour capabilities.

Even in the cases where the Windows CMM would be used for something, I'm still curious what problem Microsoft thinks they are solving by blocking the installation of ICC profiles...

[Mark D Segal]

Chapter 11 (not bankruptcy, but the Chapter number) in "Real World Color Management" 2nd Edition explains these relationships in quite some detail. Though dated, it is probably still valid. It distinguishes functions between Application colour management and OS-level colour management. Both are usually involved on a reading of this material, but can "weigh-in" differently depending.....always depending  :-).

[GWGill]

I think their logic is that anything getting into the heart of the operating system should require some form of access protection/permission, as the system is "theirs" and the profiles are "ours" - external till they become internal, so that puts the onus on the user. I'm not defending it, just trying to surmise why they do it - everything has a reason whether we think it is a sensible one or not.

Nothing about ICC profile handling in an OS is "internal". The OS does little with an ICC profile, apart from storing it, and making it accessible to applications. i.e. they are doing it wrong if an ICC profile is being read or written by other than user mode code.

[Mark D Segal]

Nothing about ICC profile handling in an OS is "internal". The OS does little with an ICC profile, apart from storing it, and making it accessible to applications. i.e. they are doing it wrong if an ICC profile is being read or written by other than user mode code.

I believe in the minds of the designers the distinction may be this: the Profiles folder with its contents is a component of the operating system (hence internal to that system whatever it does); a new profile contributed by the user was not originally part of this system, but only becomes so through a user-determined action internalizing it (again regardless of what it does). Because there is a user action bringing a component from outside the OS in, there is a level of protection. Why it's needed I don't know - you may well be correct that it's superfluous, but I can't conjure any other reasoning why both companies would be doing this.

[Doug Gray]

I believe in the minds of the designers the distinction may be this: the Profiles folder with its contents is a component of the operating system (hence internal to that system whatever it does); a new profile contributed by the user was not originally part of this system, but only becomes so through a user-determined action internalizing it (again regardless of what it does). Because there is a user action bringing a component from outside the OS in, there is a level of protection. Why it's needed I don't know - you may well be correct that it's superfluous, but I can't conjure any other reasoning why both companies would be doing this.

Malware writers are creative.  ICC profiles do not contain executable code but they can contain lots of binary data pretty much without limit.  There may be exploits that use bad data in LUT tables to break interpolation code but this would depend on the design of programs that do color management. It would be possible, for instance, to create a subtle backdoor in CMM engines that detect certain conditions in profiles and then do their thing. It's a stretch though.

[Mark D Segal]

Malware writers are creative.  ICC profiles do not contain executable code but they can contain lots of binary data pretty much without limit.  There may be exploits that use bad data in LUT tables to break interpolation code but this would depend on the design of programs that do color management. It would be possible, for instance, to create a subtle backdoor in CMM engines that detect certain conditions in profiles and then do their thing. It's a stretch though.

Well, there you go. Stretch or not, could well be thinking broadly along those lines, essentially to the effect that MS/Apple don't want to be called-out for willy-nilly allowing potentially damaging code into the heart of the OS.

[GWGill]

Malware writers are creative.  ICC profiles do not contain executable code but they can contain lots of binary data pretty much without limit.  There may be exploits that use bad data in LUT tables to break interpolation code but this would depend on the design of programs that do color management. It would be possible, for instance, to create a subtle backdoor in CMM engines that detect certain conditions in profiles and then do their thing. It's a stretch though.

Don't try and throw voodo-security at me. If their ICC parsing is code is either A) being executed in kernel mode or B) not written in a robust way, then they are doing something wrong, it's as simple as that, and the described change in installation behavior is not a way to address either issue.

[Mark D Segal]

............... and the described change in installation behavior is not a way to address either issue.

That may well be correct in a technical sense - you would know better than me - but regardless, it is a way of providing the optics for shifting responsibility from the OS provider to the OS user. Not everything is done for reasons of technical purity - let's face it.