Color differences exporting to sRGB & soft proofing not working

[Timothy5C5D]

I develop photos exclusively for web use in Lightroom Classic. That means I'm exporting in sRGB colorspace to post images on my website and social media. However, exported photos look completely different than what I see while developing. I assume this is because Lightroom uses a different ProPhoto colorspace. My monitor is a Dell S2721DGF IPS monitor. It has a wide-gamut and excellent color reproduction, though I have not done any calibration myself.

Now, I understand that Lightroom is a color managed program and windows/web is not, therefore I expect to see color differences when exporting to sRGB. I'm trying to use soft proofing to predict the differences and make changes, but the issue is that the soft-proofing doesn't appear to be working correctly. The picture I open in Windows does not reflect the soft-proofed sRGB copy displaying in Lightroom. Furthermore, the soft-proofed copy doesn't appear any different than the original in a side-by-side comparison inside Lightroom.

See the image below. The sRGB proof in Lightroom still appears different than the exported sRGB image. The exported image (left) is darker, higher contrast, and more saturated. Any ideas why these images would still be different after soft proofing? Alternatively, is there any way I can change the colorspace inside Lightroom to simply develop in sRGB and see the same colors when I export? Any help is appreciated, thank you.

[D Fosse]

There is absolutely zero difference in general color, so there's no problem in color management.

What you're seeing is the effect of different resampling algorithms, both when you scale down for export and when you view at different zoom ratios. Keep in mind that these specks of light are only a few pixels wide! How those pixels are resampled matters, and it matters a lot.

All resampling algorithms have a certain amount of sharpening built in. That sharpening enhances edge contrast, but it also by extension enhances edge color. Look at this:

See the difference?

This image is very much like a starry night sky, another recurring theme here in the forum. The answer is that you need to exercise some care when you do anything to disrupt the pixel structure - and that's what you do when exporting at smaller size.

You'll have more control over resampling algorithms, and their built-in sharpening, if you export from Photoshop. If this is critical, I'd use "Bicubic smoother" here, because it has the least amount of built-in sharpening. Then I'd do a separate round of manual sharpening after resizing, at 100% view! and decide what works best.

Bottom line: you need to understand what you're working with here - tiny specks of light. There's no way that will survive unharmed at smaller sizes. You need to make some decisions along the way.

[Jao vdL · Accepted solution]

@D Fosse has the correct answer here. The images in that screenshot are identical if you consider they are displayed in different programs that use different scaling algorithms. What you are seeing is that Develop uses a different scaling algorithm to downscale your image to the display size than other places. It subsamples the original raw file for the display. This can result in an overestimation of colorfullness (it might just happen to pick out the strongly colored pixels) and this often leads to people overdoing their sharpening and noise reduction. You should only judge the color and sharpenss/noise at 1:1 zoom in develop. When you export or go to the library panel, the complete raw file gets rendered and then scaled down to your export size. Then when you display in any viewer (including library view in Lightroom) regardless of whether it is color managed or not it gets scaled down again and during that scaling typically all pixels that were in the original image get averaged to the new pixel size the image is displayed. This can lead to a loss of apparent saturation when your color areas are small and just a few pixels accross. This is an inherent consequence of having to scale the image and is just a consequence of resampling the image that is unavoidable. There are many ways to do this scaling and this is why different programs can give different results. Lightroom's develop uses a subsampling algorithm because of speed. You don't want to rerender the entire raw file everytime you make a small change because it would be incredibly slow. Library renders from a jpeg preview that gets generated itself by rendering the entire raw file and scaling down and then firther scaling down the jpeg to the actual display resolution. So library will always be closer to an exported jpeg viewed in another application but this is only relevant if you have very strong color detail. You will not see a difference in almost any image. Images that typically give subtle differences are things like a milky way night time image, a field of flowers, or stuff like this. These differences are not real and are just caused by the image scaling and is something you have to be aware off can happen and you can't always completely control it as it can happen anywhere in the image chain.

