Lightroom color issue Develop vs Library modules

[slookabill]

Just recently when I started to process photos from my recent shoot at an airshow, after importing to lightroom 6 and starting to process, I noticed that the Library and Develop modules are showing completely different color toning for the images. I generally like what I'm seeing in the Develop module, but when going to the library I know I don't care for those colors and resulting look. What is wrong, and how can I fix it?




Develop Module look




Library Module view

 

[digidog]

The two modules use a different color space and the only accurate preview is within Develop module at 1:1 or greater. So what you report is to be expected. That said, the differences you show are pretty large.

Do you calibrate and profile your display and if so, does the software support, create V4 ICC profiles? LR doesn't like em, set the software for V2.

 

[Cariboou]

Here how appear in the Library and Develop Module Lighroom 5 without any corrections





Cheers

Cariboou!

--

Portfolio

DVL Photography

caribooua.zenfolio.com

 

[slookabill]

The two modules use a different color space and the only accurate preview is within Develop module at 1:1 or greater. So what you report is to be expected. That said, the differences you show are pretty large.

Do you calibrate and profile your display and if so, does the software support, create V4 ICC profiles? LR doesn't like em, set the software for V2.

 

[Sailor Blue]

The two modules use a different color space and the only accurate preview is within Develop module at 1:1 or greater. So what you report is to be expected. That said, the differences you show are pretty large.

Do you calibrate and profile your display and if so, does the software support, create V4 ICC profiles? LR doesn't like em, set the software for V2.

 

[Simon Garrett]

The two modules use a different color space and the only accurate preview is within Develop module at 1:1 or greater. So what you report is to be expected. That said, the differences you show are pretty large.

Do you calibrate and profile your display and if so, does the software support, create V4 ICC profiles? LR doesn't like em, set the software for V2.

--
Andrew Rodney
Author: Color Management for Photographers
The Digital Dog
http://www.digitaldog.net

I'd heard that the color space issue was more of an effect of the noise reduction/sharpening of images, not in how color balance is massively distorted.

My monitors are towards the cheap end, an Acer and AOC, and have no clue for how to calibrate or maximize them properly.

Ideally you should calibrate and profile the monitors, as others have said.

However, here's a quick fix that will at least confirm what the problem is. I assume you're using Windows; go to Control Panel, Color Management.

First note what the default is now, if any (so you can go back there if needed):



Then select "sRGB..." and click "Set as default":





If you can't see sRGB in the list, click "Add...", and find it there. If you have two monitors, this can be set for each independently.

This will tell Windows and Lightroom that the monitor behaves as though it has sRGB colour space. This won't be right, and it is always better to calibrate/profile properly, but for most monitors it will be very very roughly right.

More to the point, it may make the Library and Develop renderings look more similar.

If it makes things better, then your problem was no monitor profile, or a faulty profile.

--
Simon

 

[VTblue]

OMG, thank you so much! I've been dealing with this nightmare for months! I was getting great results in Develop, but the Library mode was completely unusable because of the distorted white balance. I went into the Windows Color Management, added a new SRGB profile, restarted Lightroom and IT WORKED! The monitor ICM profile sucked so hard.

 

[Jodes13]

Just signed up an account so I could come on and thank you for this fix also.

Honestly, thought this would be hard to fix. My develop module looked totally different to my exports and library. Thought it might just be lightroom and I'd have to deal with it.

Turns out the ICC profiles under color management are way different from the WCS profiles. I selected an WCS sRGB profile instead of the ICC profiles chosen by my monitor and boom. Everything now looks the same and I'm no longer editing raw and re-editing my jpegs.

Massive thanks for this

 

[Jodes13]

[No message]

 

[digidog]

Just signed up an account so I could come on and thank you for this fix also.

Honestly, thought this would be hard to fix. My develop module looked totally different to my exports and library. Thought it might just be lightroom and I'd have to deal with it.

Turns out the ICC profiles under color management are way different from the WCS profiles. I selected an WCS sRGB profile instead of the ICC profiles chosen by my monitor and boom. Everything now looks the same and I'm no longer editing raw and re-editing my jpegs.

The same but maybe all wrong however. You need to select the specific display profile built from an instrument, not some 'generic' RGB profile like sRGB. In color managed app's, the display profile and the RGB working space are used to produce a color managed preview. So for example, in Photoshop, there's a soft proof setting (Monitor RGB) that does this. And the preview will now match non ICC aware app's which is wrong. IOW, you can get PS to preview incorrectly as you'd see in non ICC aware app's and while the two match, they both match incorrectly. That's not a fix.

 

