Black point compensation: excellent video

[DanK]

Someone sent me this link yesterday:

https://www.youtube.com/watch?v=Qy3YRDT3u_U&t=18s

It's an excellent tutorial on black point compensation--both thorough and very clear. He answered one question that was on my list to figure out during this isolation: he shows a simple technique for fixing black point without altering the higher parts of the histogram that you don't want to modify. He also explains why it's best to use a luminosity blend mode for this, although unless the change is sizable, it shouldn't make a very large difference.

[Manfred M]

Thanks for posting Dan - Excellent video and especially important for those that tend to print images with large amounts of very dark in them. Mitch explains things quite nicely but the quality of the YouTube videos is problematic and unless one prints a lot, the subtleties he discusses are not going to be well understood. I had assumed that Photoshop's black point compensation is more sophisticated that it is.

Regardless, it's great to see someone who knows the subject well putting out a series of videos like these.

[DanK]

I also appreciated how well organized his video was. It was one of the clearest I have seen in a long time.

[Donald]

It is indeed an excellent video. A very clear explanation of a procedure that I though was much more complicated than he shows it to be. Bookmarked for future reference. Thanks, Dan.

[xpatUSA]

Very clearly expressed, However, at about 2/3 the way through, I'm puzzled by the statement that messing with the left output slider in Photoshop Levels "moves the whole histogram to the right". That is not my experience in other apps where that same slider scrunches up the histogram with very little change to the highest levels.

[DanK]

Very clearly expressed, However, at about 2/3 the way through, I'm puzzled by the statement that messing with the left output slider in Photoshop Levels "moves the whole histogram to the right". That is not my experience in other apps where that same slider scrunches up the histogram with very little change to the highest levels.

Hmm. Not having used any other pixel editor for years, I can't comment on others. However, I was able to replicate what he showed using Photoshop. It only happens, of course, if there is data at the end you are moving. Here are histograms from an image with squashed shadows only in the blue channel, before and after moving the output minimum from 0 to 10. The changes aren't dramatic and are a bit obscured by the rescaling caused by the peaks, but you can see it nonetheless.

Before:




After:



Note that this histogram shown in the levels adjustment panel doesn't change, as that is the input histogram. It's the histogram for the image displayed that changes.

[xpatUSA]

Thanks for the comprehensive reply.

My main concern was with that statement that the histogram shifts to the right. Perhaps I should explain how I understood that. If the aforementioned slider moves up by 10, I would expect highlights to move by the same amount.

Does this really happen in Photoshop? Hard to tell from your posted histograms, sorry.

In the GIMP, I just now had a highlight peak at 233 when the Levels left-side output slider was at zero. When I moved that slider to 10, the said highlight peak did not go to 233+10 = 243 as implied by the video. It went to 236 as one should expect, IMHO. And, of course, the change in highlights in the preview image was invisible to my old eyes ...

[DanK]

If the aforementioned slider moves up by 10, I would expect highlights to move by the same amount.

I don't think that's what he meant, and it's not what I observe happening. The top of the histogram doesn't move, or at least moves very little. Thererefore, there has to be a rescaling of the x-axis. That rescaling doesn't seem to be uniform, but it's very hard to see. For example, while it is hard to see because of the vertical rescaling, but it looks like there is a substantial change around the second mode from the left in the blue distribution. The green and red don't seem to be changed much, which is intriguing. Those distributions ended above the new minimum I imposed. So perhaps the adjustment is greater for channels with more mass at the bottom. But I'm just guessing.

[pschlute]

Replying to bookmark .

[revi]

Afaik, the appearance of the sharp spikes in the histogram is typical for the rescaling to a narrower range of an image with 8-bit/channel integer format.
This is due to the rounding errors introduced by the scaling, leading to two input values being mapped to the same output value (unavoidable, as you have
less output values than you have input values).

If the histogram were just shifted, there would be one spike at the highlight end, with the highlights crushed into 255.
You could also get wraparound of the values, with the extreme highlights appearing as black (which is mathematically logical, as you work module 256,
but something you really don't want to happen in an image)

[xpatUSA]

Afaik, the appearance of the sharp spikes in the histogram is typical for the rescaling to a narrower range of an image with 8-bit/channel integer format.

This is due to the rounding errors introduced by the scaling, leading to two input values being mapped to the same output value (unavoidable, as you have less output values than you have input values).

If the histogram were just shifted, there would be one spike at the highlight end, with the highlights crushed into 255.

You could also get wraparound of the values, with the extreme highlights appearing as black (which is mathematically logical, as you work [modulo]256, but something you really don't want to happen in an image)

Agreed 100 per cent, Remco.

[Manfred M]

If the histogram were just shifted, there would be one spike at the highlight end, with the highlights crushed into 255.

As a print maker, I would have a problem with this as much as with loss of details on the dark end. While black point compensation brings out detail in the darkest areas. At the white end the problem is even bigger as no ink is deposited in these areas leaving bare spots that are quite noticeable as these reflect light differently than areas with ink on them.

[DanK]

This is due to the rounding errors introduced by the scaling, leading to two input values being mapped to the same output value (unavoidable, as you have
less output values than you have input values).

Exactly. A common problem when graphing discrete distributions.

f the histogram were just shifted, there would be one spike at the highlight end, with the highlights crushed into 255.
You could also get wraparound of the values, with the extreme highlights appearing as black (which is mathematically logical, as you work module 256,

In the case of modular arithmetic, yes, but I haven't seen any sign that photo editing software does modular arithmetic. Everything I have seen suggests that it simply censors the data, leaving a spike and the minimum or maximum value. Or were you just writing about another theoretical option for dealing with a shift?

[revi]

(...)
In the case of modular arithmetic, yes, but I haven't seen any sign that photo editing software does modular arithmetic. Everything I have seen suggests that it simply censors the data, leaving a spike and the minimum or maximum value. Or were you just writing about another theoretical option for dealing with a shift?

Well, it's what can happen in addition of integers: overflow used to mean that only the last (least significant) bits of the result were kept, which corresponds to an addition modulo 256
(the CPU also set an overfow flag, but it was up to the programmer to check that flag...).

And it's certainly not something you'd want to consider as a way to deal with shifts as discussed here.
If you do that to a grayscale image, you end up with the center of highlights switching to black.
In colour images, the center of highlights could end up black, or a very bright, saturated colour (depending on which channels wrap around).

So the only option (when starting from images with 8 bit/channel) is a scaling, as shown in the video. A better solution would be to do that
scaling on the image while it's still in 16 bit/channel (or in a floating-point format). Not sure how well that would fit in a typical workflow, though:
either the photographer provides a file in such a format (which means dealing with much larger files if sticking to currently common formats),
or the photo editor has to take into account the printer limitations.