Request Preference Option to Match Color Spaces Between Library and Develop Modes

Thank you Johan.  Your response is apporpriate and understood.  I think thedigitaldog's response to my original post was perfect and very helpful for me in moving towards a solution.

The problem with these observations is that they can lead to the wrong conclusion. If people or companies do not understand why Lightroom uses different color spaces in develop and library, and do not know how to deal with that like @TheDigitalDog explained, then the conclusion is not that there is a problem in Lightroom that needs to be addressed. The conclusion is that more education is sometimes needed.

John, Thank you for the question regarding "companies discontinuing use".  It's a fair one.

Many hours of plowing through the web, broken up over several days, leading me through blogs, articles and rabbithole forum threads, etc, followed by conversations with friends in addition.  So this is an inferance based upon personal conversations and a couple explicit forum statements that I could point to if I could again find.  I don't have the energy to plow through all that again.  I just want to go back to making art with the little time that I have to do so, and will resign myself to toggling back and forth between modules until my purchased solution possibly hits that target.  Oh yes, no articles, blogs or official publications.

Thank you DigitalDog for your time and explanation.  This kind of deep drill into the specifics of this phenomenon is really helpful.  I understood that the Develop module uses ProPhotoRGB and assumed that it was more precise than the AdobeRGB employed within the Library module.  Your explanation of wider gamut and bit range makes clear why Adobe makes the choices they do for the Develop module.  This to me then begs to question, why do they not simply use ProPhotoRGB for all the modules for consistency?  I think the answer probably is that the Library and other modules usually have multiple images simultaneously displayed or rendered ready to display.  I assume that having to render on the fly so many images would considerably tax system resources, leading to slow unresponsive interaction and crashes for many.  I expect that most engineering is a series of tradeoffs to arrive at the best design achievable at the time.  Rarely is it the case that something wasn’t considered.

Honestly, I never really noticed this until I started working on a recent series of lowlight images shot on my Ricoh GR.  The images where color space changes were most obvious were shot in an urban environment at twilight at ISO 102400.   In Lightroom I turned the images to black & white, pumped up contrast and deepened blacks to the point where the noise started to more resemble extreme grain. 

I tried soft proofing (adobeRGB then the other selections) and it did not make a difference.  Perhaps this is due to the displays I have?  I run a pair of Dell U2415s (purchased 2016) from a MacPro 2013, 3.5GHz, 6-Core, 64GB RAM.  The Dells are wide-gamut, claiming 99% sRGB, but no claim to AdobeRGB.  I suppose therein lies the problem to which there is a purchasable solution.

A massive reengineering of an otherwise great program wouldn’t make sense, especially if it could have regressive impacts on it.  Technology always seeks forward I suppose.  Software chasing hardware chasing software chasing hardware… and all of it seeking increased capability.

"This inconsistency has led ... some companies to discontinue use of Lightroom"

I'm interested in learning more about this -- do you know of any articles, blog posts, etc. discussing this in particular?

Not likely to happen. First, the preview architecture in Develop is unique to all other modules and the most accurate preview of the data. Previews in Develop are working in its internal color space, which is Linear encoded "ProPhoto" (RGB primaries). 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. 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. 

What you propose would take a massive engineering redo and is unnecessary. You can make Develop soft proof the other modules.

Are you using a wide gamut display?