[CyrusOxford]

Yes! I've just signed up to thank you!

 

[agrumpyoldsod]

The two modules use a different color space and the only accurate preview is within Develop module at 1:1 or greater. So what you report is to be expected. That said, the differences you show are pretty large.

Do you calibrate and profile your display and if so, does the software support, create V4 ICC profiles? LR doesn't like em, set the software for V2.

 

[digidog]

The two modules use a different color space and the only accurate preview is within Develop module at 1:1 or greater. So what you report is to be expected. That said, the differences you show are pretty large.

Do you calibrate and profile your display and if so, does the software support, create V4 ICC profiles? LR doesn't like em, set the software for V2.

--
Andrew Rodney
Author: Color Management for Photographers
The Digital Dog
http://www.digitaldog.net

Agree -- set your colour space to Adobe RGB 1998 and your working space to this too. Also calibrate your monitors using this profile if possible.

Better: set your working space to ProPhoto RGB in Photoshop and export it from LR:

--
Andrew Rodney
Author: Color Management for Photographers
The Digital Dog

Home

 

[agrumpyoldsod]

Better: set your working space to ProPhoto RGB in Photoshop and export it from LR:

OK -- while I and many others would agree in principle - you should pick 16-bit ProPhoto RGB; But - I am sure that you are aware that there is NO monitor or printer available to day that can provide beyond Adobe RGB 1998 plus.



So selecting ProPhoto RGB (which was my choice in the past) you absolutely have to complete a Gamut check before sending your images to the printer and these images have to be in the same Gamut that your printer and the paper you have selected will replicate.

sRGB is the default working space for web work -- and as shown above it is really much smaller than both Prophoto and Adobe RGB. So again, if you care about color representation of your final on web image -- this needs to be soft proofed and gamut checked using sRGB.

Going back to the OP's issue -- I was recently advised to switch from ProPhoto RGB to Adobe RGB 1998 - because all LR works in Adobe RGB 1998, not all work in ProPhoto. My understanding is that the Develop Module actually works in Miranda RGB (Gamut 1.0) and the Library module in Adobe RGB. Yes - Export to Photoshop and other editors in 16-bit Prophoto RGB. BUT there is a discrepancy with how LR displays color AND this becomes very visible if the colors in the image are ïn-gamut"in the development module and out-of-gamut in the Library. Personally I would only use sRGB in soft proof and jpg output for web viewing.

 

[digidog]

Better: set your working space to ProPhoto RGB in Photoshop and export it from LR:

OK -- while I and many others would agree in principle - you should pick 16-bit ProPhoto RGB; But - I am sure that you are aware that there is NO monitor or printer available to day that can provide beyond Adobe RGB 1998 plus.

And that doesn’t matter. The display is an intermediary device for some of us.

Adobe RGB (1998) and sRGB, ProPhoto RGB are just color spaces, or rather containers. They don't inherently have any information other than specifications for primaries, white point, and gamma. Until we actually have a pixel, they don’t contain any information. Using ProPhoto RGB doesn’t mean you have pixels that fall to the edge of the gamut boundaries or even close to that!

So selecting ProPhoto RGB (which was my choice in the past) you absolutely have to complete a Gamut check before sending your images to the printer and these images have to be in the same Gamut that your printer and the paper you have selected will replicate.

No, you don’t. You only need to soft proof to the output profile understanding that not all color may be visible on-screen.

OR you can clip colors that fall outside display gamut so you can see them and not use them. What’s your preference? I prefer to use the color information I’ve encoded I can use but may not see on a display; that’s not my final output.

sRGB is the default working space for web work -- and as shown above it is really much smaller than both Prophoto and Adobe RGB. So again, if you care about color representation of your final on web image -- this needs to be soft proofed and gamut checked using sRGB.

sRGB in no way guarantees anything anywhere will match! You need color management for that. So if you have a color managed browser, any color space is fair game.

sRGB urban legend & myths Part 2

In this 17 minute video, I'll discuss some more sRGB misinformation and cover:

When to use sRGB and what to expect on the web and mobile devices

How sRGB doesn't insure a visual match without color management, how to check

The downsides of an all sRGB workflow

sRGB's color gamut vs. "professional" output devices

The future of sRGB and wide gamut display technology

Photo print labs that demand sRGB for output

High resolution: http://digitaldog.net/files/sRGBMythsPart2.mp4

Low resolution on YouTube:

Going back to the OP's issue -- I was recently advised to switch from ProPhoto RGB to Adobe RGB 1998 - because all LR works in Adobe RGB 1998, not all work in ProPhoto.

