function(){return A.apply(null,[this].concat($A(arguments)))}RChaz wrote:
Also the original Windows 7 OS specs were designed to color manage more completely than the final release, but that was deferred to a future Windows version
Hm, I wonder whether maybe Microsoft is thinking along the lines of normalizing everything to one color space (sRGB) in the apps, then transforming that color onto whatever monitor is installed at the system level (e.g., with the GPU)...
That would certainly be a possible move to implement color-mangement system-wide, though it would completely ignore monitors with wider gamuts.
However... If one starts thinking along these lines, one wonders if maybe IE isn't transforming colors to a "hard coded" sRGB, but perhaps it might be converting to a settable default... Maybe the "Windows Color System Default" setting for Device Profile (as listed in the Advanced tab of the Windows Color Management dialog)? This setting is, out of the box, sRGB.
Now I have to experiment with changing the system default setting and running IE9. If it turns out to be the case that IE will manage to a different intermediate color space, then there could be a workaround for people with single (or matched sets of) wide gamut monitors.
Bah, what a great idea, but so far in limited testing it doesn't seem to be true. I did change the system default and... Nothing.
Sigh, maybe in the next version of Windows...
-Noel
Then if you open a file from IE9 in Photoshop, given a calibrated, profiled monitor, it will look different than on the screen in IE9....
Tried it and it opens as an untagged image. So, I gather I'll have to send out an image to a site viewable on the web and compare, correct? Also, If I send out an untagged image, IE9 tags it sRGB?
Seems strange that saving an image from IE9 removes the tag. Bunch of crap if you ask me. I am about to launch a website running restoration work, and people are gonna see what? The saving grace is that the before and after will at least be consistent, consistently wrong!
WTF!
function(){return A.apply(null,[this].concat($A(arguments)))}Hudechrome wrote:
Seems strange that saving an image from IE9 removes the tag. Bunch of crap if you ask me.
How did you infer this from what was written?
I don't believe it's the case. It's DISPLAYING images in IE9 we're talking about, not saving them.
And I don't know whether IE9 makes any assumptions about what color space an untagged document is in. As you say, experimentation is necessary.
-Noel
Just an FYI regarding the Windows Color Management applet, Advanced tab.
With the "Windows Color System Defaults" portion it's a bit difficult to determine just how these settings are used, but here it is:
They are used to supply defaults for missing profiles required during WCS color transform in color managed apps.
1) Device profile: If a device has no profile specified anywhere else, this setting would be used as the fallback default. (eg, leave as sRGB. Be careful NOT to set this to a "virtual device model profile" - which are also listed in the "All Profiles" tab as WCS Device Profiles - confusing!, as these can have serious negative impact on system performance, such as CPU spikes for Windows Gadgets.)
2) Viewing conditions profile: This one tells the system about your viewing environment. (sRGB version for D65, ICC version for D50)
---------------
Per a MS program manager:
The Windows Photo Gallery/Windows Live Photo Gallery, and Windows Photo Viewer are the only Windows components that color manage to the display profile. Most MS Office apps, (and now IE9), will honor embedded source profiles in images, but then convert to sRGB and throw that at the display.
A technology dubbed High Color was built into the Windows 7 plumbing. Color conversion would be to an extended range color space. Wide gamut color data can be converted into this space without any loss. Compliant displays (and display cards) would be required to be able to convert internally from the extended space to their native color space. Any wide gamut image content would be properly mapped to take advantage of a display's wide gamut, and sRGB data wouldn't over-saturate by being treated as though it were already in the display's native wide gamut space. (Un-color-managed RGB would be treated as sRGB.) Unfortunately the Desktop Window Manager was unable to implement the High Color support in time for switching this plumbing on for the Windows 7 release.
---------------
Not sure if existing Display hardware already supports this High Color system once/if it's actually implemented, or whether it will also integrate an up to date Display profile into the equation or merely utilize the "factory specs" (EDID) and allow color managed apps to refine accuracy further using profiles. But the stated approach would at least neutralize the wide gamut display issue without requiring users to participate (profile their monitors) in achieving "acceptable" color.
RChaz wrote:
.... All 4 quadrants will be matchingly different than the appearance that would occur if correctly displaying via your monitor's profile...
I'm not a big fan of conspiracy theories but given the fact that this is not a technical challenge at all but a matter of decision, I can't help it thinking if the brains at Microsoft decided instead of creating practically useful solution, it will be much more impressive when ignorant users check this http://ie.microsoft.com/testdrive/graphics/colorprofiles/default.html and say "wow, Internet Explorer 9 is the only browser with such advanced color managed supporting ICC version 4".
ICC version 4 requires all profiles participating in the color management chain to be version 4. If one is not, the chain breaks.
Although there are some possible workarounds as suggested in this thread http://www.luminous-landscape.com/forum/index.php?topic=50249.msg41533 7#msg415337, for the time being v 4 for most users is practically useless because some of the major color profiles like AdobeRGB and ProPhoto RGB are not ICC version 4 yet. For this reason users do not create v4 color profiles of their monitors but still stick to version 2.
I also find it funny how Microsoft is demonstrating the ICC version 4 capabilities of IE9. They basically took and modified the page from the ICC consortium site http://www.color.org/version4html.xalter . But note how the consortium objectively titled it as "Is your system ICC Version 4 ready?" which implies correctly that more than a browser is required to get accurate colors. They also explained what this test means (pay attention to the last two paragraphs) http://www.color.org/version4ready.xalter . Microsoft on the other hand, titled its page "Color Management" starting with the sentence "Does your browser display the colors in these images correctly?" which is totally misleading. The question is "are they misleading deliberately or they are simply stupid?" In both cases it is loose loose situation for Microsoft in the eyes of the savvy users. LOL.
I'm pretty sure the project team at MS that implemented this "color management" into IE9 are not stupid, and realize their approach is flawed. I believe they took this approach to be consistent with their Office apps approach or maybe for some other longer term reason. To foist that web page on users claiming "look at us, we're properly color managed!", with that awareness of flaws takes a lot of chutzpa, is hilarious\discouraging to people with color management knowledge, and extremely misleading to those without.
function(){return A.apply(null,[this].concat($A(arguments)))}emil emil wrote:
The question is "are they misleading deliberately or they are simply stupid?"
I believe the answer must be yes to both. That opinion would have been different if I had uncovered an underlying plan in my above test, but noooo....
There is a practical limit to what a virtually unlimited number of programmers can do, though one can easily imagine their marketing people, knowing those limitations and also not thinking Microsoft is likely to go out of business any time soon, deciding to "put off" certain features to make the next version all the more attractive. You'll note they really didn't allow any new features to show up in Windows 7 Service Pack 1. The only one I can think of is RemoteFX in Remote Desktop, and all that does is make Aero work across a remote link (but not OpenGL).
-Noel
I'm getting confused about "users creating any color profiles of their montors" in compliance with any color space. What I do and assume others using pucks do is to generate a profile of the montor which informs CM of what I am actually seeing with respect to the actual color numbers such that WYSIWYG. The color space choice then, is utterly separate, and makes no assumptions as to the accuracy or inaccuracies of the viewing conditions of the monitor.
This is the only thing that ever makes sense, and if an individual user chooses to go a different route, that's their decision and hopefully, WYSIWYG still is valid.
I want to stick to the two pronged approach: Calibrate then profile the viewing device, then pick your poison...err, color space.
But then, I am still centered on printing correctly, and from what I can see, this is becoming passe'. Few print any more as the ultimate output. Bill Gates saw this many years ago when he envisioned homes equipped with extremely thin panels hanging from the wall displaying all manner of art in faithful colors. That's one of the big reasons he started Corbis, or at least I was told that when I went up to Redmond years ago to look into Corbis. That being so, the Internet access has to be color managed from source to display device. Perhaps manufacturers will be able to match the dE tolerance of the best printers on the market today, which do extremely well with canned profiles from the paper folks. Then pucks go by-by as well.
function(){return A.apply(null,[this].concat($A(arguments)))}RChaz wrote:
A technology dubbed High Color was built into the Windows 7 plumbing. Color conversion would be to an extended range color space. Wide gamut color data can be converted into this space without any loss. Compliant displays (and display cards) would be required to be able to convert internally from the extended space to their native color space.
Thanks for that insight!
Makes perfect sense... Conversion from an integer data representation to a deeper internal integer representation should be extremely fast via cached table lookup, computers handle deep data with ease nowadays, and a complex color transform to an output space in the GPU should be fasssst indeed.
I experimented some with an OpenGL format called GL_SRGB_ALPHA. I've also implemented gamma conversion shaders so as to be able to do OpenGL combinational operations in linear space yet get all the benefit of direct screen writes. It's clear a modern GPU has no trouble processing the kinds of transforms needed for this work - it gets the job done in a tiny, tiny fraction of a second, even in super high quality floating point modes.
-Noel
function(){return A.apply(null,[this].concat($A(arguments)))}Hudechrome wrote:
I'm getting confused about "users creating any color profiles of their montors" in compliance with any color space.
Now I'm confused about what you're confused about...
Perhaps it's the discussion of the type of profile (v2 vs. v4) that is bothering you?
Otherwise I don't see an implication here that users are expected to create a monitor profile that's in compliance with a document profile.
-Noel
Hi gener7,
Don't be so certain. Please read the information starting in post #2 in this thread.
IE9 is actually NOT properly color-managing the images it displays, in that it completely ignores your monitor profile!
Therefore, for anyone who has profiled their monitor - especially those models that display a gamut differing significantly from that of the standard sRGB profile, such as modern wide-gamut LCDs - the colors will now actually always be wrong
in IE9!
Hi Noel
I did indeed go over post 2 and not having a wide gamut monitor I would have thought that IE9 would somehow pick up the monitor profile set in Color Management (in the Control Panel.) My mistake.
Ditto for Hudechrome. Maybe it will be fixed by the time I can afford a wide gamut monitor ![]()
Gene
North America
Europe, Middle East and Africa
Asia Pacific