I am organising my photos in LR and I am editing them in PS. When I am exporting from LR into sRGB jpgs colours can go wild. See attachment.

ATTACHMENT ONE (Numbering from right to left!):

FIRST: LR displays photo using Soft-Proofing::ON with Profile::sRGB Intent::Perceptual.SECOND: Preview displays same photo stored on the HD after export with Settings ColourSpace::sRGB, ImageFormat::JPEG, Quality::100THIRD: Safari displays same photo stored on the HD as above.FOURTH: Safari displays same photo after upload into the web.

Obviously in this example there is a massive colour change from the picture displayed on the right to the pictures displayed on the left. In this example the colour change happens while viewing the same file via different software here Safari compared to Preview. Even if the file was exported into sRGB a massive colour change happens. WHY?

ATTACHMENT TWO AND FOLLOWING:Colour gamut export relevant settings in PS and LR.

Thanks for the link. Unfortunately I am using a EIZO Colour Edge wide gamut monitor. Is there a shortcut to reading all of that?

Your screengrabs have the wrong display profile embedded in them which suggest your system isn't using the required custom calibrated display profile. Where does the profile "Photography" come from/located on your system?

You need to read up, seriously, if you don't even know you're suppose to be using a custom display profile on a wide gamut display as an Eizo.

See below what I get from your screengrab opening in Photoshop. Not a good sign color management is working as it should under the hood and especially in Safari and Lightroom which are color managed.

@tlooknbill: I am using i1-Display-Pro from x-rite with Eizos Color-Navigator-6. Photography is the name of a predefined calibration target in Color-Navigator-6 which I have used to create the profile. The profiles location is: Library/ColorSync/Profiles/CG243... . I added the screenshot to give a visual motivation.

@digitaldog: I cant see the problem with my settings. My understanding is that for web publications encoding in sRGB-8bpc untagged is the standard. With these setting I uploaded the photos to PS only to export them later to the web. I am sorry if I didnt explain that correctly.

@digitaldog: I cant see the problem with my settings. My understanding is that for web publications encoding in sRGB-8bpc untagged is the standard.

I'd be hard pressed to use any such term as standard here <g>

I'd embed the ICC profile unless you're dealing with thousands of images whereby the extra 4k of data adds up significantly. Many ICC aware web browsers will recognize the embedded profile and use it, while if not found, uses your display profile for the assumption of that data. That would be the wrong assumption if indeed the data were in sRGB. So embed that profile.

Photography is the name of a predefined calibration target in Color-Navigator-6 which I have used to create the profile.

What happens when you assign (in Photoshop) your Xrite i1Display profile to your screengrab that has the embedded "Photography" profile? There should be no change to the preview if both "Photography" and your custom i1Display profile are one and the same profile your OS is using (which there can only be one) as well as Photoshop for delivering correct looking color managed previews. A predefined calibration target that is separate from an ICC i1Display profile is very unusual behavior for screengrabs on Mac OS X.