That’s simply not true. All processing in LR and ACR take place with ProPhoto RGB primaries and thus color gamut.

My understanding is that the Develop Module actually works in Miranda RGB (Gamut 1.0) and the Library module in Adobe RGB. Yes -

Nope. Start here (it’s old but nothing has changed):

Loading…

digitaldog.net

Export to Photoshop and other editors in 16-bit Prophoto RGB. BUT there is a discrepancy with how LR displays color AND this becomes very visible if the colors in the image are ïn-gamut"in the development module and out-of-gamut in the Library. Personally I would only use sRGB in soft proof and jpg output for web viewing.

The small possible discrepancy with some images is moot if you understand how and where to view your images correctly: In Develop.

 

[agrumpyoldsod]

And that doesn’t matter. The display is an intermediary device for some of us.

Its the device I use to see my edits.

Adobe RGB (1998) and sRGB, ProPhoto RGB are just color spaces, or rather containers.

That's what I said.

They don't inherently have any information other than specifications for primaries, white point, and gamma. Until we actually have a pixel, they don’t contain any information. Using ProPhoto RGB doesn’t mean you have pixels that fall to the edge of the gamut boundaries or even close to that!

?? ENGLISH PLEASE !

So selecting ProPhoto RGB (which was my choice in the past) you absolutely have to complete a Gamut check before sending your images to the printer and these images have to be in the same Gamut that your printer and the paper you have selected will replicate.

No, you don’t. You only need to soft proof to the output profile understanding that not all color may be visible on-screen.

You and I (and the guys I work with) very much disagree -- Most of us don't routinely soft proof before we generate output for the web -- and find ourselves surprised when, for example, there is a colour shift, certain colors just go nuts OR certain colours are not what the client expects. If you have an out of gamut color that looks nuts/is not correct when you see it printed or in your final image for web viewing (and this could be sRGB for Web viewing OR the color gamut of your printer and selected paper) THEN you should replace it with an IN Gamut color. The tool I was taught to use is the Gamut Warning Tool

OR you can clip colors that fall outside display gamut so you can see them and not use them. What’s your preference? I prefer to use the color information I’ve encoded I can use but may not see on a display; that’s not my final output.

sRGB is the default working space for web work -- and as shown above it is really much smaller than both Prophoto and Adobe RGB. So again, if you care about color representation of your final on web image -- this needs to be soft proofed and gamut checked using sRGB.

sRGB in no way guarantees anything anywhere will match!

Thanks I know, so does just about everyone else.

You need color management for that.

AND that is why I said -- if the image is to be placed on the web and viewable by everyone then it has to be in-Gamut in sRGB, because almost no-one has a color managed browser in the wider world.

Thanks for the sale pitch !

Going back to the OP's issue -- I was recently advised to switch from ProPhoto RGB to Adobe RGB 1998 - because all LR works in Adobe RGB 1998, not all work in ProPhoto.

That’s simply not true. All processing in LR and ACR take place with ProPhoto RGB primaries and thus color gamut.

Please provide evidence to support your statement !

My understanding is that the Develop Module actually works in Miranda RGB (Gamut 1.0) and the Library module in Adobe RGB. Yes -

Nope. Start here (it’s old but nothing has changed):
http://digitaldog.net/files/18Color Management in Lightroom.pdf

I do luv it when protesters give me the evidence that I quoted the right info -- " Think of the underlying internal color space as having the RGB primaries and white point of ProPhoto RGB, but instead of 1.8 gamma encoding, this newspace uses a 1.0 gamma encoding." and this space is called Melissa (I misspoke by calling it Miranda -- I must have been watching Serenity)

Since YOU were kind enough to give me some reading -- please follow this link The truth about lightroom colour management OR Jeffrey Friedl's article on on color space .

 

[Simon Garrett]

A couple of points to your post:

That’s simply not true. All processing in LR and ACR take place with ProPhoto RGB primaries and thus color gamut.

Please provide evidence to support your statement !

I'm not sure what you meant by that, but in the link you posted (http://www.colourspace.xyz/the-truth-about-lightroom-colour-management/) it says what Andrew (digidog) said about what it called "editing colour space":

"Lightroom’s editing space accomplishes this by using the RGB primaries and white point of ProPhoto RGB." The editing space is the one in which it does all its processing (i.e. editing of the image).

My understanding is that the Develop Module actually works in Miranda RGB (Gamut 1.0) and the Library module in Adobe RGB. Yes -

Nope. Start here (it’s old but nothing has changed):
http://digitaldog.net/files/18Color Management in Lightroom.pdf

