Changing gamut creates horrible reds

[matthiassebas]

When exporting photos from LR after editing in PS reds can go wild. This can happen directly when exporting into sRGB or later when exporting into AdobeRGB when uploading to my website. Is there a science to managing these colour changes even during retouching? Thanks for any help!

See attachement and description in a post below.

[matthiassebas]

Re: Changing gamut creates horrible reds

Please help!

[mistermonday]

Re: Changing gamut creates horrible reds

It sounds like you are not implementing Color Management properly.
Take a screenshot of your Color Settings in PS Edit>Color Settings and post it here.
As you hand off a file from LR or ACR tp PS, you need to respect or convert the color profile is the two applications are working in different color spaces. Other wise the colors will appear way over saturated or way under saturated. Similarly when you save an image from PS to be displayed on the Web, you need to make the appropriate conversion because most web browsers do not have color management and are expecting a file that is equivalent to sRGB.
Cheers, Murray

[matthiassebas]

Re: Changing gamut creates horrible reds

Thanks Murray I so glad you replied to my post!
I am organising my photos in LR and I am editing them in PS. Only when I am exporting the files from LR into sRGB jpgs colours can go wild or when I am exporting them into AdobeRGB jpegs can go wild after being uploaded to the web. Please find screenshots of all colour related settings in LR and PS (that I am aware of) below.

Many thanks!

Cheers Matthias

[andrewrodney]

Re: Changing gamut creates horrible reds

Doesn’t sound right, the differences should be pretty tiny. You have LR, soft proof using sRGB, what do you see there?

[matthiassebas]

Re: Changing gamut creates horrible reds

In LR turning on and off soft proofing doesnt have a visible effect. On another note in LR while soft proofing I have two options how the conversion to sRGB should be handled that is perceptual and relative conversion. Nevertheless during the export into jpeg I can only select the target colour space (sRGB).

[Tony W]

Re: Changing gamut creates horrible reds

Something does sound odd, the colour red for instance, I have seen this when assigning an sRGB image to Prophoto by mistake, but not sure that if you were bringing in a Prophoto image to an sRGB working space which way the colour would go.

When you have your image in PS what happens when you go to Edit/Assign Profile – what does the profile say for Working RGB ? and what happens if not already sRGB you click on the Profile and change to sRGB?

Are you sure that you should be converting to Adobe RGB for your web work as I would have expected sRGB?

I would suggest you try the following:

• In PS colour settings change the working space from sRGB to Prophoto. This then effectively matches the working space of LR and is the space you have set for LR external editing.
• IMO you should also turn on the profile mismatches in this dialogue box as this will warn you when opening or importing an image that there is a mismatch and give you the opportunity to decide what to do with the image so that it displays correctly.
• Your proof settings in PS should normally be those of the paper you intend to print on not your monitor profile. If you want to simulate how a print will look when sent from PS then you would select the correct paper profile e.g. using an HP printer and glossy paper the profile may be named something like HPAdvancedGlossy.

[andrewrodney]

Re: Changing gamut creates horrible reds

In LR turning on and off soft proofing doesnt have a visible effect. On another note in LR while soft proofing I have two options how the conversion to sRGB should be handled that is perceptual and relative conversion. Nevertheless during the export into jpeg I can only select the target colour space (sRGB).

If you don't see it there, something's off with either how you're exporting or how the new data is interpreted. Again, check all the settings.

In soft proof, using simple RGB working space profiles like sRGB, you have two options for rendering intent but the profile only has one table. So it doesn't matter, you'll end up with the same results.

[matthiassebas]

Re: Changing gamut creates horrible reds

I am so sorry...it seems i am a bit slow

LR: when exporting via FILE>EXPORT>FILE SETTINGS I can only select the target colour space e.g. sRGB but I dont see any options that influence how the conversion is performed. Also in LR if i use soft proofing with a target output colour space set to sRGB and I dont see any effect on the screen.

