Having issues where the exported images are way darker than what I have edited.

[stevenphamphoto]

Anyone have an issue with LR CC where you export a photo but the export photo is way darker than it should be? Out of 600 photos, a good 30 or so are darker. It's not my export settings or monitor. I check back with my browser, photo viewer, and dropbox it to my phone but the resulting images seem darker than what I edited to.

I have to offset the images by exposure to almost +4 to get it to look right after exporting it.

[stevenphamphoto]

So I purged it, even made a new purge folder. I turned off the GPU but it still had the same effect.

Tried everything listed on my Mac as well and it did the same thing. It's just a weird offset somewhere

[Jao vdL]

---

@stevenphamphoto wrote:

So I purged it, even made a new purge folder. I turned off the GPU but it still had the same effect.

Tried everything listed on my Mac as well and it did the same thing. It's just a weird offset somewhere

---

Yeah this does look like a bug. As said, I see the incorrect bright version that you see all the time, for a few seconds. It is then immediately gone never to return in the same session. Strangely when I quit Lightroom and reopen it, it shows the too bright version (the correct version is the dark one!) again and disappears again. Somehow your machine gets stuck in whatever it does initially on mine.

[stevenphamphoto]

Rather frustrating but when I apply the preset and just use auto settings, it exports sort of fine. But once I make additional changes, the exported image always looks different. Then again, the previous photo in the set didn't have any issues so some of my work is just stuck in limbo.

[Jao vdL]

Yeah weird issue. Does the same thing happen in a new, empty catalog?

[stevenphamphoto]

Made a new catalog and edited the photo to my preferences. Exported fine. 

But when I read the previous XMP, the error had occured again. Maybe it's the XMP file of the edits?

[Jao vdL]

Could be something in the preset that you are using? Did you use the same preset in the empty catalog?

[stevenphamphoto]

I just did another test by saving the preset (I use the same preset for everything) into the new catalog, applied it to the one image, and the same error occured but didn't on the other files. 

So maybe it's the raw file? Still stuck in limbo again.

[Jao vdL]

something in your settings in the preset is triggering this. It could be the rather extreme (for a portrait image) highlight recovery setting but hard to say. It is interesting that it didn't happen on the image when you manually did your edits. Can you tell what is obviously different between your image when manually edited and when loading the xmp? I looked at your xmp file from the download link above and I don't see any obvious issues. Looks quite normal.

[stevenphamphoto]

Someone else that commented noticed a similar effect. Applying the preset or XMP and it looks fine. But then zooming in, it changes to something way underexposed. 

[Jao vdL]

Probably not related to your problem but you are making your machine do a LOT of unnecessary work. Smart previews are only used when the originals are not available. In almost all cases building them is just a massive waste of time and a waste of disk space. They are almost never used. Building 1:1 previews is useless if the first thing you do after that is to do any develop edits. The 1:1 previews you made before are now all out of date and will need to be rebuilt. You only need 1:1 previews if your edit workflow is to first step through all your images in library and check all of them for critical focus and never hit develop until you made a first down select. This is a typical workflow for studio photographers but even there there is a faster way to do things. If at any time before you have a downselected set of images you hit develop or do any batch editing, your 1:1 previews are dirty and need to be rebuilt. So best not to build them for most people. 

For almost all people, the best workflow is to only build standard previews or (much faster but has some caveats that your color might change subtly if you go into develop) is to use embedded previews upon import. The latter is super fast and gives you 1:1 previews right away by just using the jpeg previews the camera already generated for you and embedded into the raw files. Ignore smart previews if you never need to do any develop edits while your originals are offline (for example you store your originals on an external hard disk that will not always be connected when you need to edit). 

[crispincorky]

When you upload online the colour profile gets dropped for a basic monitor rgb one so you need to tweak the gamma curve before uploading. This video explains it: https://youtu.be/rYAjPHz-r18?si=R_zLTWiQUnaK0PIh

[robert_0373]

Hi Steven, did you ever come up with a solution to this problem? I have the exact same issue whenever I use smart previews (don't have the problem when not using smart previews, but obviously editing is slower as a result)...

[Parrotdyes]

This has been an immensely useful thread. I'm grateful to the OP for opening this topic and to all the people who gave advice, suggestions and performed tests on their own machines to try and replicate the problem. To synthesize what I've learned on the topic I wrote the following post on reddit https://www.reddit.com/r/Lightroom/comments/1ih2hud/lightroom_preview_and_export_look_different/
I'll explain in short here also. For anyone facing the same problem as OP and me go read the following article on preview types: https://digital-photography-school.com/6-types-lightroom-previews
My suggestion is to build standart previews instead of the default setting of embedded. Maybe not use smart previews although I'm not sure they're a problem. And finally for good measure set the high DPI scaling setting of the lightroom.exe to be decided by the application. All of those should make LRC fast enough to work properly and avoid the problem that brought us here in the first place.