I do luv it when protesters give me the evidence that I quoted the right info -- " Think of the underlying internal color space as having the RGB primaries and white point of ProPhoto RGB, but instead of 1.8 gamma encoding, this newspace uses a 1.0 gamma encoding." and this space is called Melissa (I misspoke by calling it Miranda -- I must have been watching Serenity)

Meliessa space is ProPhoto RGB but with sRGB's Tone Response Curve (TRC), which approximates to a gamma of 2.2 not 1.0.

LR uses Melissa RGB for histograms and pixel values, as a sRGB gamma (close to 2.2 gamma) is closer to human perceptual TRC than is linear TRC. That means a mid-grey is half way up the scale, and not right down the left hand end.

It uses Adobe RGB for previews, as it stores previews in 8 bit encoding, and to store an image in a wide space such as ProPhoto using 8 bits risks visible staircases on tone wedges.

I'm pretty sure it uses sRGB in web module (not Adobe RGB as in the link) and in print module it uses the preview (Adobe RGB) for display, but sends to the printer whatever colour space you specify in the printer profile.

 

[digidog]

And that doesn’t matter. The display is an intermediary device for some of us.

Its the device I use to see my edits.

Me too (on a wide gamut display). My soft proofs are very close to the print. There are colors that printer can produce your display cannot and vise versa. EVEN if you ONLY use sRGB. NO printer can produce sRGB fully!

Adobe RGB (1998) and sRGB, ProPhoto RGB are just color spaces, or rather containers.

That's what I said.

They don't inherently have any information other than specifications for primaries, white point, and gamma. Until we actually have a pixel, they don’t contain any information. Using ProPhoto RGB doesn’t mean you have pixels that fall to the edge of the gamut boundaries or even close to that!

?? ENGLISH PLEASE !

What don’t you understand about containers vs. the data they may contain?

So selecting ProPhoto RGB (which was my choice in the past) you absolutely have to complete a Gamut check before sending your images to the printer and these images have to be in the same Gamut that your printer and the paper you have selected will replicate.

No, you don’t. You only need to soft proof to the output profile understanding that not all color may be visible on-screen.

You and I (and the guys I work with) very much disagree -- Most of us don't routinely soft proof before we generate output for the web -- and find ourselves surprised when, for example, there is a colour shift, certain colors just go nuts OR certain colours are not what the client expects. If you have an out of gamut color that looks nuts/is not correct when you see it printed or in your final image for web viewing (and this could be sRGB for Web viewing OR the color gamut of your printer and selected paper) THEN you should replace it with an IN Gamut color. The tool I was taught to use is the Gamut Warning Tool

You can’t soft proof for the web! Because you do not have the ICC profile for every viewers display. If they even have one! You can soft proof to what your non color managed browser (don’t!) would look like on YOUR machine. But if you had a color managed browser (DO!), it would appear exactly as you see it in Photoshop in sRGB.

OR you can clip colors that fall outside display gamut so you can see them and not use them. What’s your preference? I prefer to use the color information I’ve encoded I can use but may not see on a display; that’s not my final output.

sRGB is the default working space for web work -- and as shown above it is really much smaller than both Prophoto and Adobe RGB. So again, if you care about color representation of your final on web image -- this needs to be soft proofed and gamut checked using sRGB.

sRGB in no way guarantees anything anywhere will match!

Thanks I know, so does just about everyone else.

