When evaluating a file in LR the Soft Proof values are incorrect. This has been documented as a bug Lightroom CC Soft Proof Histogram Displays Incorrect RGB Values. Has anything been done to fix this issue? If not, is there a work around? If not, what are you doing to correctly evaluate your RAW captures. Our studio will not upgrade beyond LR 5.7

Just to be clear the Loupe soft proof preview image is correct. It's just the color values displayed below the Histogram that are incorrect. You can view the "Destination Gamut Warning' by clicking on the icon in the upper right-hand corner of the Soft Proof Histogram panel. This only tells you when there is actual clipping, but still useful for making soft proof adjustments.

The Soft Proof Histogram appears to display the LR Native Color Space values (Melissa RGB) without RGB data conversion to the destination profile color space setting in the Soft Proof panel. As you've discovered the readings can be quite different and rather useless. I'd stick with using the onscreen gamut warning as the best solution for now:

This is not a workable solution in our studio. We need to know the exact values of several colors as we shoot mostly clothing for Levis, The North Face, Marmot and Nike. In LR 5.7 we have the capability. Reading between the lines, there is no work around for LR CC 2015 or LR 6? FYI, I checked both my LR CC 2015 External Editing settings and the settings for LR5.7. They are identical. So where is the RGB data conversion happening or not happening?

This has nothing to do with the External Editing Preferences settings. Currently there is no way to see the actual RGB soft proof values from inside LR 6/CC 2105 and LR 5.7 can't do CMYK soft proof at all. What is your current workflow and destination color space?

We currently use EOS Utility to shoot into a watched folder for LR 5.7. We use Adobe 1998 as our color space throughout. We do not use CMYK at all. We deliver RGB files. Therefore they must be color correct. I have been using a different workflow than the rest of the studio. I have using LRCC 2015 and EOS Utility. It wasn’t until last week I began to notice the discrepancy in what I knew the values to be and what LR CC 2015 was showing me in Soft Proof. We are using Canon 5DMIII and MarkII set to Adobe 1998 color space.

Since you don't need CMYK soft proof I'd stick with LR 5.7.1 until Adobe gets this issue fixed in LR 6/CC2015. Please add your +1 vote at my bug report and any comments, which will put you in 'following' status for updates. This may help to get Adobe's attention who hasn't even marked the bug report as 'Acknolweged.' Let me know if you have any other questions.

I can confirm that in LR 6.1.1 on Windows 10 the problem still exists.

I edited a CR2 (sky shot) to be pure blue - 0/0/100 %. It soft proofs to 37/7/230 for Adobe RGB.

I then exported from the CR2 a tiff in Adobe RGB space and imported it to LR. In several other applications the tiff is 0/0/255, in LR it is 41.9/18.7/95.6 % and when soft proofed to Adobe RGB it is 37/7/230. Soft proofed to sRGB it is 36/7/221 although when the tiff is converted to sRGB in PS it is (of course) still 0/0/255.

The impression I have from reading about the issue described earlier and elsewhere, which could be wrong since most of it was late last night, the erroneous softproof RGB numbers in LR 6/2015 are still in the LR-internal MelissaRGB colorspace instead of being converted to the selected output colorspace, i.e. the RGB version of the percentages we see without softproof turned on.

However, in your example the numbers are slightly different between your AdobeRGB and sRGB examples. Is this variance because the eyedroppering was at a slightly different spot or because there is still some math being applied that depends on the output colorspace, but not the correct math? sRGB is a slightly "smaller" colorspace than AdobeRGB and your blue component being reported is darker (221 vs 230 for AdobeRGB) so it seems that something could be happening just not the right thing. It would be easier to test with a contrived TIF that has the same value everywhere instead of a raw file that is pushed to pure cyan if that's what you have.

Remebering back to the end of 2013, the histogram display in softproof mode actually had two sets of numbers, the MelissaRGB values, a slash, then the output-colorspace values (or maybe the other way around). At some point the Melissa RGB numbers were removed and the output colorspace remained, but now with LR 6 perhaps the MelissaRGB number has returned in place of the output colorspace numbers.

Yes. I just verified the versions and I do have the latest and they are as you listed. Oh yeah, I still have the issue of inaccurate RGB values in both. Yes to the end of April report. I am puzzled that in four months Adobe has not addressed this issue. If I am not mistaken there have been at least one update since this BUG was discovered. Still nothing has been done. Maybe the few of us who use this information are too few for them to bother!

Well it has been another month and still no word from Adobe concerning this bug. I have confirmed that we have the latest Lightroom CC 2015. We have returned all of our production machines to Lightroom 5.7.1 as it is critical for us to know what the RGB values are in our files. I have done a screen capture of a color chart to graphically show the problem. I wonder how expensive it is to fix this bug? Wouldn't want to eat into Adobe's profits.

I have just asked the same thing. I was making a printer test chart with exact RGB colors, when I saw that Lightroom read these colors completely wrong. The only "colors" that Lightroom read correctly is greyscale. I have the latest CC version of Lightroom, so it seem they take their time to acknowledge this problem.