Lastly, you absolutely should get a hardware calibrator. It is essential to getting anywhere near correct color especially if you are editing on a wide gamut monitor. The canned profiles are seldomly anywhere near correct even if your monitor came with an official looking calibration report. You can't avoid these subtle scaling issues by calibration but it does avoid the much larger color shifts you can see between the screenshots from different systems in this thread.

[Timothy5C5D]

Well well, @D Fosse & @Jao vdL I think you're on to something here. This may just be a good lesson in resampling and sharpening algorithms. I've tried exporting the file as a DNG (https://drive.google.com/file/d/1AC4SijgHij3gSDfUzQCCXT88sSfQJihM/view?usp=sharing in case anyone wants to check it out) and importing  into photoshop. The photoshop file and LR library view look the same (same as when exporting as sRGB jpg with higher contrast and saturation), while the develop view in LR looks different. This seems to support the different rendering algorithms being used.

To finish this up, does anyone have any advice on how to improve my workflow to avoid this discrepency in develop mode? I see the suggestion above of exporting in PS, but I still have the issue of changes made in LR development not being reflected when sending the file to PS. All of my work involves photography of this product, and I would like to contiue developing in LR. Is there a way to change the rendering algorithm in LR's different modes? Any settings I can alter or be particularly mindful of? I have tried reducing sharpening/noise reduction/clarity/texture to zero, but I do still see differences between develop and library/PS.

[TheDigitalDog]

The bottom line: there is no discrepency in the Develop module. 

There are issues for some in properly viewing the image data in an ideal and consistent fashion. 

Optical illusions like these in fig 1 are not new:

http://digitaldog.net/files/23The%20eyes%20don't%20have%20it.pdf

[Timothy5C5D]

Well, I don't think it's quite fair to say this is entirely optical illusion. There are clear pixel differences in the zoomed in image @D Fosse posted above. While it may be caused by rendering algorithms and edge sharpening effects, it is still a real effect.

Regardless, the question now is what can I do to minimize this? Can I change how the previews are rendered in LR? Any settings that can help alleviate this? I see that at 100% zoom the images do look the same, but editing at 100% (which appears extremely zoomed in on a hi-res photo) is also impractical. Any ideas on how to improve workflow here?

[TheDigitalDog]

---

@Timothy5C5D wrote:

Well, I don't think it's quite fair to say this is entirely optical illusion. 

---

In terms of a very dark and very light surround around each image alone, it is fair to suggest optical illusion is part of the issue. The original post talked of difference in color and tone (copy and paste: darker, higher contrast, and more saturated), not sharpness and noise matching. Again, again, this is to be expected and was mentioned. The differences in zoom ratio and not using one image pixel for one screen pixel was discussed in like the 3rd post here. Gotta do this correctly. 

You minimize this by again previewing the image data in the correct module at the correct zoom ratio; all discussed earlier.

[Timothy5C5D]

Another oddity I found: my image appears different in Library and Develop. Almost like the Library preview has not had some effects applied and looks darker, much like the exported photos. The differences are subtle, but its quite apparent when switching back and forth between Library and Develop on my screen. Is it possible some of the develop settings are not being applied on export?

[Per Berntsen]

Are you comparing at 100% view?

[TheDigitalDog]

Oh, do not invoke soft proofing in Develop module to sRGB, kind of pointless and possibly adding to the issue. View the raw in Develop. View the JPEG in sRGB, hopefully in Photoshop. This is what I did with your image on this end, also using a wide gamut display. Is this different and a closer match? The same, worse?

[D Fosse]

I suspect this is just a good demonstration of how interface color (dark vs. light) can influence your perception 😉

A light interface gives you a reference for the white point, and all shortcomings are immediately revealed. Most images tend to look darker and more muddy. A dark interface removes that reference and so everything looks good because the eye adapts to the image.

My #1 wish for Lightroom has always been a light interface option like we have in Photoshop. For this reason I do most of my critical editing in Photoshop, not Lightroom.

[richardplondon]

I tend to agree the option of a "light" interface would be welcome, though involving a ground-up review of the whole Library UI and the visibility of its shades-of-grey highlighting for that different scheme - so not limited to a redesign of the tool panels.

But even without such a redesign, we can already change the Lights Out mode to "white", and then at a keypress, temporarily hide everything but our image (to an selectable opacity of the overlay).

Also the Develop workspace background colour can be set to white, although in that case the side panels are still seen as dark context unless you Tab those away temporarily - the more laborious option IMO.

[D Fosse]

Right. There are workarounds, but pretty cumbersome.

Anyway, this turned out not to be the issue in this case after all.

[Todd Shaner]

To really see what the OP is seeing we need to request he export the raw file to DNG file format with all of his LrC settings applied. Timothy5C5D can you please do that and post to your file sharing site.

I added the Basic panel settings visible in his screenshots, but there may be other settings. With just the Basic panel settings applied there is substantial image content outside of sRGB gamut and even some outside Adobe RGB. The DNG export file will contain all of his settings allowing us to hopefully see what he is seeing and better understand what's happening. Thank you.

[Timothy5C5D]

Good idea, I'm quite curious to see if this is reproduced on other machines. Here is a download link for the DNG: https://drive.google.com/file/d/1AC4SijgHij3gSDfUzQCCXT88sSfQJihM/view?usp=sharing

[Jao vdL]

I see zero difference between library and develop when zoomed in 1:1. The original is quite noisy so this is one of those prototypical images that will suffer a bit of color distortion when zoomed out in develop but I still do not notice any significant change in color on my Mac Book Pro. The only thing is a slight difference in presence for the LEDs that are reflected in the back surfaces. They look slightly brighter in the Develop preview (zoomed out to fit). This is quite typical for images that have very high noise reduction settings (anything above 25 is very high). The retina display probably helps hide most scaling artefacts but you can't completely get rid of them. As said they are gone completely in 1:1 display and zoomed 1:1 the display is identical. 

Exported sRGB jpeg is also identical in my case when viewed at 100%/1:1. On Macs everything is color managed of course so that is not a worry. I see slight differences when zoomed to fit for the reasons already discussed. The standard jpeg app on Macs: preview.app uses a very soft scaling algorithm that tends to lose sharpness (and so will soften the very small highlights in this image in the reflected LEDs) when zoomed out but at 1:1 it is identical to Lightroom Library and Develop.

[Timothy5C5D]

Yes you're right, the differences between library and develop are gone within LR at 100% zoom. It's apparent now that this is a scaling and resampling issue. With this in mind, I want to improve my workflow. Editing at 100% (which appears extremely zoomed in on a hi-res photo) is impractical; I can't really get the image to look the way I want it without seeing the full frame. Do I have any control over how LR renders the preview in develop mode? Is there anything I can do to minmize the resampling artifacts?

[Todd Shaner]

Changes were made to the Libray Preview zoom interpolation sometime after LrC v8.4.

https://community.adobe.com/t5/lightroom-classic-bugs/library-preview-zoom-interpolation-changed/idi...

Noisy image files have always exhibited differences between the Develop and Library module at less than 1:1 zoom. Prior to the above mentioned interpolation changes the most accurate preview was the Library module's Zoom preview setting that most closely matches the Export file's image dimensions. Unfortunately that is no longer the case. As Jao has mentioned for best results try using lower sharpening and NR settings. The Develop preview should then more closely match the Library module preview and export files.

[Todd Shaner]

One other thing you can try is to disable the GPU in LrC and see if that improves the preview matching between the Develop module and Libary module. Go to Edit> Preferences> Performance, set 'Use Graphics Processor' to Off, and then close and restart LrC.

[TheDigitalDog]

---

@Todd Shaner wrote:

One other thing you can try is to disable the GPU in LrC and see if that improves the preview matching between the Develop module and Libary module.

---

Suggested earlier, tried by the OP, no difference. 

Again, with or without GPU, it is entirely to be expected in some cases for Develop and other modules to show a slight mismatch! The preview architecture differs; the data, the color space, the bit depth: nearly everything.   

[TheDigitalDog]

---

@Todd Shaner wrote:

Changes were made to the Libray Preview zoom interpolation sometime after LrC v8.4.

According to whom inside of Adobe?

[Jao vdL · Accepted solution]

You can't change the way develop renders unfortunately. The difference is minimized if you use high resolution displays such as retina screens, 4k monitors, etc. since you can't really see the individual pixels there. You can get a bit of an idea by switching back and forth to Library or by using a second display (the preview on the secondary display is rendered from the jpeg preview just like in library but it updates live (but slow) while doing changes in develop settings). One factor we haven't even discussed is what happens when you scale your jpeg upon export and use output sharpening. You'll see it actually get closer to develop again! Again, this is due to the scaling algorithm and post scaling sharpening, which will bring back some of the detail lost by the scaling.

You should realize that you will never be able to completely control this. You can't control what scaling websites, web browsers, printing layout software, etc. uses so you simply have to get used to not being able to perfectly control this. This is true for all imaging software. For example, if you are in Photoshop, you will see that the image can radically change between zoom levels. Photoshop uses a different scaling algorithm when zoomed out at powers of 2 (i.e. 50%, 25%, 12.5% etc) than at off even divisible zoming rations (i.e. 33%, 66%, etc.). Typically the image will loook more detailed (and colorful for images such as this) at non-even zoom ratios because it uses a nearest neighbor algorithm. You'll see lots of threads by people wanting to get the appearance you see in Photoshop at odd ratios and them being really upset when the file outisde of Photoshop looks completely different. 

Bottomline, do not touch sharpening and noise reduction outside of 1:1 zoom. Check your images both in Library and Develop. Best to use high resolution displays as you'll see more pixels even in zoomed-out views so less possibility of scaling artefacts.

[Timothy5C5D]

Ah now here's a good suggestion! Putting the library view on my second monitor lets me see the development changes in real time, in a way that appears true to the final export.

This has all been very informative. I did not realize how drastic the effects of scaling and rendering artifacts could be. I suppose the images I work on, with high saturation and bright points of light, are a fairly extreme edge case that highlights the issue quite well. Thank you, I truly appreciate everyone's help with this. Case closed!

[Guest]

FYI Dell provides "default" (uncalibrated, obviously) monitor profiles for all of their monitors.   You'll need to look on their site in the drivers section for your monitor model.  It may or may not be accurate.   My aging and surprisingly still working (why the CFL backlight hasn't burned out yet I'll never know) Dell U3011 shipped with a profile that covered the majority of AdobeRGB which it was factory calibrated for.  That's just a secondary junk monitor though, and not really relevant.   Your monitor has a downloadable profile that covers most of DCI-P3 and not-quite-all of sRGB.   Note that the monitor you have is not one of Dell's "PremiereColor" models.   Although they list their 8bpc + FRC models as 1.07 billion color, they're not 10 bit panels. Unless they changed the naming scheme again only the monitors with models starting in UP are true 10 bit.   Usually the 8+FRC ones are designed for one specific colorspace and can't really be calibrated to cover, say AdobeRGB instead, where a 10 bit panel might cover both. 

The whole thing about color managed viewers isn't quite true anymore on Windows.   I'm still a few releases back (1909 I think) and both explorer via thumbnail previews and the built in Photos program honor ICC profiles.   It's the desktop itself and programs that don't do things correctly that aren't color managed.

Here's a screenshot of a 16bpc .tif (explorer thumbnail) which was converted to the Rec. 2100 PQ W10000 profile in photoshop (for maximum visibility of the difference).   You can see a jpeg next to it in the original AdobeRGB colorspace, which looked too similar to sRGB to use as a good example in this case.  Then I used

exiftool -ICC_Profile= _DSC0202.tif 

To remove the ICC profile from the image without doing anything that might update a built-in thumbnail or manipulate the image itself in any way.   The second image is the result, where Windows defaults back to the sRGB colorspace.  You'll notice it's now less saturated than the AdobeRGB version. 

Anyway the point is, download your monitor's profile from Dell's website and set it up before bothering to compare anything, then set the monitor to the required settings for that colorspace according to the manual.  It won't be calibrated but it'll be quite a bit closer than using a random sRGB profile on top of whatever manual adjustments for viewing you might have made. 

What windows won't do is display 16bpc images @ 10bpc depth even when the monitor is set to that, which is easy to verify with a large black -> white gradient and the banding check in photoshop vs. windows Photos, so that can cause a very slight color difference.  

[D Fosse]

No, you misunderstand how monitor profiles work and what they do. As well as some other things.

A monitor profile isn't supposed to "cover" anything. It has one purpose: to describe the actual and current behavior of the monitor, whatever that is. A monitor profile is a map. It just needs to describe the terrain.

The monitor doesn't need to match any particular color space. It is what it is, and that's fine. You could make a monitor half way between sRGB and Adobe RGB and it would work just as well. Then the profile would describe that halway color space, and that would work exactly the same way. The reason it's not done is just for marketing reasons.

"Factory calibration" is a contradiction in terms. They can't know the monitor settings. The profile needs to take that into account.

No, Windows "Photos" and Windows Explorer are not color managed. They do not know what an icc profile is, and ignore all of them. The reason an Adobe RGB image looks roughly right on a wide gamut monitor is that it's already quite similar to the monitor's native color space. Not a match, mind you, but reasonably close.

And finally, 10 bit display works in applications that support it, like Photoshop, but not in applications that don't, like Photos or Explorer (or Lightroom). Windows itself, the operating system, supports it.

[Guest]

I'm aware of that.   Dell's profile will still be better than assigning sRGB.  It's not going to be accurate.

I probably phrased the thing about AdobeRGB coverage badly;  that profile was the map for the display's full gamut at factory settings.    Their "factory calibration" was their adjustment of the AdobeRGB preset on the monitor to come as close as it would get to full AdobeRGB coverage.     Change the brightness, color temp, contrast, etc and it's invalidated.  The monitor ages and it's invalidated.     I'm not rich enough for one of the really high end displays with the little robotic drop-down auto profiler / calibrator so I used a Spyder3 I got cheap (for good reason) a couple of times a year.   It was flakey and usually took several tries but I managed to keep the display accurate enough to proof prints on a Canon iPF5100 and not have mismatch unless I screwed up in the overly complicated paper selection and paper profile selection that needed to be done for canon branded roll paper (none of the names matched between the driver, the printer itself, and the profiles for reasons unknown to me so you needed a spreadsheet and it was safer to set the paper type on the printer itself and not let the driver try to mess with it, then dig out the right profile). 

No, Windows "Photos" and Windows Explorer are not color managed. They do not know what an icc profile is, and ignore all of them. The reason an Adobe RGB image looks roughly right on a wide gamut monitor is that it's already quite similar to the monitor's native color space. Not a match, mind you, but reasonably close.

I thought this too, and it used to be true so I never really bothered looking...  and you really won't notice the difference between AdobeRGB and sRGB in small thumbnails and I don't normally store images in bizarre colorspaces that no display can deal with properly...  right up until I tried that silliness with the Rec. 2100 profile above.   I don't even know why I did.   I do know that there's absolutely no reason I know of aside from Windows reading the ICC profile (or lack thereof) that the thumbnail of that TIFF in explorer which has identical RGB values after stripping the Rec. 2100 profile would suddenly revert to the original colors I'd been screwing with on it.   Exiftool doesn't mess with the image itself.  

If you've got a good explanation of why the colors shifted back over to what they were before I assigned Rec. 2100 to it with no image manipulation (just EXIF field deletion) I'd love ot hear it, because I can't come up with another one.   You can try it yourself though. It does the same thing with JPEGs (if you don't have the TIFF preview filter installed.)  I'm serious, if it's not ICC being applied it's confusing the heck out of me.  😛