Options
IE9 and Images
Dan7312
Registered Users Posts: 1,330 Major grins
So I installed the IE9 Internet Explorer beta. I went to my smugmug site and said to myself "Wow, all those images look better than they did in IE8, the colors are more saturated and clearer!" But I know that whenever I try anything new things always look better no matter what.
I don't have a way of doing a IE8/9 side by side comparison, but I did to a side by side comparison between IE9/Firefox and the IE9 looked better (to me of course), colors clearer and slightly more saturated.
I know IE9 does graphics differently that the previous IE browsers but I haven't found much about the details other than it uses DirectX.
I know I'm probably the only smugger who uses IE, but has anyone else tried IE9 and have you noticed any differences with images?
I've not cal'd my display but I do use the ICL profile that came with it and when I compare it to the smugmug test photos things match up really well.
I don't have a way of doing a IE8/9 side by side comparison, but I did to a side by side comparison between IE9/Firefox and the IE9 looked better (to me of course), colors clearer and slightly more saturated.
I know IE9 does graphics differently that the previous IE browsers but I haven't found much about the details other than it uses DirectX.
I know I'm probably the only smugger who uses IE, but has anyone else tried IE9 and have you noticed any differences with images?
I've not cal'd my display but I do use the ICL profile that came with it and when I compare it to the smugmug test photos things match up really well.
0
Comments
http://www.dgrin.com/showthread.php?t=178146
http://www.danalphotos.com
http://www.pluralsight.com
http://twitter.com/d114
Here's what I have found so far:
1. IE 9 is fast. Really, it blows away everything else on speed.
2. IE 9 does support embedded ICC's and will correctly render images in Adobe RGB, ProPhotoRGB, etc.
3. IE 9 does not apply my display calibration profile on any images. This is, in my view, a huge problem!
4. IE 9 will scale images quickly (presumably using the GPU) but it does not have the GPU apply any anti-aliasing/filtering. I see some nasty artifacts as shown below (look at the gentleman's jacket!).
FPV is the FastPictureViewer image browser.
The different colors arise from the fact that IE 9 is *not* applying my monitor calibration profile.
Asking this, because this was a major issue (aside bugs), when they tried to invent colormanagement to FF some years ago.
Except of the strong moire, which comes from heavy oversharpen and which is not seen in Safari and Chrome, I can do what I want (with three different calibrated profiles), I don't get much of different results in Chrome, FF, Safari, IE9, IE7 and FVP. Just a bit with FF because it also takes care of the rendering intent.
And to be honest, the sky at the first two images looks odd to me. Tooo redish.
I don’t understand. Can you clarify?
Author "Color Management for Photographers"
http://www.digitaldog.net/
As you know, there are two issues with color management on Windows:
1. Applying the profile specified by any embedded ICC within the image.
2. Applying the profile specified by any monitor calibration profile.
On my machine, IE 9 appears to handle 1 but not 2.
That's the exact opposite to Chromium which does 2 but not 1.
Fast Picture Viewer (which is not a web browser) does both of course.
For web use, I think that Chromium is rather more useful to me since the vast majority of my images are in sRGB. All of those images are displayed correctly. With IE 9, nothing is displayed correctly since it appears to completely ignore the display profile in Windows\System32\spool\drivers\color. So IE 9 displays sRGB images differently from fully color managed apps (like FPV, CS5, and Lightroom). It displays them just like other apps which lack color management.
I have checked the Color Panel Color Management options and they are correctly set. Since my normal calibration profile is in ICC v4, I did try swapping it out for a v2 version and that didn't help either.
BUT unlike with FF, Safari, FVP on which all the appearance of the image is different when the monitor profile is changed, f.e. to widegamut or photogamut, the appearance of Malcoms image on IE9 does not change at all.
If I'm not wrong this means, IE9 is reading the embedded profile but translates it to something like sRGB, regardless of the monitor profile.
I might be wrong here, because my monitor (as lots outta there) is not able to show >90% aRGB or > 98% sRGB.
@Malcom
Is this image sRGB or not?
If so, why a browsers/app, which falls back to/assumes an image is in sRGB in case a profile can't be read or the browser/app is not colormanagement, should present a sRGB image different?
Why a colormanagement app/browser should suddently present a simply sRGB image different, when the monitor profile is okay?
I don't see a reason for this.
Except for blueish or redish tints, which are often invented by false rendering intens when converting images to sRGB.
You're right. Something funky happened with the colors on my screen captures. They don't accurately reflect the colors I saw displayed by the three applications. I need to go back and look at that again. However, FPV and Chromium did render the same colors as each other and CS5/Lightroom. IE 9 is the odd one out.
The point is... for me, IE 9 is rendering the colors without regard for my display calibration profile.
Yes, I'm working in sRGB exclusively so there's no issue with embedded ICC's here. Indeed, other tests confirmed that IE 9 respects those nicely (including ICC's in v4).
I do not agree that the original image is (significantly) oversharpened. It's a large image that all of the programs have downscaled to fit on the screen. Chromium uses software scaling and does it well. FPV used the GPU but it does also try to tell the GPU to use the best filtering available (usually bilinear) to avoid moire and other artifacts. It seems that IE 9 has done neither and the result is ugly, IMO. The FPV rendition shows that better is possible with GPU-based scaling and hopefully this is something Microsoft will address.
It's possible that IE 9 is applying the monitor profile on other computers/configurations. But I cannot make it do so on my machine. So, if does work for others, I'd be interested to hear about that. Sadly, the one tiny piece of documentation I was able to find on IE 9 color management was silent on the display profile question and flat out wrong on other issues (claimed support for ICC v2 and v3, instead of V2 and v4):
http://msdn.microsoft.com/en-us/ie/ff468705.aspx#_ICCColorProfiles
I will need to go back and recreate my original screen captures to try and figure out why they don't reflect the displayed colors correctly but that doesn't change my main findings:
1. That IE 9 disregards the monitor calibration of my machine.
2. That IE 9 image scaling is rather poor and produces some pretty nasty artifacts compared with Chromium and FPV. In fact, I did try Firefox 4 and that gave similar results to FPV; some moire but not nearly as ugly as IE 9.
Yes, the original image is in sRGB and does contain an explicit ICC reflecting this fact. For anyone that wishes to try rendering this image on their own machine, I have placed the original image here:
http://www.malch.com/nikon/DSD_2841.jpg
I think you'll find the IE 9 colors do not exactly match, for example, CS5. I think you'll find they do match a non color managed app like IE 8.
At the risk of repeating myself... there's no issue with the embedded ICC; IE 9 handles that fine.
The real issue is... my monitor isn't natively perfect. Hence it was calibrated with a Spyder. Fully color managed applications will use the Spyder profile to "correct" the displayed colors. I have more than a dozen apps and every one of them is behaving as expected. CS5, Lightroom, FPV, Capture NX and all of the other fully color managed apps will apply the display profile resulting in accurate/consistent colors. The non color managed apps don't. Others that are partially color managed behave exactly as I'd expect too.
I’m still not understanding this. In an ICC aware app, the embedded profile and the display profile both have to come into play. I wasn’t aware of any Windows issue where this wasn’t the case (I can’t see how an app could be considered ICC aware if it didn’t take the display profile into account when transforming the document color space for preview, something Adobe calls Display Using Monitor Compensation). But I’m a Mac guy. I know that in the past, there were issues on Windows where you could have a display profile but its LUTs were not loaded into the graphic system (hence the need for the old gamma loader).
Are you saying this browser recognizes the embedded profile in the doc but then doesn’t understand or use the display profile to transform those values for the display?
Author "Color Management for Photographers"
http://www.digitaldog.net/
Yes, exactly! It does only half of the job, at least on my machine. I don't yet know what others are finding. Still waiting for some credible input on that.
But this is not uncommon in the windows world :-( There are a lot of apps which only do half the job.
For example, Chrome and Chromium have the ability (not enabled by default) to apply the display profile. But they ignore the embedded ICC's in AdobeRGB, ProPhotoRGB images. Having said that, they work pretty well if (and only if) you're viewing sRGB images.
There are others (e.g. FastStone Image Viewer) which claims to have a color management option. When enabled, it recognizes embedded ICC's but it never applies the display profile. Windows applications need to do this for themselves -- Windows doesn't automagically do it for them.
Firefox does both. However, it will not handle embedded ICC's or display profiles expressed using ICC v4. Also, as a general browser, it's much slower than Chromium or IE 9, on my machine.
What Windows 7 does do is:
* Maintain a list of installed color profiles and allow to user to specify the default profile for each device.
* It makes that info available to applications. i.e. The app can ask Windows "What is the default profile for device X?".
* Windows can also preload the video LUT with the gamma and white point data from the calibration profile. This is a Good Thing but it is not sufficient by itself for full color management. Earlier versions of Windows did require a separate LUT loader to do this.
What Windows doesn't do (and color managed apps need to do) is apply both the embedded ICC profile and the device-specific profile. Some programs apply one profile, some apply the other, a few apply both (correctly) and, too many don't do anything at all.
Something else for you Mac users to gloat over ;-)
FYI: this is a fairly complete list of fully color managed apps for Windows:
* Adobe CS3, 4, 5 (I'm not sure what the status is with PS Elements)
* Adobe Lightroom
* Nikon Capture NX/View NX
* Fast Picture Viewer
* ACDSee Pro
* Zoner Photo Studio
* PhotoMechanic
* Firefox (but doesn't handle ICC v4)
* Safari I think. I only looked at it briefly some while ago
Most of the rest have no color management or partial color management.
I can't help feeling that Microsoft just don't understand color management. I know that a lot of application developers don't because I have personally discussed these issues with quite a few of them. Just try looking for the information to explain what a developer needs to do to make a Windows app fully color managed. You'll probably come up empty handed. Or, worse still, with erroneous information.
As I said, I’m a Mac guy but this behavior seems very odd and I would not call it ICC (color management) aware. Recognizing an embedded profile without having the ability to also recognize and use a display profile for Display Using Monitor Compensation just makes no sense. Its like one hand clapping. When you say its “doing only half the job”, I wonder what they are trying to accomplish. This is per application I have to assume as you say other app’s work correctly. Photoshop, Lightroom, C1, Safari etc, etc all preview the same RGB values simply because they use both sets of profiles. One profile by itself can’t do squat.
Non ICC aware app’s just take the RGB values and send them to the display. They have zero knowledge that the RGB values are sRGB, Adobe RGB or any RGB for that matter. The numbers go to the display, and the app has no idea of the display profile either. I wonder if this is what you are reporting. If an app “knew” the RGB values were say Adobe RGB (1998) and sent that to the display (which is what I suspect you are reporting), without the display profile in the loop, those values would not preview correctly because again, sending R45/G87/B91 directly to the display even when understanding its scale (Adobe RGB (1998)) not using the display profile to then properly render those values just doesn’t produce the correct color appearance.
Author "Color Management for Photographers"
http://www.digitaldog.net/
http://www.danalphotos.com
http://www.pluralsight.com
http://twitter.com/d114
i use firefox 4.0 beta 64bit [ nicknamed minefield ]
i downloaded the image from above http://www.malch.com/nikon/DSD_2841.jpg
and it looks exactly the same as the one from IE9 in post #5
/ɯoɔ˙ƃnɯƃnɯs˙ʇlɟsɐq//:dʇʇɥ
1. The light part on the sleeve of the childs' coat is a different color in each browser.
2. Darker part in the folds of the upper part of the sleeve of the woman's coat has slightly more detail in IE9.
In both cases the red's appear to be a bit brighter or more intense (don't know the proper term) in IE9.
Dan
http://www.danalphotos.com
http://www.pluralsight.com
http://twitter.com/d114
I made some tests (to make it obvious with a cyclical monitor profile, red => blue, green => orange, etc) and they show only PS, Bridge, Safari, FF and IMatch (my DAM) maps to the monitor profile. FVP, Chrome and IE9 maps to an "general" sRGB space.
So IE's "colormanagement" its only halfbacked.
<a href="http://samples.no-nameweb.de/IE9b.jpg" target="_blank"><img src="http://samples.no-nameweb.de/IE9b.jpg" width="570" height="326"></a>
top row: PS w. monitor profile proof, FVP, IE9, Chrome, Safari
bottom row: PS original, FF, Bridge (mid, underlayed), Imatch
FPV *does* apply the monitor profile. However, like some other Windows programs, it does require that the user explicitly configure the monitor profile within the application settings (Options | Display | Color Management). You may have to use the Pro version of the product to get this functionality (I'm not sure it's available in the free edition). Quite a few other Windows programs require explicit configuration, including (from memory) ACDSeePro, ZonerPhotoStudio, PhotoMechanic and others. The Nikon and Adobe products get the monitor profile directly from Windows (no need to manually configure them).
Chrome and Chromium can optionally apply the monitor profile. You have to enable this via the poorly documented command line switch: --enable-monitor-profile. Just add this to your Chrome shortcut so the program is launched with that option enabled. Then those browsers will do a great job of rendering sRGB images (but only sRGB).
Note Firefox is a bit half-backed too. It doesn't support ICC v4. See:
http://www.color.org/version4html.xalter
IE 9 looks better on that test because it does apply the embedded ICC's versus treating everything as sRGB. However, it's not applying the monitor profile and that's a showstopper in my book.
It actually the V4 spec and implementation that’s a bit half-baked. Its not really at all useful in this case (for just screen viewing) and for the use in output profiles, its caused more problem than its solved. V2 profiles for the time being are just fine.
Author "Color Management for Photographers"
http://www.digitaldog.net/
You might also try looking at this image (which I use as a primary color management test):
http://www.malch.com/nikon/DSD_1314.jpg
Once again, the image is sRGB.
Now, if I view this image with CS5 or any other fully color managed app. the bricks in the background look to be something like a yellow ochre. As soon as I view it in an app that is not color managed, the image contains way too much red and the bricks take on a very heavy red cast. That's because my monitor displays reds that are too strong. My calibration profile effectively attenuates the reds by an equal amount to hopefully result in an image that is "just right". You may see a different effect depending on the inherent imperfections in your specific monitor. Your calibration profile will be different from mine because our respective monitors have different imperfections built into them.
But unless your monitor renders sRGB perfectly (and trust me it doesn't without a calibration profile) you should be able to see the color differences between those apps that apply the display profile and those that don't.
Considering that sRGB is based on a theoretical display based on a CRT circa 1993 using P22 phosphors, you can kind of forget about that perfection <g>.
Author "Color Management for Photographers"
http://www.digitaldog.net/
I'm sure you have studied this in much more detail than me and I'll accept your word on that. However, Firefox is the only program I know of that exhibits a v2/v4 issue. And folks need to be aware of this otherwise they'll be very confused (as I was) when Firefox apparently ignores their v4 monitor calibration profile. And, by the way, it does
silently ignore ICC v4 profiles (rather than throwing an error/warning).
If Firefox matched Chrome and IE 9 on performance, I would still be using it. The v4 limitation is certainly not a huge problem for me. My display profile is actually ICC v4 but it's no big deal to maintain a v2 mirror just to keep Firefox happy.
But hands up: who is using sRGB V4 profiles in his/her workflow or does even know about it? ;-)
Umm, that would be me ;-)
As stated earlier, my default display calibration profile is ICC v4. Now, it's certainly not a huge deal for me because I can easily create a v2 copy. However, it did have me scratching my head for a few hours when I tried to make it work with Firefox.
I do think the color management support in Firefox is pretty reasonable. I also agree with their decision to shift from LCMS to QCMS for reasons of performance. It was that transition that created the ICC v4 issue. However, I would prefer to see Firefox produce a warning/error when encountering an unsupported profile! Silently ignoring such conditions is rarely a good thing, IMO. Unfortunately, I have other issues with Firefox, mainly related to poor performance relative to Chromium.
The failure of Chrome/Chromium to respect any embedded ICC's is rather more serious. But at least those products are suitable for viewing sRGB images and I can live with that limitation in the short term. I believe it does need to get fixed in the longer term. I'm rather impressed with Chromium performance and also the nice clean scaling on large images (much nicer than Firefox or IE 9).
However, the failure of IE 9 to respect the monitor profile is not acceptable for me. It means that I'm not going see accurate colors rendered for *any* image, and that basically sucks! It's an especially big deal for me because I have a home-brewed Digital Asset Management system that uses a web browser for the front end user interface. It's a shame about the color management (which I thought was going to get nailed) because the performance if IE 9 is very impressive.
For the time being, Chromium remains my first choice.
The question is why and what you expect to get from using this version which is so poorly supported? What do you expect V4 ICC profiles to be doing for you? Can I suggest nothing useful and in many cases, potentially troublesome results?
Author "Color Management for Photographers"
http://www.digitaldog.net/
I'm probably guilty of assuming that v4 is newer and therefore better than v2, versus critically examining all of the facts and nuances.
On the other hand, life is too short to analyze every single thing. And, since ICC probably should understand this stuff better than me, I took their "expert opinion" at face value:
http://www.color.org/advantagesv4.pdf
To be honest, I've not personally experienced any problems with ICC v4 support, except with Firefox.
But this certainly wouldn't be the first time that following expert advice led me down the wrong path ;-)
Once again, I don't see the Firefox lack of support for v4 as a huge deal. However, I do feel that folks should be aware of the issue so they don't waste time trying to troubleshoot problems with Firefox and v4 profiles.
That’s one issue you can rack up, start printing with V4 profiles, you’ll find others. And there’s nothing V4 brings to the party in terms of web browsing so assuming you are not building or printing with V4 profiles, there’s about zero need to have your calibration software default to building them. Go back to V2 and the one issue you have will disappear.
Author "Color Management for Photographers"
http://www.digitaldog.net/