A Workflow with Beta RGB

[digitaldog]

It should be possible to do this as a 3rd-party panel in Photoshop, I think.  It would have to be done by Adobe for Lightroom, I think.

Someday I'd like to see it in ACR and LR. I'm told it's possible, the question is, does Adobe feel it's worth the engineering time and money? Do many of their customers?

[Ellis Vener]

In a different vein,
In practice how does Lindbloom's Beta RGB compare to  the Joseph Holmes authored EktaSpace 5 and  the D-Cam profiles? http://www.josephholmes.com/profiles.html

[Jim Kasson]

Hi Jim ... you're still leaving me behind, I'm afraid.  Are you referring to your previous post where you say: "Or does it? There's nothing to say that the points in the image that give you the top part of the red histogram channel are the same points that give you the top part of the blue histogram channel. We're just lucky that it happens to work out that way for most images."?  So that gray, for example, will give the same histogram peak as its RGB components separated out, as you show.

Yes, indeed.

It would be useful to explain what a color histogram actually is (which I assume is one of the things you are attempting to do?).  My understanding is that its essentially a graphical representation of the tonal range of the image.  As such, its main use is to give us an idea about things like shadow and highlight clipping, whether the image is under-exposed or over-exposed ... that sort of thing.  It isn't intended to show whether or not parts of the image are out of gamut (how could it? the image will never be OOG in its own color space), and so we shouldn't use it for that purpose (I can't imagine that anyone would).

So I'm not sure what your point is .

Robert

Robert, maybe we're in "violent agreement" on this issue. Sounds like we agree that the histogram is a lousy tool to use to examine the gamut of an image, which was my main point.

Now, on to the details...

You said earlier: "Why is it that we are lucky?  We can always adjust the saturation of individual colors, surely, so if we adjust the red but it's quite separated from the blue ... so what?  I think I'm definitely missing something here."

Being lucky, in this case, meant that the information at, say, the top of each plane of the histogram came from the same group of pixels. It usually, but most certainly not always, does. If it does, when all the planes are moved to the right, it means a part of the image that has almost no chroma will appear with a luminance near paper white, in conventional wisdom, A Good Thing. If it doesn't, moving the top of the histogram planes to the right can result iin out-of gamut colors, especially is monstrously large color spaces.

On a related point, you say, "We can always adjust the saturation of individual colors..." With the histogram, we can't see how saturated any color is.

You also said earlier: "...and this is reflected in the histogram since this is a linear representation of the saturation of the image at every luminance point (more or less)"

First, in Ps, the horizontal axis of the histogram is in general non-linear. That axis is in the non-linearity of the working RGB color space. Unless you work in Ps in a color space with a gamma of one (or less!), the horizontal axis of the histogram will give more weight to darker colors than a linear scale would. This is appropriate almost all the time becasue of the nonlinearities inherent in the human visual system. Aside: As a corollary of this, the 18% reflectance point will occur at a different place in working color spaces with different gammas. This is important if you edit sometimes in, say, Adobe RGB with its 2.2 gamma, and PPRGB, with its gamma of 1.8. In Ps, the vertical axis of the histogram is linear (all the time? I'm not sure. Andrew?).

Second, as I think we now agree, the histogram doesn't represent saturation at all.

Are we good now?

Thanks,

Jim

[Robert Ardill]

Someday I'd like to see it in ACR and LR. I'm told it's possible, the question is, does Adobe feel it's worth the engineering time and money? Do many of their customers?

Personally I think that it's shocking that Photoshop doesn't already have it.  PS is a high-end, expensive program and I find it amazing that it lacks so many basic features that have to be provided by 3rd-party plug-ins (or even work-arounds like making ACR a 'filter' ... because it has many editing features that are better than Photoshop's).

As for Lightroom ... well already many photographers aren't using Photoshop, so if Adobe keeps adding features they may end up shooting themselves in the foot.  On the other hand Lightroom has some serious competition ...

It would be useful if LuLa conducted a survey of its members on this subject.  I wouldn't think too many members would give a rating than better than 1 in 10 to the current gamut warning features in either program. After all, PS's Gamut Warning doesn't even work at the dark-end; and the Color Range out of gamut selection doesn't even tie in with the proofing out-of-gamut, so it can't be used to create an OOG mask for ink-jet printers!

Robert

[Robert Ardill]

On a related point, you say, "We can always adjust the saturation of individual colors..." With the histogram, we can't see how saturated any color is.

You also said earlier: "...and this is reflected in the histogram since this is a linear representation of the saturation of the image at every luminance point (more or less)"

Second, as I think we now agree, the histogram doesn't represent saturation at all.

Are we good now?

Hi Jim ... yes we're good.  I just used VERY sloppy language! What I meant of course is that the histogram is a representation of the proportion of pixels that are at a particular luminance level in the image. So if the image is pure black, the histogram will show all pixels at one point to the far left; if the image is gray, there will a one line near the center (the position depends on the working-space gamma, as you point out); if the image is mostly dark, there will be a bump at the left end, mostly light will result in a bump at the right end etc.  

Robert

[Robert Ardill]

Being lucky, in this case, meant that the information at, say, the top of each plane of the histogram came from the same group of pixels. It usually, but most certainly not always, does. If it does, when all the planes are moved to the right, it means a part of the image that has almost no chroma will appear with a luminance near paper white, in conventional wisdom, A Good Thing. If it doesn't, moving the top of the histogram planes to the right can result iin out-of gamut colors, especially is monstrously large color spaces.

Hmm. Jim, I'm not sure I quite get this.  Let me see if I can put it in plain English.  We have two separately illuminated objects in the image; the rest of the image is pure black.  One of the objects is a red tomato with a green spot in the middle.  The other object is a green apple.  (our reds and greens happen to be pure R and pure G). Because of the shape of the fruit the illumination is not uniform. The light we use favors reds, so that the red tomato is brighter than the green apple and the green blob on the tomato is in the same brightness range as the green apple (but darker than the darkest spot on the red of the tomato).  So our histogram should now show a nice curve for the green of the apple, with another nice curve to its right for the red of the apple.  What we don't see is that part of the green curve is made up of the green from the green blob on the tomato.

If we clip the red bell curve by pushing up the image brightness, what we would expect to happen would be that the tomato would go white but the green spot in the tomato and the green apple would stay green (a brighter green).  So the white tomato is 'OK' ... at least logically .  However, the green of the blob and the green of the apple may well get pushed out of gamut.  If the gamut of the working space is smaller than the gamut of the destination then the apple and green blob would stay in gamut; if we are using ProPhoto it will almost definitely go out of gamut.

If we repeat this with a different illuminant, so that the red and green bell curves overlap, then both the apple and tomato, including its green blob, will all go white happily together.  However, on their way to white, either the reds or the greens could well go out of gamut, right?

So, in plain language, is this what you are saying?  If so, then it's a compelling case to take care when adjusting the image brightness!  And also a compelling case not to use the histogram to try to figure out if parts of the image are within gamut or not.

Robert

[Robert Ardill]

Andrew or Jim,

Have a look at this image+histogram and tell me if the histogram is right or wrong:



The image is just a yellow gradient, going to white ... so the red and green histograms seem fine.  The blue histogram should surely be flat in the left half of the image, shouldn't it?

The histogram looks much the same in Lightroom (although the yellow part is pushed further to the right ... presumably because of the sRGB gamma LR uses for the histogram?).

Robert

[digitaldog]

Everything you thought you wanted to know about Histograms

Another exhaustive 40 minute video examining:

What are histograms. In Photoshop, ACR, Lightroom.
Histograms: clipping color and tones, color spaces and color gamut.
Histogram and Photoshop’s Level’s command.
Histograms don’t tell us our images are good (examples).
Misconceptions about histograms. How they lie.
Histograms and Expose To The Right (ETTR).
Are histograms useful and if so, how?

Low rez (YouTube): http://www.youtube.com/watch?v=EjPsP4HhHhE
High rez: http://digitaldog.net/files/Histogram_Video.mov

[MarkM]

The blue histogram should surely be flat in the left half of the image, shouldn't it?

There is no part of the histogram that represents the left half of the image. A histogram is simply a bar chart counting the total number of pixels at each value. There is a left half of the histogram, but this in no way corresponds to the left half of the image.

It may be helpful in this case to look at the gradients in the individual channels. There you'll see the red and green channels have a gradient that goes from about 150 to 255 and the blue channel has a gradient going from black to white. This corresponds to the histogram.

One strangeness is that the histograms are not flat in any channel when you make gradients with the gradient tool. Photoshop by default uses a gaussian distribution with the gradient tool and this is reflected in the inverted bell curve of the histogram. If you want flatter histograms you can set the gradient smoothness to 0% in the tool setup.

[digitaldog]

If you want flatter histograms you can set the gradient smoothness to 0% in the tool setup.

Where's that?

[MarkM]

Where's that?

In the gradient editor box. (I'm not sure what the official name is). With the gradient tool selected, click on the little gradient selector in the tool bar. (screen shot attached).

[digitaldog]

In the gradient editor box. (I'm not sure what the official name is). With the gradient tool selected, click on the little gradient selector in the tool bar. (screen shot attached).

Got it, thanks, good tip.

[Jim Kasson]

Hmm. Jim, I'm not sure I quite get this.  Let me see if I can put it in plain English.  We have two separately illuminated objects in the image; the rest of the image is pure black.  One of the objects is a red tomato with a green spot in the middle.  The other object is a green apple.  (our reds and greens happen to be pure R and pure G). Because of the shape of the fruit the illumination is not uniform. The light we use favors reds, so that the red tomato is brighter than the green apple and the green blob on the tomato is in the same brightness range as the green apple (but darker than the darkest spot on the red of the tomato).  So our histogram should now show a nice curve for the green of the apple, with another nice curve to its right for the red of the apple.  What we don't see is that part of the green curve is made up of the green from the green blob on the tomato.

If we clip the red bell curve by pushing up the image brightness, what we would expect to happen would be that the tomato would go white but the green spot in the tomato and the green apple would stay green (a brighter green).  So the white tomato is 'OK' ... at least logically .  However, the green of the blob and the green of the apple may well get pushed out of gamut.  If the gamut of the working space is smaller than the gamut of the destination then the apple and green blob would stay in gamut; if we are using ProPhoto it will almost definitely go out of gamut.

If we repeat this with a different illuminant, so that the red and green bell curves overlap, then both the apple and tomato, including its green blob, will all go white happily together.  However, on their way to white, either the reds or the greens could well go out of gamut, right?

So, in plain language, is this what you are saying?  If so, then it's a compelling case to take care when adjusting the image brightness!  And also a compelling case not to use the histogram to try to figure out if parts of the image are within gamut or not.

Robert, what you say sounds about right, but without a concrete example image, I can't exactly figure out what you're saying. But consider the example images that I posted above, the one with 3 squares with sRGB values, 119,0,0; 0,119,0, and 0,0,119, and the other one with one square with sRGB values 119,119,119.

Moving the right-hand arrow on the Ps Levels tool (the one that changes the white point) to the left on the one-square image so that the histgram right peak gets well above 200 will result in the white rectangle when printed, approaching paper white.

Moving the right-hand arrow on the Ps Levels tool to the left the same amount on the three-square image will result in none of the colored rectangles, when printed, being within the gamut of any reflective mode printer known to man.

And the histograms of the two modified image will still be the same.

Coming at it another way, if the definition of saturation within an RGB color space is the percentage distance from the white point to the maximum available chroma at a given luminance and hue angle, the three squares in that image are all 100% saturated. The grey square is 0% saturated. Yet the histograms are the same.

By the way, the above definition of saturation is different than the one that's used when the  reference gamut is that of the human visual system., although the change is but one word: the percentage distance from the white point to the maximum visible chroma at a given luminance and hue angle.

I think I'm going to bow out of this discussion now. We appear to be on the same page. You're in good hands with Andrew (although I have to admit that I've never watched any of his videos -- I can't stand to watch instructional videos).

Jim

[Robert Ardill]

Everything you thought you wanted to know about Histograms

Another exhaustive 40 minute video examining:

What are histograms. In Photoshop, ACR, Lightroom.
Histograms: clipping color and tones, color spaces and color gamut.
Histogram and Photoshop’s Level’s command.
Histograms don’t tell us our images are good (examples).
Misconceptions about histograms. How they lie.
Histograms and Expose To The Right (ETTR).
Are histograms useful and if so, how?

Low rez (YouTube): http://www.youtube.com/watch?v=EjPsP4HhHhE
High rez: http://digitaldog.net/files/Histogram_Video.mov

Thank you for your video Andrew ... very illuminating, as usual!  It certainly shows that I did not understand the color histograms!!

I have to say that the color histograms are highly non-intuitive and I really wonder how many photographers understand them!  To have a red to white gradient showing a blue and green histogram at the left with a count of zero ... is about as crazy as it gets IMO.  Although showing no red as cyan gets pretty damn close!  I don't see the value of that sort of histogram at all because it's much more likely to confuse than to inform.  And to have a luminosity histogram (which at least makes sense) as the main histogram, and a crazy RGB histogram on the levels adjustment ... well, what can I say?

Fortunately for me I've only ever used the luminosity histogram ... and now that you've explained the others to me I firmly intend to stick to it!

Robert

[Robert Ardill]

There is no part of the histogram that represents the left half of the image.

My sloppy language: I meant the left half of the histogram in the image.

Robert

[MarkM]

I think most photographers use the RGB histogram simply to check for clipping and not for much else. It's possible to have a luminance histogram that sits comfortably in the middle of the chart while in reality you are clipping a single channel. For example a image filed with sRGB(255, 0, 0) will give you a luminance histogram that shows a bar at 76. If you pushed up your exposure based on this you would horribly clip your red channel. In that sense it's somewhat useful for scenes filled with saturated colors although it would be more so if cameras could give you histograms that reflected the raw image.

Video editing software traditionally has a few tools that are arguable more useful like waveforms and vectorscopes that I think would be quite handy in photoshop especially if you are trying to edit colors to a particular target.  I've seen some plugins for these, but have never tried them.

[Robert Ardill]

I think most photographers use the RGB histogram simply to check for clipping and not for much else. It's possible to have a luminance histogram that sits comfortably in the middle of the chart while in reality you are clipping a single channel. For example a image filed with sRGB(255, 0, 0) will give you a luminance histogram that shows a bar at 76. If you pushed up your exposure based on this you would horribly clip your red channel. In that sense it's somewhat useful for scenes filled with saturated colors although it would be more so if cameras could give you histograms that reflected the raw image.

Video editing software traditionally has a few tools that are arguable more useful like waveforms and vectorscopes that I think would be quite handy in photoshop especially if you are trying to edit colors to a particular target.  I've seen some plugins for these, but have never tried them.

Yes, I suppose that's just the limitation of a histogram, in that it requires interpretation and doesn't always give an intuitively correct picture of what's in the image.  I can see that a green 100 to gray 100 gradient, for example, has a problem: after all green will be at 100 across the whole image, so a full-size spike at 100 for green makes sense.  At that slice of the image, R=B=0, so all of the red and blue pixels are at zero, so it makes logical sense to show a full size spike at 0 for both red and blue (after all, how else do we represent black on a histogram?).  At slice R=B=1, green is still 100, so no difference there, but now 1% of the pixels are R=B=1 and 99% of the pixels are R=B=0, so again, a full size spike for both red and blue at that position.

The confusing thing is that the histogram is representing both 0 and 1 in the same way.  It would have helped to have some visual representation of that, at least on the channels that are shown separately, for example with pixels with a value of 0 being black and with a value of 1 having the channel color.  So that a Green 100 to Gray 100 gradient would look like this:



But, as you say, using the luminance histogram on its own won't show potential channel clipping, so we do need the separate channel histograms.  It would have been very useful to be able to select a Lab histogram.

Gradient histograms are particularly confusing though ... real image histograms are more understandable.  But there is quite a lot to be learnt about histograms playing around with gradients, and also combinations of red, green and blue.  At least it helps to see where the one's interpretation might be wrong.

Robert

[GWGill]

That you are sqeezing the whole gamut of ProPhoto into the printer space with perceptual rendering is false.

Well, of course it depends on how the gamut mapping is setup.

Current CMMs are dumb in that they do not look at the colors that are actually in the image but merely squeeze the image by some arbitrary value, which usually leaves OOG colors after the perceptual rendering.

I'm not sure which CMM"s you are thinking about, but your statement doesn't apply to ArgyllCMS, which uses actual gamut mapping as opposed to some sort of arbitrary compression. If you create perceptual or saturation intent tables you have to specify a source gamut. If you use the default it will be that of the source color space (which is a bad idea if that is a wide gamut space like ProPhoto), or you can override that and use the gamut of the images you intent to gamut map.

[GWGill]

And now that we're not arguing that point, here's a link to an algorithm for gamut mapping that my admittedly biased and interested self believes would be an improvement over the point-process gamut mapping algorithms used today.

Some work has been done on spatial gamut mapping, as a survey of the literature will show, and even I presented something on it at the Fogra Colour Management Symposium in 2010. But most people are well below that rung on the gamut mapping hierarchy of refinement:

   1. No gamut mapping - clip
   2. Arbitrary compression (possibly what CMM's that don't allow a specific source gamut have to do)
   3. Specific colorspace to colorspace mapping
   4. Specific image to colorspace mapping.
   5. Spatial gamut mapping.

Most people are probably at 2. Those using ArgyllCMS tiffgamut + collink + cctiff are at 4. It is worth exploring the rungs above 2 before leaping to the conclusion that 5 is worth the effort at the moment.

[GWGill]

This profile (DCam 5) makes ProPhotoRGB looks small and it is the only profile I have seen that ecompasses all visible colors (not even LAB)

By definition, L*a*b* encompass all visible colors. Perhaps you actually mean that L*a*b* with a* and b* restricted to the range -128 to +128 can't represent all visible colors ?