Nevertheless when in

PS: I have selected the settings as in the screenshots attached and if I then turn on and off VIEW>PROOF COLOURS with the settings as in the screenshots then I have a massive effect that I dont understand.

[matthiassebas]

horrible reds after export

Attached is an example showcasing the horrible reds after export. This is a picture that was before edited in PS.

Right: LR displays photo using Soft-Proofing::ON with Profile::sRGB Intent::Perceptual.

Second from Right: Preview displays same photo stored on the HD after export with Settings ColourSpace::sRGB, ImageFormat::JPEG, Quality::100

Third from Right: Safari displays same photo stored on the HD as above.

Left: 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.

I thought when exporting in sRGB the browser should display the photo as LR does it in Soft-Proofing with Profile::sRGB or when Preview displays the same file. Here this is obviously not the case.

PLEASE PLEASE HELP.

[Tony W]

Re: Changing gamut creates horrible reds

It looks like you use a Mac and although I imagine that there should be very little difference between applications across platforms there could be specific things that I am missing as I am a PC user.

It is not 100% clear to me your workflow sequence and where the real problems lie. Maybe I have misunderstood the post but originally it seemed that your main problem was you exported your files from Lightroom as jpeg sRGB and when you viewed in PS you get a shift to Red is that correct?

When you get the red image in PS have you checked the profile is actually correct? Goto Edit/Assign Profile and look in the dialogue box - next to profile it should say sRGB if the imported file is tagged as sRGB. If it is anything else then try changing it to sRGB.

Although at odds with your sceen shot settings it looks very similar to assigning a Prophoto space to an sRGB image. If you look at the 4up image of the wooden owl the bottom images left is an sRGB version and the right is the image when assigned Prophoto. The colour change looks very similar to what you are experiencing? The top images show the original left in my pref. working space Prophoto and what happens if the image is assigned as sRGB.

IMHO it is good practice to synchronise your workflow settings between LR and PS, in my case I choose Prophoto but if you only want to work in sRGB then I would suggest that you should also set up LR for external editing in that space. You will see my settings for PS and LR are both the same in the attachments. It also means that if I right click an image in LR and select edit in PS that the image opens correctly without any warning dialogue boxes and I do not have to go through the export process.

With soft proofing you would expect to see differences between your original and you proof depending on profile. It is possible that the differences are slight that you are not noticing when changing if you view as a single image. So I prefer to set up LR as in the attachment showing two windows the left being the original edit and the right being the soft proofing window with the correct paper profile selected. You might want to look into using create virtual copy in softproofing.

I cannot comment on the views in Safari browser as I do not use this application but AFAIK it is or should be a colour managed application. If it is not or colour management is turned off this could account for problems with colour display being incorrect. I am fairly confident that the browser will expect an sRGB tagged image or assume this to be the case for an untagged image.

[andrewrodney]

Re: Changing gamut creates horrible reds

Safari is ICC aware. IF the images have an embedded profile, they will preview like Photoshop and LR. IF no embedded profile, the display profile is assumed (which could be the wrong assumption).

Just work on getting LR and PS in sync color wise and don't bring browsers into the equation just yet. When settings are correct, IN Develop at 1:1, the color should appear the same there as in Photoshop!

You either need to check the current Export Preset or your preferences for Edit in Photoshop (or external editor).

[Tony W]

Re: Changing gamut creates horrible reds

I revisited this as I had some thoughts about possible causes of the problems.

My guesses are:

• You are embedding an incorrect profile i.e. a display profile
• You are using a wide gamut monitor
• Your monitor is incorrectly/not calibrated

The reason for my guesses is that copying and saving your attachments and bringing into PS the image shows an embedded profile named 'Photography' where I would expect it to say sRGB **** or any other RGB flavour.

I suspect this profile name is caused by setting and saving your image with one of your monitor display settings rather than the correct one e.g. sRGB, Adobe RGB etc. Consequently you are getting these strange results.

