I am going insane in my attempt to keep consistent color management through all areas. Everything was fine, color was great, prints were matched to calbration, monitor calibrated, and then....I rebooted the computer since I hadn't done so for a week, and when I restarted Bridge, and Lightroom (yields same results), the color immediately drains from the photos. Similar to the screenshot, however when I initially created this screenshot, Bridge was still accepting the color. Now, the desaturation exists in all Adobe programs. (PS CS5, camera raw, bridge , lightroom 3. I feel like I'm going in circles here. I have no clue what could have changed with the reboot. One thing I have noticed is that in Window before a photo image is generated in a folder is shows as a paint pallette. And, when asked in Windows Color Management of the program I would like to use to install a profile, I am give Microsoft Color Management System (which to my understanding is designed for Vista or XP). Tried to delete the program but was denied. Not sure if that has anything to do with it either.
If you have any insight and can help me stop the madness I would be so greatly appreciative!!
Thanks! 
Windows7
U2410 Dell Ultra Sharp Monitor
Photoshop CS5 64-bit
Adobe Lightroom 3
Camera RAW
Adobe Bridge
NIVIDIA FX 580
117
Replies
Even though your test results so far are a little confusing, I still
believe this is expected behavior, where your wide gamut monitor is just
oversaturating images that look normal under color managed
applications. I own a wide gamut monitor and can reproduce the effect
you're getting by opening an aRGB tagged image in IE8 and seeing that
its far more saturated than the same image opened in Firefox, Safari, or
Photoshop since they can read and respect the embedded profile without
sending the color numbers straight to the monitor.
Since I work in a company doing a lot DTP (we do yellow pages for some cities in germany) I have a business related interest in that and I had a remote session with Connie some hours ago.
How does it fit to you, when even a sRGB made on my computer, with an embedded sRGB profile, sent over to her computer, looks desaturated in Bridge on her monitor, but as it should be in IE and FF?
A sRGB might should loook slighty different in Bridge, but not at all desaturated. Its like watching an image with a large colorspace by a small monitor profile or assigning sRGB to an image in ProPhoto. Or similar to what we see with an unmanaged browser (IE <V9) in the web, when the images are in aRGB or ProPhoto.
The DELL monitor profile coming with the CD was loaded. You won't believe it, when haven't seen.
I'm a bit lost here, since the issue appears to her after a reboot, so I don't expect a hardware failure. I also don't believe its a Adobe bug (I must have it as well with my U2410), but something else interfering...
To one of her PSD this was assigned, and Bridge showed it as untagged:
Mind the © in front - filename on disk: dsc_4400cz-89.psd
ps
was very late yesterday, so here're the screenshots
to the left how the image looks on her monitor in Bridge with the default DELL U2410 profile, to the right the same image as it should look, in my Bridge (embedded sRGB)
Camera RAW preferences were set to "apply autotone adjustments" unchecked and "disable JPEG support", so it was not influenced by this.
Thanks for the info on Windows LUT loaders. It's nice that they give such easy, intuitive controls over OS color management, since color management itself is already so abundantly easy to understand...
Thank you for providing more info on Connie's issue, too. Maybe if we eliminate more variables we can figure it out. I have a vested interest in solving this problem too, mostly out of curiosity and a better understanding of how the color management eco system is working in this situation. I'm a new-hire quality engineer (assigned to color management) on the Photoshop team, so I'm trying to learn as much as I can by working on weird problems like this .
Perhaps we could stick with this one image for now, for testing purposes? Could you tell me what version of Bridge/Photoshop you guys are using? If the desaturated appearance also appears in Photoshop, would you mind if we isolated the testing to Photoshop for now? I'm not as familiar with Bridge, and I suspect that the embedded profile not being displayed in Bridge is a potential bug (I can at least verify this behavior by using my own PSD files, Bridge seems to not display the metadata profile name when the PSD reaches a certain file size... I haven't checked with the Bridge team yet to see if this is a bug though).
I'm checking to see if I can find a copy of this U2410 monitor on floor so I can reproduce this behavior. I have an HP Dreamcolor wide gamut monitor right now, so I'm working with that to try and reproduce the situation.
The behavior I mentioned that you quoted above I can also reproduce with an sRGB embedded image (in fact I was using an sRGB image and mistakenly thought it was embedded with aRGB, oops...) but if a tagged image is looking the same in IE as in FF, but different in Bridge/Photoshop, it sounds like something else is happening...
Would you mind sharing the version numbers of your IE and FF? I heard the older versions of FF had CM turned off by default, but the newer versions have it turned on by default. I'm using IE8 right now and FF 3.5.13.
If you feel like it you could download the windows version of Apple Safari browser and try that one, too. That browser always has CM turned on, and on my machine I'm getting identical results to FF but IE8 is behaving as though it's not respecting the profile (expected).
Does the U2410 have different "modes" that you can set in the monitor menu, and then assign the corresponding manufacturer provided profile in Windows color management? I tried this with my HP Dreamcolor, setting its mode manually to sRGB, and then changing the monitor profile WCM to match it as sRGB, and then the colors on all applications match (IE8, FF, Safari, and Photoshop). Could you try something like that?
My theory is that the desaturated colors are the "right" colors, and that the monitor just displays a wider gamut with much more saturated colors than the color spaces typically embedded in images (sRGB, aRGB). Since you have the same monitor though, it sounds like this might not explain it, but just comparing screenshots I don't think will answer the problem since screenshots in Windows are untagged (if they're just capturing the raw color numbers coming out of the monitor, then a screenshot passed between one U2410 to another could still look different from each other, and it wouldn't prove that the Bridge/Photoshop colors are wrong). Or, if you paste a screenshot into a blank, new document sRGB image in Photoshop, the image inside of the color managed app will appear desaturated and the image in non-managed app will appear normal.
Would you mind letting me know about the color modes settings for the U2410 and make sure you and Connie are using the same mode settings, along with the same Windows CM monitor profile and as close to identical Windows CM settings as you can both get to?
Another test would be for Connie to open the desaturated looking image in Photoshop, edit it until she gets the color appearance she likes (without changing the embedded profile of the image) and then saving and sending it to you to see if the image looks correct to you in the Photoshop on your computer.
Thanks!
The images were fine before a typical reboot. After the reboot, I loaded Bridge so I could get back to work and as soon as the thumbnails loaded, I watched as each one of had the colors drained for them. Row, by row, like dominoes. My computer is brand new, and was built for me back in September. There was a couple of days, not long after I had started using the system, that the same issue arose. I nearly drove myself crazy then trying to get help...to no avail! And then as suddenly as I showed up, it was gone again. And I did nothing to the system whatsoever to "fix" it. I never removed anything, or added anything, and mainly because I couldn't find anyone to help me.
Unfortunately, the situation began October 27th and her I sit over 2 weeks later being held captive as I can sit and see all the thousands of photos awaiting my attention, and there is nothing I can do about it. And for those of you who are photographers by trade, trying to explain to a client why I can't get their photos edited is about like you all (IT geniuses) trying to explain the intricate tasks of a motherboard. The only difference is that they've paid me with their hard earned dough.
Before, the issue occurred on the 27th, I had never changed anything in regards to color management on Window 7. I had not even looked at the the color management setting within the control panel. Below is a screenshot of when it occurred back in Sept. Oddly enough, the desaturation only occurred in LR, and PS. Camera Raw and Bridge we fine.
at 
Hello Mjorts,
Sorry guys, I'm totally stumped.
Well if you don't know what's going on, how can we? 
Thanks! Good luck with the investigation, too! If I learn anything new I'll let you guys know.
I believe after reading this and my previous post, you are back to the game and have to report something to other resorts. Or you are telling us, that all this are not bugs but wanted features 
After reading Connie's last post and about test she did on a MAC, I did some further tests as well.
AFAIK Connie is on IMac now (@Connie, correct me, if this is wrong) which I believe is non wide-gamut. Which would mean she's back to the sRGB world and in this tiny world, everything seems to be okay. 
When I understand her last emails right (she might being cut from internet for a while, because she's on a MAC now), she asked her computer technician to reassemble the whole PC, check it and assemble it a again. Hopefully she also asked him to install W7 from scratch as I adviced her, just to eliminate the last possible source.
Even when I don't believe its an OS/system wide issue anymore.
Because I was able to reproduce what Connie gets with WSC & Adobe on a Dell U2410 wide-gamut monitor, as well on a Samsung non wide-gamut monitor at least for NEFs. Of course on the latter it is not that obvious, but since the Samsung covers a color space which is - regarding the reds and yellows - 85% larger than sRGB, a desaturation within reds happens there as well.
Which is normal when sRGB were processed on a non wide-gamut and viewed on a wide-gamut monitor.
I feel I have to explain why I wasn't able to reproduce the issue so far: I did my previous tests mostly with Canon CR2, on which the difference between ACRs "Adobe Standard" and its "Camera Standard" profile is not that big like it is with NEFs.
By this it wasn't obvious to me what happens to Connie and her NEFs.
- Seems ACR applies "Adobe Standard" to the previews in Bridge.
Seems Connie shoot some or lots of her images with Nikons color styles / presets, f.e. with Mode3 or Vivid. But ACR always applies the Adobe Standard profile - which is the primary source for the desaturation of NEF files on a wide-gamut monitor when using ACR.
This might not happen when using the Nikon Capture NX/NX2, which might automatically recognize the camera styles, but I'm not sure about that.
This original NEF was shoot with Mode3, the preview in Bridge should come close to the second image which is the embedded, but untagged JPG.
I guess Connie (like myself, who as said shoot Canon and Oly) wasn't aware of this circumstances.
- Since ACR provides camera profiles with the latest ACR versions, why not assigning at least the "Camera Standard" for all cams instead of assigning something like "Adobe Standard" in Bridge and ACR?
Here's a video recording of that and what I believe Connie encounters (more or less) - compare the camera styles to how the original looks in Bridge:
You might need to watch it on youtube, switch to HD and then fullscreen (the icon to the very right) to see it clear.
I pointed Bridges cache to my slowest disks and the recording software eats performance as well, so the changes happening by creating the sRGB JPEGs for the cache, interpretating ACRs color styles and applying the monitor profile, is very good visible in the recording.
Which was called as "suddently dropping" colors in the past by Connie.
Note: as long you don't see a small red "star" in the middle of the blue circle, I'm only pointing to an image, not clicking/selecting it.
Mind the bug at the end: when Bridge is minimized to the taskbar and is revoked, it shows the cached sRGB image, without loading / applying the monitor profile. Some need to take action by clicking around or refreshing the screen, in order to apply the monitor profile. I pointed to the womans hair to show the difference.
I saw a thread somewhere in the Adobe Forums (might be the Bridge forum) where someone was complaing about that as well.
But all this does not explain why Connie's other images (JPEGs and PSDs) appear desaturated as well.
I believe Connie was used to a sRGB monitor (and/or a workflow set to sRGB) and when switching, she might have mixed this and that up (converting to, assigning only or saving without a profile) - which is not necessarily her fault.
Why f.e. LR per default works in ProPhoto respectively in Melissa space? I myself use to work in ProPhoto, but I'm aware that I work - more or less blind - on colors my monitor can't display and my printer is not able to print.
She also might have converted back and forth between color spaces, not noticing this and not being aware about the consequences while in a sRGB workflow. But now - on a wide-gamut monitor - she IMHO gets the bill for that. Unfortunately.
For the following please read my previous post.
When Bridge was fed by an image with a ProPhoto space via its cache, it shows desaturated previews:
Bridge, PS, MB, and in the background the same image in Dopus, an unmanaged FileBrowser.
But the same JPEG which was converted to ProPhoto (to the right) and I fed Bridge with, is shown OKAY in IMatch, which is fully color managed.
Why I see it desaturated in Bridge and MB?
The only chance I see for Connie when she wants to stay on W7, with a wide-gamut monitor and with Adobe products, is to load every single image as unmanaged to PS and convert it to a profile which gives her the wanted result.
A bit of a life's work when you have more than ~100.000 images
btw:
There is another bug with ACR, not sure if its known already:
Set ACR settings to Camera Raw Database.
Take a RAW, make copies of it (either in explorer or by "duplicate" in Bridge) and assign an arbitrary ACR setting to one. Watch what happens to the other copies in Bridge - you might have to clear cache - or reload Bridge.
Its settings are applied to all copies of this RAW.
When using XPM sidecars, they (the development settings) are nicely kept seperately.
ACR should work with the filename, not by reading the asset name or the "original RAW" name from - how I assume - EXIF or XMP.
I consider this as a serious bug.
This is too much information and too many variables for me to invest in reading through all of this. I'm sorry.
No problem.
It was a hard job to investigate and put that together.
Why don't you post your Bridge issue in the bridge forum and your ACR issue in the ACR forum and see if someone with more expertise in these areas gets back to you?
Me?
Thanks, I don't have any issue and I for sure don't start over in another Forum, just for being asked, if my system is calibrated, if Firefox is showing the same than Bridge, to load an image with a cross profile, etc. pp. 
Personally I don't even use Bridge, because for a simple image lister which it is on its best, it eats far to much memory and CPU performance and is unreliable. If i would need to decide about a DAM, than it would be Cumulus anyway.
But I learned some important things for my company, f.e. that I can't provide Bridge's cache on f.e. a SAN, because color management is applied when cached images are generated. Which means that the appearance of the cached images not only is system specific, but specific to certain settings of a system.
Even on a single user desktop this means, that the cache have to be purged from time to time, f.e. when changing monitor profiles or when a monitor needs to be exchanged (which happens more often in a company than in a private household), otherwise I'll have different appearances in Bridge, MB and PS.
Another lesson I learned by this was that often (not always) Bridge crashes, when the monitor profile was changed. Than the cache have to be purged as well.
I also encountered the ACR Camera RAW database bug and I know how to avoid it, even when I believe xmp files are a pest.
But I thought at least the latter would be somehow interesting for the Adobe developement dep. and / or quality management. Even when here is not much knowledge present, about how other parts of the CS suite are working, I believe/hoped communication between this (any) forum and the other deps. should work without further assistance. If I would be an executive I would demand that from my employees.
As a customer who have a real problem (homebreewed or not) like Connie, I would feel dispatched in its bad meaning. "Not my responsibility" please go => somwewhere else. Sorry.
Should be easy to check if this are (known) bugs or features (I believe Adobe use a bugtracking system like bugzilla or similar) or pointing Bridge Forum mods to this thread simple by an email.
ps
the last two images in my former post are not shown / were deleted. Just to keep the thread consistent, here they are again:
CM.jpg
imatch.jpg
Of course (for anyone following this thread), WHACKED RGB is an even more dramatic tool to troubleshoot this type of problem (I just added a Whacked RGB print resolution file to my above download link):
Tagged with embedded profile WhackedRGB.icc:
Exact same file except its embedded profile has been stripped:
If you are using a color-managed Web browser the difference between tagged and untagged should be dramatic (very bluish)...if you are using an unmanaged browser, both files will look exactly the same (because they are both having the same default profile applied).
My point is: drop these files into your problem apps and see what's going on...
Yeah, nice play with the cross color space images, but with all respect gator, you should have read the whole thread. 
Connie's problem are not non color managed apps, her problem are color managed apps (especially Adobe apps), respectively those who pretend they are.
Bridge f.e. is not CMed; not in the sense PS is.
For the following test you need to have a wide-gamut monitor with a generic or profiled monitor profile loaded.
You won't see much of a difference on a non wide-gamut monitor when going through this:
Make yourself a new folder (for example Gator) and put a RAW to it. Open Bridge and develope the RAW as you like. Leave it open in PS. Open MiniBridge and make sure the color management is enabled in its preferences.
You'll get something similar like this:
What you se is a NEF (DSC_4051.NEF) with ACRs "vivid" camera preset assigned, developed to the ProPhoto Colorspace. PS/MB/Bridge.
Now edit the image in PS, resize it to a width with is similar to the width of your monitor. Make it 8 bit or when on CS5 just save it as JPEG. Make sure its name is like that of the full RAW image name, including the suffix (NEF or CR2, etc) => f.e. imagename.NEF.jpg. For the NEF shown it should be saved as DSC_4051.NEF.JPG
Find your Bridge cache folder. In there, below \1024, you find a folder which starts with "Gator...." f.e. P:\Bridgecache\1024\GatorCC153054. Copy the saved image to it. Wait a bit or close and restart Bridge, but don't purge cache.
You'll get something like this:
What happend? Seems Bridge always assumes that it would be fed with sRGBs. Of course it does so, because an engine (or Bridge itself) in the background interprets the images (NEF, PSD, etc. pp.), means its assigns ACR settings respectively the camera styles, assigning the monitor profile to it and saves all that as a JPEG in sRGB in Bridges cache directory.
IMHO. I might be wrong here regarding the details - so please understand this and the following statement as assumptions...
Bridge than is reading its cached sRGB and assigns monitor profile again (?) - I can't tell at the moment and have to think about this - but its obvious that something strange is going on here ....
Anyway. Per default there are two cached previews for Bridge, a third will be generated when you switch to full screen preview and zoom in.
Since we only exchanged the 1024px preview, you will see different previews when switching to full screen or, when f.e. in filmstrip, you minimize the previews until those cached images from the /240 folder are used.
Now assign the monitor profile to the image in PS:
Close, but the MB preview still looks different. Not sure if this is visible on every monitor: the MB preview in the middle has a "colder" apperance, compared to what is seen in PS and Bridge.
Now click on the most upper part of the MB window and hold it or move the window a bit and you get this:
Now the "warmth" is almost the same on all previews. As soon you lift your finger and release the MB window, it is back to the colder appearance.
So taking all this together, can we tell this is a consistent and reliable color management? So far I believe not - haven't even checked yet, what LR is doing on this...
What happens to images which previously were processed on a "normal" sRGB and the cache never was rebuild? And even when the cache was purged after a new monitor come into place and a monitor profile was assigned, what happens to images developed to the ProPhoto color space, but saved without an embedded profile and for a some reason have been tagged as sRGB or aRGB?
Which can happend, we never know what developers do assign or do forget to remove, right?
I'm talking about the "InteropIndex" here. When this EXIF tag is set f.e. to sRGB or aRGB (no embedded color profile) but the image was developed f.e. to ProPhoto, Bridges metadata view shows that the image is in sRGB and of course it shows it desaturated as well 😞
AdChoices