Speaking for everyone now? You’re having enough problems speaking correctly for yourself. :-(

You need color management for that.

AND that is why I said -- if the image is to be placed on the web and viewable by everyone then it has to be in-Gamut in sRGB, because almost no-one has a color managed browser in the wider world.

Nope.

Thanks for the sale pitch !

The absurd is the last refuge of a pundit without an argument

What am I selling and for how much.

Going back to the OP's issue -- I was recently advised to switch from ProPhoto RGB to Adobe RGB 1998 - because all LR works in Adobe RGB 1998, not all work in ProPhoto.

That’s simply not true. All processing in LR and ACR take place with ProPhoto RGB primaries and thus color gamut.

Please provide evidence to support your statement !

Sure, here’s text from Mark Hamburg who was the architect of LR:

The histograms (both tone curve and output), the curve display, and all
numbers are in the color space variously known as Melissa RGB, B astard RGB,
or Love Child RGB. (ProPhoto primaries and white point, sRGB response
curve.) This is true for both raw and rendered files.

The internal space is essentially linearized ProPhoto, but using that for
the histograms and the numeric readouts would result in excess space being
used to display information about the highlights.

This is the space that ACR uses for the tone curve display and histogram.
ACR uses the current output space for the output histograms and the numeric
readouts. Since Lightroom doesn¹t have a notion of an output space until
such time as you actually go to generate output, we just settled on matching
what ACR was doing for the tone curve since having two fixed color spaces
seemed excessive.

Mark~-~-~-~

ONE of us was an alpha tester for LR before it went public beta, you were not.

My understanding is that the Develop Module actually works in Miranda RGB (Gamut 1.0) and the Library module in Adobe RGB. Yes -

Nope. Start here (it’s old but nothing has changed):
http://digitaldog.net/files/18Color Management in Lightroom.pdf

I do luv it when protesters give me the evidence that I quoted the right info -- " Think of the underlying internal color space as having the RGB primaries and white point of ProPhoto RGB, but instead of 1.8 gamma encoding, this newspace uses a 1.0 gamma encoding." and this space is called Melissa (I misspoke by calling it Miranda -- I must have been watching Serenity)

I’m sorry your mistakes and my facts continue to ruin your life.

Since YOU were kind enough to give me some reading -- please follow this link The truth about lightroom colour management OR Jeffrey Friedl's article on on color space

Specially what (and what states the facts Mark and I have provided about the underlying color space used in the ACR engine for processing)?

Want to tell us that Adobe is wrong about ProPhoto RGB too?

https://helpx.adobe.com/lightroom/help/color-management.html

In the Develop module, by default Lightroom displays previews using the ProPhoto RGB color space. ProPhoto RGB contains all of the colors that digital cameras can capture, making it an excellent choice for editing images. In the Develop module, you can also use the Soft Proofing panel to preview how color looks under various color-managed printing conditions.

http://ptgmedia.pearsoncmg.com/impr...t/lightroom4/pdf_files/LightroomRGB_Space.pdf

Lightroom carries out the image processing calculations in its own RGB space, which uses the ProPhoto RGB coordinates but has a gamma of 1.0 instead of 1.8.

And then there’s this you missed too:

Loading…

digitaldog.net

Facts bud!

 

[digidog]

A couple of points to your post:

That’s simply not true. All processing in LR and ACR take place with ProPhoto RGB primaries and thus color gamut.

Please provide evidence to support your statement !

I'm not sure what you meant by that, but in the link you posted (http://www.colourspace.xyz/the-truth-about-lightroom-colour-management/)it says what Andrew (digidog) said about what it called "editing colour space":

"Lightroom’s editing space accomplishes this by using the RGB primaries and white point of ProPhoto RGB." The editing space is the one in which it does all its processing (i.e. editing of the image).

My understanding is that the Develop Module actually works in Miranda RGB (Gamut 1.0) and the Library module in Adobe RGB. Yes -

Nope. Start here (it’s old but nothing has changed):
http://digitaldog.net/files/18Color Management in Lightroom.pdf

I do luv it when protesters give me the evidence that I quoted the right info -- " Think of the underlying internal color space as having the RGB primaries and white point of ProPhoto RGB, but instead of 1.8 gamma encoding, this newspace uses a 1.0 gamma encoding." and this space is called Melissa (I misspoke by calling it Miranda -- I must have been watching Serenity)

Meliessa space is ProPhoto RGB but with sRGB's Tone Response Curve (TRC), which approximates to a gamma of 2.2 not 1.0.

LR uses Melissa RGB for histograms and pixel values, as a sRGB gamma (close to 2.2 gamma) is closer to human perceptual TRC than is linear TRC. That means a mid-grey is half way up the scale, and not right down the left hand end.

It uses Adobe RGB for previews, as it stores previews in 8 bit encoding, and to store an image in a wide space such as ProPhoto using 8 bits risks visible staircases on tone wedges.

I'm pretty sure it uses sRGB in web module (not Adobe RGB as in the link) and in print module it uses the preview (Adobe RGB) for display, but sends to the printer whatever colour space you specify in the printer profile.

 

[digidog]

Going back to the OP's issue -- I was recently advised to switch from ProPhoto RGB to Adobe RGB 1998 - because all LR works in Adobe RGB 1998, not all work in ProPhoto.

You were lied to. OR someone who doesn’t understand how the product works, like you, made such a false claim on the web and you not only accepted it at face value, you can’t accept the facts those of us with the facts are trying to provide to you to clear out your misunderstanding from whoever lied to you.

Why you feel the need to reject this is beyond me:

"The highest form of ignorance is when you reject something you don't know anything about". -Wayne Dyer

--
Andrew Rodney
Author: Color Management for Photographers
The Digital Dog
http://www.digitaldog.net