Mac OS X (unless they've changed things with screengrabs) always embeds (on my system) my i1Display ICC profile that has a custom name I gave it at the end of the calibration/profiling process. There's no option to assign any other profile be it a predefined calibration target or Standard RGB.

Whatever display profile that occupies the video card (and there can only be one) is the one Photoshop and all other color managed apps access to generate color managed previews. You are using two profiles in your system.

Your "Photography" profile just adds confusion in sorting this out from my experience. If EIZO has some different kind of routine for dealing with display profiles then this is beyond what I can help you with.

Below is what I get from your embedded "Photography" screengrab using both Colorsync's "Show Info" and "Extract Profile" scripts. Is Photography a REAL ICC profile?

When I assign the profile 'Photography' to the screenshot in PS colors dont change. I am only using one display/output-profile on the Eizo and this profile is called Photography. Please see screenshots.

Let's not dwell on the screen capture because at least I am not sure how you created it and IF the app that did this even embedded the correct profile. Let's stick with an actual image in a known RGB working space (sRGB, Adobe RGB etc). Note too, profiles more than one name so this too could add to confusion when dealing with the display profile depending on how it was built. The name seen in the CS utility shows 243W, could you have built that profile and named it Photography? Photography is the name of a predefined calibration target, but it has to be the name of some ICC profile for it to show up as it did in Photoshop's color settings.

What Tim is saying however is spot on, you do NOT want to embed the display profile into the document (unless it really was a screen capture after which you'd convert to say sRGB). That the assignment doesn't change the capture means it IS in the display color space.

@digitaldog:: The name 243W in the ColorSync Utility refers to the factory profile which is not in use. The name Photography in the ColorSync Utility refers to the profile that I have created with Eizos profiler called ColorNavigator-6. The software handles the profile and enables it. I have not copied display profiles. I was following a request by tlooknbill who wanted me to assign the profile Photography again to the screenshot. I have added the screenshot only as a visual motivation and didnt want to proof anything with it.

Let's not dwell on the screen capture because at least I am not sure how you created it and IF the app that did this even embedded the correct profile. Let's stick with an actual image in a known RGB working space (sRGB, Adobe RGB etc). Note too, profiles more than one name so this too could add to confusion when dealing with the display profile depending on how it was built. The name seen in the CS utility shows 243W, could you have built that profile and named it Photography? Photography is the name of a predefined calibration target, but it has to be the name of some ICC profile for it to show up as it did in Photoshop's color settings.

What Tim is saying however is spot on, you do NOT want to embed the display profile into the document (unless it really was a screen capture after which you'd convert to say sRGB). That the assignment doesn't change the capture means it IS in the display color space.

Andrew, has Mac OS X changed their screengrab profile embedding routines? If not, the "Photography" profile is getting referenced by the system as the system profile during a screengrab and it really shouldn't. And if so, then what are other color managed apps referencing as the system profile.

Matthias, how are you making your screengrabs? Command/Shift 4 or 3? or using another piece of software to do it.

Don't know, I don't ever use it (I use SNAPZ). What it feeds me is untagged so I use Hazel to Assign the display profile and convert to sRGB, works like a charm. IF the OS embeds anything, has to be the display profile.

Then your system is referencing the wrong display profile because when I do the same screengrab and open in Photoshop my custom i1Display profile is embedded. I tried to extract your "Photography" profile out of your screengrab and it's not even an ICC profile, in fact it's not even a profile at all as I demonstrated above.

I'ld suggest you go into Display Preferences and locate your custom i1Display profile and click on it to make sure it's being used as your system profile.

Other than what Andrew suggests I don't know how to solve your problem. I've never encountered anything like that on all the four Mac systems going as far back as 1998 when I first got into digital imaging and color management.

@tlooknbill: Sorry for any misunderstanding that I might have caused. Photography is the target in the profiler software and also the name of the profile that appears in the system preferences when I choose this profile. If you like I can upload the profile for you to have a look at it?

Also if you are using a wide-gamut display and if you are up for a quick test you could save an image in sRBG tagged and untagged and see if you see the same effect?

@tlooknbill: Sorry for any misunderstanding that I might have caused. Photography is the target in the profiler software and also the name of the profile that appears in the system preferences when I choose this profile. If you like I can upload the profile for you to have a look at it?

Also if you are using a wide-gamut display and if you are up for a quick test you could save an image in sRBG tagged and untagged and see if you see the same effect?

Not necessary to provide the "Photography" profile because it's clear what's getting embedded in your screengrab is basically a "point to" Linux style 'alias' type file most likely I'm assuming to prevent extracting from downloaded screengrabs. It appears Eizo's Mac system integration is a lot more sophisticated than I want to deal with.

Anyway, whatever's going on with your screengrabs it doesn't seem to have anything to do with solving your issue. I know it's over my head. Maybe Andrew's advice is the direction you should take.

Unfortunately the problem seems not to be a handling error. Instead it seems to be an effect connected to driving a wide and a standard gamut monitor from a Mac at the same time when handling untagged sRGBs.

Tests before showed that sRGB-8bpc files in Safari (and other browsers) displayed a heavy red colour cast if untagged on the MacBook Pros LCD (sRGB gamut) and on Eizos CG243W (wide gamut).

From my point of view this result was not in line with the explanation Safari assigns the display profile to the untagged file as in the case of the sRGB display this shouldnt result in a red colour cast if the profile of the sRGB device would have been assigned.

Nevertheless Rob Griffith suggested to test with sRGB-8bpc files tagged and untagged with the Eizo CG243W attached and also detached from the MacBook Pro.

As before in this test the red colour cast was visible on the MacBook Pros LCD as long as the Eizo was present. Nevertheless after a restart and detaching the Eizo the colour cast was gone on the MBPs LCD!

Also reattaching the Eizo via Thunderbold after the MacBook Pro was started without it (not showing the colour cast) introduced the colour cast on both displays upon moving the files once onto the Eizo!

So it seems that the presence of a wide-gamut display can change the behaviour of a sRGB display device also connected to a Mac wrt displaying untagged files.

Also it brings in line the explanation that Safari might not handle properly untagged sRGBs on wide-gamut displays because its stretches sRGBs to the gamut of the wide-gamut display (or via a similar mechanism e.g. tagging the file with the profile of the wide gamut display which might result in the same effect) and by doing so introducing the red colour cast. My understanding is that this is what digitaldog and Rob Griffith (via phone) have explained.

Many Thanks to tlooknbill, digitaldog and Rob Griffith and all the others who helped.

Upon uploading images to the web they might be modified, compressed and or stripped off the ICC profile for efficiency reasons. These modifications can be out of the control of the user.

I experienced colour changes after uploading pictures to the web which where exported from LR and were looking swell after uploading as they came out with this red colour cast. I checked that LR is exporting pictures in JPEG tagged.

My understanding is now that the website stripped the profile from the picture when resizing it and by that procedure the colour cast was introduced. That is also in line with my experience that if the picture was exported in 70% JPEG (smaller) and in the target dimension most of the time no colour cast was introduced.

Actually this was the reason why I started this thread: A strong red colour cast on some pictures that I viewed on the web.