To prove this to myself -at least - I brought one of my attachments back into PS and assigned a display profile rather than an RGB. Bringing this into PS and choosing to not colour manage (Discard Profile) made the image quite red and therefore I think this likely to be the root of your problems.

[matthiassebas]

Re: Changing gamut creates horrible reds

Many thanks to mistermonday, TonyW and andrewrodney for the interesting feedback and your help and thoughts. In the last couple of days I have read all your suggestions and played around with the system and changed a lot of settings back and forth but unfortunately I wasnt able to find the problem.

Therefore and because the setup was too complicated (PS/LR/and the web all together) I started to reduce the number of components and did the following. But before I start let me describe the components that I am working with. I am working on an Eizo CG243W which is calibrated via a x-rite i1-Display-Pro using Eizos ColorNaviagator-6 software on a mac. The name of the display profile is 'Photography'. The mac is actually a macbookpro and its display is calibrated via the i1-Profiler from x-rite.

Here comes the simplified test. I loaded a .CR2 into photoshop/Camera Raw and saved from this photo a tight crop as a .TIFF encoded in ProPhoto-16bpc. I converted this .TIFF file from ProPhoto-16 to sRGB-8bpc (not using Assign-Profile but using Convert-to-Profile and converting 16bpc to 8bpc using the Image>Mode command) and used the save-as command to save 2 versions of this file. In PS the conversion did not change colours. One version was saved tagged/with profile (sRBG8bpc_wProfile.jpg) the other version was saved untagged /without profile (sRBG8bpc_woProfile.jpg). Both files are attached.

Before converting the .TIFF to sRGB I used the proofing mechanism in PS to check for out-of-gamut colour changes. No colour change was visible. I used the best .jpeg quality on export.

Now I tested the appearance of these two files in Safari, FireFox, GoogleCrome and Mac::Preview. The result was always the same. The tagged version appeared colour wise ok. The untagged version looked very very reddish. The difference was not at all subtle. Please see screenshot. (Yes, the screenshot is tagged with the profile 'Photography' but why would this be odd? This is a screenshot of an output device that uses a profile with this name.)

Now I uploaded the two files into the web and checked the appearance again on four different monitors. On the Eizo and on the LCD of macbookpro driving the Eizo the untagged photo was still very very reddish but the tagged photo was OK on both screens. Nevertheless on two other macbooks the difference between the tagged and the untagged picture was tiny! One of the other macbooks was calibrated too but as I mentioned there was almost no difference between the tagged and the untagged version on the two other macbooks.

Because I saw the effect (very reddish untagged version) on the wide-gamut display (the Eizo) and on a non-wide gamut display (the LCD of the macbook) the effect isnt a wide-gamut effect. Also I made sure that the conversion from ProPhoto to sRGB was correctly applied for both files. Therefore this cant be the effect of a wrongly applied profile e.g. a monitor profile. On 2 other macbooks the effect is tiny. Hence the effect seems to be relevant only to the macbookpro connected to the Eizo on which I run photoshop.

I always assumed that an untagged photo in a browser was treated as a sRGB-8bpc. Given the results (see screenshot) this must be wrong.

Could somebody please explain? Any ideas?

Screen shot 2013-05-05 at 18.53.09.png

[andrewrodney]

Re: Changing gamut creates horrible reds

Now I tested the appearance of these two files in Safari, FireFox, GoogleCrome and Mac::Preview. The result was always the same. The tagged version appeared colour wise ok. The untagged version looked very very reddish. The difference was not at all subtle.

At least in Safari, all untagged documents use your display profile to assume the color space of the data. But it's not in the color space of your display, it's in sRGB! Hence the disconnect.

All these browsers at least today are doing this wrong IMHO. They should allow the user to either select the assumption for untagged data, as we have in say Photoshop or just force the issue and assume sRGB. In the old OS9 days, that functionality was available.