Color changes between develop and Web Module (darker, redder, contrastier)

[shermanphoto]

I build a web gallery for every job, after making adjustments and when I switch to that module everything becomes darker, contrastier, muddier and redder.

It's a real hassle.

I just updated to the new version 8  but it happened in Version 7 too.

I trashed prefs, rebuilt monitor profiles and rebuilt previews.

None had any effect

Anyone know the answer to this?

[TheDigitalDog]

https://forums.adobe.com/people/Bob+Somrak  wrote

Maybe things have changed with Mojave but on High Sierra and Lr 8 the Web module is only PARTIALLY color managed for me.

Same test, Lightroom 5, Left Library, right Web:

[Bob Somrak]

thedigitaldog​

See this thread and links in the thread.

Re: Photos in Web more Saturated than Library and Develop.

[TheDigitalDog]

https://forums.adobe.com/people/Bob+Somrak  wrote

thedigitaldog

See this thread and links in the thread.

Re: Photos in Web more Saturated than Library and Develop. 

As outlined, AS TO BE EXPECTED.

You want to view the images correctly, read what Adobe writes about the Develop module AND the zoom ratio.

I'm not making this up.

Do I have to ping Eric Chan or Thomas Knoll to back up what Adobe itself states clearly in the URL I provided?

[Bob Somrak]

You apparently didn't read the links in the thread I posted with comments from Adobe personnel. 

[TheDigitalDog]

Apparently you didn't view the Library and Web matching and the question I asked: do you believe Library module isn't color managed?

[Bob Somrak]

thedigitaldog  wrote

https://forums.adobe.com/people/Bob+Somrak   wrote

thedigitaldog 

See this thread and links in the thread.

Re: Photos in Web more Saturated than Library and Develop.  

As outlined, AS TO BE EXPECTED.

You want to view the images correctly, read what Adobe writes about the Develop module AND the zoom ratio.

I'm not making this up.

Do I have to ping Eric Chan or Thomas Knoll to back up what Adobe itself states clearly in the URL I provided?

Perfect example of Partial color management in the Web Module

[shermanphoto]

I read it and they were aware of the issue 2 years ago and it still exists in the latest release. I have done further a/b testing today and the uploaded galleries are much closer to the color/contrast of the develop module than the web module but not exact.

Silly me, to think they should look good in the web module. If I generate and load a "we preview" action it looks more accurate but who has the time to do that when working a job?

Stephen

[TheDigitalDog]

shermanphoto  wrote

I have done further a/b testing today and the uploaded galleries are much closer to the color/contrast of the develop module than the web module but not exact.

In Develop, you set a soft proof for sRGB?

[shermanphoto]

No, I am trying it now, good catch !

[shermanphoto]

Just tried it, still quite different

[TheDigitalDog]

You can't soft proof in web module. What I was wondering is IF the uploaded image from LR, in a color managed browser matches the preview in Develop when soft proofing is on for sRGB. And again, ideally, you'll view the two at the same zoom ratio at 1:1.

[D Fosse]

As I never use the web module I haven't followed this discussion.

But now that I take a look, it's clear that this is sRGB data straight to wide gamut display - it's all oversaturated in the familiar way we know from non-color managed software.

Could this be a MacOS vs Windows thing? MacOS has a color management hand everywhere; while Windows is strictly hands off. If the application doesn't do it, it doesn't happen.

Apologies if that's already been covered upthread

[johnrellis]

Could this be a MacOS vs Windows thing?

No, the bug report shows the behavior occurring on Mac.

[TheDigitalDog]

johnrellis  wrote

Could this be a MacOS vs Windows thing?

No, the bug report shows the behavior occurring on Mac.

Not on my Mac. I've provided numerous examples of this. For LR5 up to LR8.

