Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: John Hollenberg on September 04, 2016, 08:11:10 pm
-
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.
-
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!
-
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.
-
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?
-
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.
-
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.
-
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!
-
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.
-
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.
-
Understood; at least with OSX, when it happens, one does get a notice that access to the Profiles folder requires permissions.
-
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...
-
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.
-
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...
-
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 :-).
-
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.
-
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.
-
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.
-
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.
-
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.
-
............... 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.
-
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.
As I said, it's a stretch. I also agree the installation behavior accomplishes little to nothing. However, such approaches by malware writers have been done and the incredible complexity of the code in systems these days makes it extremely difficult to protect against.
However, it's also a very unlikely attack vector because very few install ICC profiles and those that do are not attractive targets from either a financial pov (most malware) or intel gathering pov (state actors). So silently ignoring an install request is just knee jerk "security" implemented in a way that is annoying and confusing. A lot of that going around these days.
-
Werd problem. I use windows 10 since januari. Create a lot of profiles on another computwr before transferring these to my production computer. NeveR experienced this issue.
-
So silently ignoring an install request ...............
Perhaps the case for Windows, but on OSX one does get a warning and there is an option for the user to over-ride and allow the install. Maybe it achieves nothing of technical importance, but as I mentioned above, that's probably not what it's for - it's possibly there for the optics of positioning responsibility onto the user. Otherwise why bother if it's not a good technical approach, which they would know.
-
Werd problem. I use windows 10 since januari. Create a lot of profiles on another computwr before transferring these to my production computer. NeveR experienced this issue.
I also have never seen this happen and that includes downloading profiles from the web as well as installing profiles created on other computers. And that's with Win 10 x64. Could be some configuration. Windows is security is highly configurable for IT to control corporate environments.
-
I've run into it a few times, when extracting data off of a hard drive from a dead system. It's fairly easy to reproduce.
I went to a "foreign" system (one of several Win 10 pcs in my house), and downloaded BetaRGB.icc from Bruce Lindbloom's website. I then formatted a USB drive on this same pc, selecting NTFS as the file system. The USB drive after formatting shows Everyone as the only user in the security properties screen. I copied the BetaRGB.icc file onto the USB drive. This is consistent with what one runs into extracting data from a foreign hard drive, except there may be other users listed in the properties.
I moved the USB drive to another Win 10 pc and copied the profile to my desktop. A right click on the file brings up the context menu, including Install Profile, and I invoked same. I checked the security properties of the profile in c:/windows/system32/spool/drivers/color, and all appeared ok, except that it was "branded" as a file from an unknown system, with a msg that it might be blocked, and with a convenient check box to unblock it.
The moral of this story is choose FAT32 for your file system on a USB drive used for file transfer. I won't comment on the appropriateness of Window's actions, but they are consistent.
Richard Southworth
Added by edit - I was not blocked from using the profile in Photoshop even though I had not checked "Unblock", maybe a difference between PS and LR?
-
I moved the USB drive to another Win 10 pc and copied the profile to my desktop. A right click on the file brings up the context menu, including Install Profile, and I invoked same. I checked the security properties of the profile in c:/windows/system32/spool/drivers/color, and all appeared ok, except that it was "branded" as a file from an unknown system, with a msg that it might be blocked, and with a convenient check box to unblock it.
Sounds like the problem is not something specific to ICC profiles, but just a permissions problem. Maybe Win10 changed the default permissions for some sorts of file creation, and therefore such files are not readable when copied from NTFS to systems without a corresponding user account.
-
In my experience as long as the files from another Windows system aren't encrypted/password protected, then one can always take ownership and read the data. However they are flagged as "foreign", and hence the message on the security properties screen. It would then be up to an application, or possibly the OS, to decide to reject/hide the files. As the OP discovered, they can be unblocked.
Richard Southworth