Lightroom color issue Develop vs Library modules

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.

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.

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

No text.

Jodes13 wrote:

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.

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

agrumpyoldsod wrote:

digidog wrote:

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.

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:

agrumpyoldsod wrote:

digidog wrote:

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: https://www.youtube.com/watch?v=WyvVUL1gWVs

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):
http://digitaldog.net/files/18Color%20Management%20in%20Lightroom.pdf

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 wrote:

digidog wrote:

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%20Management%20in%20Lightroom.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/imprint_downloads/peachpit/peachpit/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:

http://digitaldog.net/files/18Color%20Management%20in%20Lightroom.pdf

Facts bud!

Simon Garrett wrote:

A couple of points to your post:

agrumpyoldsod wrote:

digidog wrote:

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%20Management%20in%20Lightroom.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.

First, agrumpyoldsod is confused but hopefully the facts we both know and accept will sink in.

As for previews in LR.

Previews in Develop are working in its internal color space, which is Linear encoded "ProPhoto" (RGB primaries). That color space agrumpyoldsod can’t accept. As we both know, in terms of color gamut, Linear ProPhoto, ProPhoto RGB, and Melissa RGB all have the same color gamut because they use the same set of RGB primaries from ProPhoto RGB. As we both know, the difference between them is the encoding of the image values (e.g., linear encoding, 1.8 encoding, and 2.2 encoding, respectively). The differences in this encoding does not affect image appearance in previews. So, within the Develop module, how our images appear in Linear ProPhoto, regular ProPhoto, and Melissa RGB are all correct and all the same and for all files: raw, jpeg, tiff, dng, etc. The facts are however, in Develop, the previews are the unnamed internal color space.

The Library previews are Adobe RGB (1998), because the previews are stored as JPEGs. JPEGs are 8-bit, inappropriate for a wide gamut color space like Linear ProPhoto, ProPhoto RGB, and Melissa RGB. Using an intermediate-sized color gamut as found in Adobe RGB (1998), avoids artifacts, while providing a larger gamut than sRGB. Another reason why the LR user might consider a wide gamut display that closely approaches or exceeds Adobe RGB (1998).

The Develop module doesn't have quantization problems because the image rendering isn't using JPEGs. It is instead performed on the fly using the original image data (e.g., a raw file), using higher internal precision (at least 16 bits).

Within the Develop module, if a user has turns on soft proofing, the gamut is limited to whatever ICC profile the user has chosen for soft proofing.

Now perhaps but hopefully not, a return to the unreality bubble of agrumpyoldsod...

agrumpyoldsod wrote:

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