As for the bug report (and I couldn't find it when I searched), you're telling us it's 2 years old. That says something....

And yes, I've asked in the 'right area' about this and as yet haven't heard back from anyone on the LR team.

The facts are, the 'bug' doesn't show up for me. And I suspect others too. That doesn't mean there isn't a bug. It may have absolutely nothing to do with LR and Adobe. Hence, we need MORE data from users who see this issue, as I asked about above.

But stating that the Web module isn't color managed simply isn't correct. It is. It may be buggy but it's also color managed. Saying it isn't, or saying it's 'partial' color managed doesn't help because I've shown it is (it matches Library perfectly) and there is no such thing as 'partial color management'. It either is or it isn't. Bugs not withstanding.

I can show you a bug in Photoshop with the Gamut Overlay. It's a bug but that doesn't mean the Gamut Overlay doesn't work. Same with color management in Web. Once we get past that silliness, we might find out what's going on with SOME users where Library and Web do not match.

[Per Berntsen]

thedigitaldog  wrote

The untagged JPEGs in Adobe RGB (1998) or worse, ProPhoto RGB should look desaturated in LR without an embedded profile because it assumes sRGB. You can see the same effect in Photoshop assigning sRGB to the Gamut Test File as I showed yesterday.

ProPhoto without an embedded profile does look desatured in LR (develop and library), but the saturation increases in Web.

OVER saturated would be an sRGB imaged, assumed to be in ProPhoto RGB (or something wider than sRGB). Easy to test, take the Gamut Test File which is in ProPhoto RGB and duplicate it. Convert it to sRGB. Assign sRGB to ProPhoto. Assign ProPhoto to sRGB image. You see this: (ProPhoto right, sRGB left):

Yes, this is exactly what I see.

To answwer your questions:

1. Your OS and OS version as well as the version of LR.

Windows 7, Lightroom 7.5

2. What products you use for the creation of the ICC profile. What settings are used.

ColorMunki, using Eizo's Color Navigator, version 2 matrix (gamma curve) profile

3. What kind of display system: wide gamut, sRGB like gamut, and if it's the kind of unit, like mine (NEC SpectraView) where the calibration takes place in the panel, not via the ICC Profile LUT.

I use an Eizo CX 240, wide gamut. Not sure if the calibration takes place in the panel.

4. Can you confirm or deny that in Develop, when soft proofing to sRGB, that preview and your web images (in a color managed browser) match or not?

When I soft proof the test file to sRGB, it becomes desaturated.

When I view an sRGB jpg in a color managed browser, it's identical to LR Develop soft proofing to sRGB.

[TheDigitalDog]

https://forums.adobe.com/people/Per+Berntsen  wrote

4. Can you confirm or deny that in Develop, when soft proofing to sRGB, that preview and your web images (in a color managed browser) match or not?

When I soft proof the test file to sRGB, it becomes desaturated.

When I view an sRGB jpg in a color managed browser, it's identical to LR Develop soft proofing to sRGB.

This is potentially interesting and useful. Again, you've got an sRGB image and when you soft proof it, it looks less saturated?

That shouldn’t happen.

The Gamut Test File in ProPhoto RGB, soft proofed to sRGB would appear in some areas, less saturated; all the colors that fall outside sRGB but within your wide gamut display. But the sRGB softproof and the sRGB upload match; that's expected and good.

[Per Berntsen]

thedigitaldog  wrote

This is potentially interesting and useful. Again, you've got an sRGB image and when you soft proof it, it looks less saturated?

No, it's the original Gamut_Test_File_Flat.tif in ProPhoto soft proofed to sRGB.

[TheDigitalDog]

https://forums.adobe.com/people/Per+Berntsen  wrote

thedigitaldog   wrote

This is potentially interesting and useful. Again, you've got an sRGB image and when you soft proof it, it looks less saturated?

No, it's the original Gamut_Test_File_Flat.tif in ProPhoto soft proofed to sRGB.

OK, got it.

I still don't understand how this is happening however:

The jpg with ProPhoto embedded displayed over saturated in all of them, and they all displayed exactly the same as Lightroom Web.

Should be the opposite as shown above.

[D Fosse]

At this point, I think two things. One, using untagged files here is throwing a wild card into the mix, likewise assigning the display profile. We know what that both of those do in a normal color management chain. It either breaks the chain, or nulls it out. We don't need more unknown factors, we need less.

I think we should stick to properly and correctly tagged material, just to keep variables down so that we can identify what is actually taking place.

Second - and this is just my personal feeling and opinion - these already highly saturated test images make it difficult to see what's going on. It confuses and overloads the eye with redundant information. It's much more immediately obvious with "normal" images, with colors that people can recognize from memory.

I can't explain why some see it and some don't. From where I sit, this is consistent and unambiguous.

[Todd Shaner]

https://forums.adobe.com/people/D+Fosse  wrote

I can't explain why some see it and some don't. From where I sit, this is consistent and unambiguous.

Dag, I see it exactly as you and John Ellis have described. The Web module is only partially color manged:

1) Displays image using the embedded color profile or assumes sRGB when image is untagged.

2) Outputs image to screen using sRGB display profile and NOT the OS assigned display profile.

Windows 7, NEC PA272w wide gamut monitor, Spectraview calibration, LR 7.5

[TheDigitalDog]

https://forums.adobe.com/people/D+Fosse  wrote

At this point, I think two things. One, using untagged files here is throwing a wild card into the mix, likewise assigning the display profile. We know what that both of those do in a normal color management chain. It either breaks the chain, or nulls it out. We don't need more unknown factors, we need less.

I agree. What I wanted to do was two fold.

1. Show that the Web module IS color managed. It's also super buggy. I'll come back to why that's important to consistently state.

