Histograms in Soft Proofing

[bjanes]

Normally, I don't pay much attention to the histogram when softproofing. I was softproofing a TIFF of an orchid that had been rendered into ProPhotoRGB and focus stacked with Helicon Focus. The softproof gamut warnings showed minimal OOG for either the monitor or print (yes, Andrew, I know these warnings are next to useless). When viewing the soft proof on a wide gamut monitor (NEC PA241w), I could see no difference between Perceptual and Relative Colorimetric, but the histograms were markedly different. What does this mean?

Thanks,

Bill

[Tim Lookingbill]

Whatever it means I'ld think you'ld first have to know what the histogram is representing on output. You have Simulate Paper/Ink turned on so any connection to appearance and that histogram and whether it is showing a combination of the Epson printer profile or what it's suppose to look like visually on paper is too complex to parse and be of any use.

Now I'm confused.

[digitaldog]

(yes, Andrew, I know these warnings are next to useless).

One of the reasons is, it's buggy! I suspect that's why you're seeing here.

[fdisilvestro]

It seems to me that the issue is that spike in the shadows which is perhaps out of the visible (or appreciable) range. One of the limitations of the histogram in LR is that you do not control de vertical axis scale so it is automatically adjusted. The rest of the histogram looks similar in shape, only at a different scale.

[digitaldog]

It seems to me that the issue is that spike in the shadows which is perhaps out of the visible (or appreciable) range. One of the limitations of the histogram in LR is that you do not control de vertical axis scale so it is automatically adjusted. The rest of the histogram looks similar in shape, only at a different scale.

Perhaps. It's very odd how the two differ due to just the RI. Maybe rendering both ways and looking at them elsewhere (Photoshop)? It does suggest that something here isn't visually correct/useful or both in terms of usefulness of the histogram.

[digitaldog]

I can't get close to replicating these differences with a number of very saturated images (raw and rendered) with the few Epson profiles I have (one custom, one canned). This is very odd. Could this be due to the focus stack? When I toggle the RI, I see the histogram change a bit as expected, but nothing like Bill shows. The image, the profile, the image stack? Bug?

[bjanes]

Perhaps. It's very odd how the two differ due to just the RI. Maybe rendering both ways and looking at them elsewhere (Photoshop)? It does suggest that something here isn't visually correct/useful or both in terms of usefulness of the histogram.

Andrew,

As you suggested, I loaded the file into Photoshop and looked at the histograms in the native ProPhoto space and the histograms after converting to the printer profile using RelCol and Perceptual. The two latter histograms look very similar, as expected.

The top image is the histogram of the ProPhoto file.
The next two images are histograms of the file converted to the print space with the indicated rendering intents. These are latter two histograms are quite similar, as expected.

Bill

[digitaldog]

Very odd. Another indication something isn't right in LR and another indication that the two Adobe teams are not treating the same data the same way which they should. Another indication of how Histograms can lie.

[Robert Boire]

The softproof gamut warnings showed minimal OOG for either the monitor or print (yes, Andrew, I know these warnings are next to useless). When viewing the soft proof on a wide gamut monitor (NEC PA241w), I could see no difference between Perceptual and Relative Colorimetric

I know this is off topic a bit, but why are these OOG warnings next to useless?

[digitaldog]

I know this is off topic a bit, but why are these OOG warnings next to useless?

The Out Of Gamut Overlay in Photoshop and Lightroom
In this 25 minute video, I'll cover everything you need to know about the Out Of Gamut (OOG) overlay in Photoshop and Lightroom. You'll see why, with a rare exception, you can ignore this very old feature and still deal with out of gamut colors using modern color management tools.

YouTube: https://www.youtube.com/watch?v=00O-GTDyL0w
High resolution: http://digitaldog.net/files/OOG_Video.mp4

[dwswager]

Normally, I don't pay much attention to the histogram when softproofing. I was softproofing a TIFF of an orchid that had been rendered into ProPhotoRGB and focus stacked with Helicon Focus. The softproof gamut warnings showed minimal OOG for either the monitor or print (yes, Andrew, I know these warnings are next to useless). When viewing the soft proof on a wide gamut monitor (NEC PA241w), I could see no difference between Perceptual and Relative Colorimetric, but the histograms were markedly different. What does this mean?

Thanks,

Bill

I personally think it has to do with the mixed meaning of the histograms.  With a composite of all 3 channels, the -levels 0-255 represent the number of pixels at that level relative to the total number of pixels.  However, when attempting to show the histograms of the individual channels, the program is attempting not only to show the difference of pixels at a single level relative to another level, but also to show a single level relative to another channel at that level.

[Robert-Peter Westphal]