2. I wanted to wrap my head around what's going on. I still can't and went to bed with a 4 Aleve headache. It's been stated that the module treats everything as sRGB and doesn't use the display profile. With the Gamut Test File, that doesn't show and one reason I've used it along with the Roman16's in (this case) Adobe RGB (1998). If anything, The Gamut Test File appears if it the profile is stripped, it's assumed to be ProPhoto RGB assigned sRGB but I can't get that to match either. ProPhoto RGB appears MORE saturated which is the opposite of what we'd see with no color management of that tagged data.

Now how to move on? I've submitted an internal bug and can't say much more publicly.

This issue has been around since version 5, maybe earlier but version 5 is the oldest I have running and the bug sometimes shows up and based on the gallery which is even more odd. I wasn't aware of this bug and I can't find any old bug reports other than what is the 'public' bug area. Considering this bug has existed this long, I wouldn't hold my breath waiting for a fix.

So there are two ways to look at this issue. One from a software engineering team and one from the user. The engineering team probably would tell you: that what's the big deal? You edited the images previewed correctly in Develop, the uploads are correctly color managed, all the Web module is for is to place the images. You could do that in grayscale. The user (and I'm one) would state that Adobe put color management on the map in 1997, this is an ugly bug and it SHOULD be fixed.

Where that leaves us is containing to yell and post reports after every update. But again, don't hold your breath, it could be a waste of your time. Doesn't take much time but what else can you do?

Now when yelling, it doesn't help one bit to state: The web module isn't color managed. It is, and the preview path is super buggy. I've worked with enough Adobe engineers (since version 2.5 of Photoshop) to know what not to say. Stating the "module isn't color managed" will fall on deaf ears. It will largely be dismissed immediately. Perhaps saying "the web module's color management preview architecture is buggy" will too, but at least it's framed correctly. It will not be ignored at the get go like the other statement.

Adobe knows about this bug. How long? I can't state. It may never be fixed. It may be fixed at the next update or in 5 years.

My plan is to file an internal bug report every build I see this bug. And on the public site too. I don't understand why some images preview as they do on certain displays and I'm pretty sure stating "[The Web module] uses a photo's embedded profile but assumes incorrectly that the display's profile is sRGB." is wrong and doesn’t aid the cause.

Getting Adobe, among other's to fix stuff takes a bit of finesse at step one. I came into this based on a statement I still believe isn't correct about a lack of color management in the Web module. But I'm very certain now, headache or not that a bug exists.

[Per Berntsen]

thedigitaldog  wrote

This issue has been around since version 5, maybe earlier but version 5 is the oldest I have running

I happen to have version 2.7 installed, which displays correct colors in the Web module.

So the issue could have been around since version 3 or 4.

[johnrellis]

I happen to have version 2.7 installed, which displays correct colors in the Web module.

So the issue could have been around since version 3 or 4.

Here's a summary of the testing of previous versions:

2.7: Works correctly (Per Bernsten)

4.0: Works correctly (John Ellis)

5.7.1: Works correctly (John Ellis); works incorrectly (Andrew Rodney)

6.0: Works incorrectly (Smit Keniya)

6.7 Works incorrectly (John Ellis, Smit Keniya)

6.14: Works incorrectly (John Ellis)

8.0: Works incorrectly (John Ellis)

[shermanphoto]

Works incorrectly

Verision 8

[johnrellis]

I posted the following in the feedback forum bug report:

Summary: LR includes third-party web-browser engines that are almost certainly used to render HTML Web galleries. The observed color-management behavior of LR's Web module matches that of these Web engines on Mac. The Web module could be made fully color-managed by updating LR to use the most recent version of the Chromium Embedded Framework.

Details

The Finder shows LR 4.0 and 5.7.1 on Mac include WebKit 1.0.0, the web browser engine used by Safari, which has long been fully color managed (using profiles embedded in photos and the display profile).  Accordingly, the Web module in these versions of LR is fully color-managed.

The Finder shows LR 6.0, 6.14, and 8.0 on Mac include Chromium Embedded Framework (CEF), the web engine inside Chrome.  All of these LR versions use an old version of CEF (31523.6.11), dating from at least 2015, when LR 6 was released.  Older versions of Chrome were only partially color-managed, using profiles embedded in photos but assuming the display's profile was sRGB.  Accordingly, the Web module in these versions of LR behaves similarly.

Both web engines treat photos without an embedded profile ("untagged") specially. WebKit assumes the photo is sRGB and displays it using the display profile. CEF sends the color numbers directly to the display without using the display profile.

The color behavior of CEF in LR's Web module was certainly reasonable for 2015, since it matched the behavior of the most popular browser at the time.  But now most people viewing the Web on desktop computers use browsers that are fully color-managed.  Newer versions of CEF support full color-management, so this issue could be addressed by including the most recent version of CEF in LR.

[Detailed steps for confirming this and screenshots are included in the original post.]