I personally think it has to do with the mixed meaning of the histograms.  With a composite of all 3 channels, the -levels 0-255 represent the number of pixels at that level relative to the total number of pixels.  However, when attempting to show the histograms of the individual channels, the program is attempting not only to show the difference of pixels at a single level relative to another level, but also to show a single level relative to another channel at that level.

Andrew,

there is one mistake in your youtube video : As soon as you import a photo into Lightroom, it willbe converted to ProPhotoRGB ( with a linear gamma ), so it is no more in ColorMatch RGB. And therefor, it could be possible that that many colors are out of gamut when you do a softproof on ColoMatchRGB.

Robert

[bjanes]

Andrew,

there is one mistake in your youtube video : As soon as you import a photo into Lightroom, it willbe converted to ProPhotoRGB ( with a linear gamma ), so it is no more in ColorMatch RGB. And therefor, it could be possible that that many colors are out of gamut when you do a softproof on ColoMatchRGB.

Robert

While it is true that images will be converted to ProPhotoRGB with linear gamma, the histograms and readouts will still be reported out using an sRGB tone curve and the image will appear to be in the fictional Melissa space. If an sRGB image is converted to ProPhotoRGB using relative colorimetric (the only option available in PS) the colors will not change, but the image will occupy less of the ProPhoto space and this will be reflected in the histogram. No color will be forced out of gamut.

To demonstrate this, I rendered a rose into sRGB (I don't use colormatch) using default values on the sliders, and the image barely fits into sRGB as shown in the first image below. I then import the sRGB image into LR. The image is converted to ProPhotoRGB with a linear tone curve. The histogram uses a sRGB TRC and the image occupies less than all of the ProPhoto space as shown by the histogram values to the left of maximum. The color numbers have changed, but the colors they represent have not changed and the colors appear the same on screen (Macbook pro with retina display). This is the second image from the top.

If I render into ProPhotoRGB using the same settings, the ACR histogram (not shown) moves to the left. The colors are unchanged, but the color numbers are smaller with the larger color space and the histogram moves to the left. When I import into LR, the histogram is the same in both ACR and LR. Third image.

If I render into ProPhotoRGB, again in ACR, and adjust the sliders exposure, white, highlight, and black sliders for a more optimal rendering, but leave saturation and vibrance alone, the histogram fills up in both ACR and LR because of the increased color range. Fourth image.

Bill

[digitaldog]

Andrew,
there is one mistake in your youtube video : As soon as you import a photo into Lightroom, it willbe converted to ProPhotoRGB ( with a linear gamma ), so it is no more in ColorMatch RGB. And therefor, it could be possible that that many colors are out of gamut when you do a softproof on ColoMatchRGB.

LR honors the color space of all rendered images. However, the Histogram shows us MelissaRGB unless we setup the soft proof for that data (in this case, ColorMatch RGB). All editing of that data would be conducted in ProPhoto RGB with a linear TRC. No editing was conducted. The data is in ColorMatch RGB.
It would be ridiculous for LR to convert every rendered imported image into ProPhoto RGB (and it doesn't)! The edited iteration you export? Yes.

[digitaldog]

While it is true that images will be converted to ProPhotoRGB with linear gamma, the histograms and readouts will still be reported out using an sRGB tone curve and the image will appear to be in the fictional Melissa space.

It is only true when the edits are applied to the source data for a new iteration to be processed (in ProPhoto RGB primaries/linear TRC) leaving the original data untouched. LR doesn't convert rendered images to any color space upon import. It honors the color space. You can see this when you examine all rendered images in Develop, down in the calibration pane (Embedded). Further you can, and I do, create smart collections that can collect images based on their embedded color space. As you can see below, all sRGB embedded and of course imported images are shown:

[bjanes]

It is only true when the edits are applied to the source data for a new iteration to be processed (in ProPhoto RGB primaries/linear TRC) leaving the original data untouched. LR doesn't convert rendered images to any color space upon import. It honors the color space. You can see this when you examine all rendered images in Develop, down in the calibration pane (Embedded). Further you can, and I do, create smart collections that can collect images based on their embedded color space. As you can see below, all sRGB embedded and of course imported images are shown:

Andrew,

Thanks for pointing this out. As I understand the LR editing and display modules, the data of the imported file are never changed, but the edits and changes made by the user are stored as metadata and these are applied when the file is exported or printed. When one is working in the library, map, book, slideshow, print and web modules previews are created in the AdobeRGB space and these are used for display. In the develop module previews are in ProPhotoRGB. Where are these previews stored? For the library module, I think they are stored in the *Previews.lrdata file on the hard drive. When in the develop mode they may be stored in the Camera Raw Cache and held in memory when one is editing the image.Increasing the Camera Raw Cache to 20 MB or more is said to speed up editing. Do you have information on these matters?

When I look at the Calibration Panel for pixel images imported in LR, I see Embedded listed, but the actual profile, e.g. ProPhotoRGB is not shown. How does one get this information?

Bill

[digitaldog]

As I understand the LR editing and display modules, the data of the imported file are never changed, but the edits and changes made by the user are stored as metadata and these are applied when the file is exported or printed. When one is working in the library, map, book, slideshow, print and web modules previews are created in the AdobeRGB space and these are used for display. In the develop module previews are in ProPhotoRGB. Where are these previews stored? For the library module, I think they are stored in the *Previews.lrdata file on the hard drive. When in the develop mode they may be stored in the Camera Raw Cache and held in memory when one is editing the image.Increasing the Camera Raw Cache to 20 MB or more is said to speed up editing. Do you have information on these matters?
When I look at the Calibration Panel for pixel images imported in LR, I see Embedded listed, but the actual profile, e.g. ProPhotoRGB is not shown. How does one get this information?

Correct on all points above (not crossed out for simplicity in the reply). LR doesn't show you the embedded profiles but you can, as I illustrated, build smart collections to locate that data which of course is embedded in the image files. It might be nice IF instead of Embedded, it stated what the embedded profile was. Embedded is just an indication this isn't raw data, but a rendered image with some embedded profile. AFAIK, the Develop module uses Adobe RGB for previews in Develop and built on the fly while editing.
According to the must own, Lightroom FAQ from Victoria Bampton:



• Standard-sized rendered previews are used in all of Lightroom’s modules to some degree. (The standard previews are actually a preview pyramid, with lots of different sized previews, from large ones right down to thumbnails.)
• 1:1 rendered previews are primarily useful for zooming in to 1:1 (i.e. checking focus) in Library module or Draft Mode printing.
• Smart Previews (2560px long edge) are mainly used in place of original  les when the originals are of ine, but they can also help speed up Develop loading time.
• ACR Cache, or Camera Raw Cache, temporarily holds partially processed fast load data (1024px long edge) for the most recently accessed raw  les, and is used in Develop to speed up loading times.
• Fast Load DNG’s holds the same partially processed fast load data (1024px long edge) as the ACR Cache, but it’s contained in DNG  les permanently, whereas the ACR Cache is temporary. It’s only available for DNG  les, and you can learn more about these in the Appendix starting on page A-1.


• Behind the scenes, standard and 1:1 sized Previews are rendered Adobe RGB JPEG. These standard previews are fast for browsing, but the quality is too low for editing in the Develop module. That’s where Smart Previews come in.

[digitaldog]

Update after checking: Smart Previews (SP) and Fast Load Previews (FLP) and ACR cache files are both only partial rendered data, ALL other previews are fully rendered. So or course, they are not in Adobe RGB (1998). The Library previews are Adobe RGB, because the previews are stored as JPEGs.  JPEGs are necessarily 8-bit, and using big color spaces (like ProPhoto) will result in visible banding artifacts when limited to an 8-bit encoding.  Using an intermediate-sized color space like Adobe RGB avoids these artifacts, while providing a larger gamut than sRGB.  (Most monitors are limited to Adobe RGB anyways, so this is fine for display preview purposes.)

The reason Develop doesn't have this quantization problem, is because the image rendering isn't done 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).

[bjanes]

Correct on all points above (not crossed out for simplicity in the reply). LR doesn't show you the embedded profiles but you can, as I illustrated, build smart collections to locate that data which of course is embedded in the image files. It might be nice IF instead of Embedded, it stated what the embedded profile was. Embedded is just an indication this isn't raw data, but a rendered image with some embedded profile. AFAIK, the Develop module uses Adobe RGB for previews in Develop and built on the fly while editing.
According to the must own, Lightroom FAQ from Victoria Bampton:

Andrew,

I am still a bit confused about the use of ProPhotoRGB in the previews when one is editing the image. A post entitled "How Lightroom manages color" states:

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.

The by default qualification implies that there may be an option to use another color space, but there is no mention of how or why one would do this. ? to deal with colors out of the monitors gamut as implied by the soft proofing option.

Regards,

Bill

[digitaldog]

Andrew,

I am still a bit confused about the use of ProPhotoRGB in the previews when one is editing the image. A post entitled "How Lightroom manages color" states:

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.

The by default qualification implies that there may be an option to use another color space, but there is no mention of how or why one would do this. ? to deal with colors out of the monitors gamut as implied by the soft proofing option.

It's confusing, not clear and seems to have changed over time. Again, according to (I believe Eric), Develop isn't using JPEGs but partially rendered image data. It might very well be ProPhoto RGB-ish but it's not stored as a 'rendered'  preview in any color space like the other modules.