Robert_Lay's Raw tutorial - clipped highlight exposure margin

Robert has made mention of his Adobe Camera Raw tutorial here.

I just picked up my EOS 20D (2.0.3 firmware), put a Speedlite 580EX in the hotshoe in ETTL mode, an EF 24-70mm f/2.8L lens on the camera, and deliberately shot a flash picture with a fairly wide tonal range using too much positive FEC to deliberately blow the highlights. ISO 400 was the minimum ISO to get the desired exposure with bounced flash, so I used ISO 400. I'm using ACR 3.3 (final) in Photoshop CS2.

If you set all the sliders on the first two pages to 0 apart from the White Balance, then hold down Alt and slide the exposure upwards, the best agreement between the white pixels in ACR (clipped in all channels) and the flashing pixels on the camera display came to +0.45. I believe Robert is suggesting this figure is likely pretty static across all Canon cameras is correct - has anyone got any other results for Canon DSLRs?

In ACR 3.3, you can save these settings, by dropping down the menu, choosing Save Settings Subset, checking everything except White Balance (you're better off using the White Balance in the file), and saving. I called it "Blown highlight check", which is now in my drop down menu of settings in ACR.

I have got some hard clipped pixels in the image, seen by holding down ALT and dragging the Exposure slider to -4.00. Keeping ALT down, when I drag that slider upwards, I first see more 'white' pixels (clipped in all channels) at -1.55, and a large increase in those 'white' pixels starting at around -0.85. These are the values that, I presume, mark the initial onset of soft clipping, and where soft clipping becomes significant.

At this point Robert writes, in the tutorial:

I'm not quite clear how you're suggesting we relate the two values I've found to anything useful when using the camera.

Finally, there's talk about finding the point at which the clipped pixels don't reduce in number - in my image that's at around -1.25. Again, I'm not sure what the meaning of this is.

Robert, or anyone - I'd appreciate your clarification. If you, or anyone else wants the .CR2 file and a JPEG of the camera's LCD, please PM me.


David

Dear David,

When reviewing images in-camera (with the blinking histogram) we are able to determine whether any portion of the image is clipping or not. Obviously, you want to know if the amount clipped is recoverable or not.

I think you will agree that in the latest revision of the tutorial (5th Revision) the procedure for evaluating how much clipping is recoverable is a bit lengthy to repeat here, but in my testing of the G5, the answer is one full f-stop. In your testing of your camera, I believe you arrived at a value of 0.45 - (-0.85) = 1.30 f-stops.

So, the way in which we use that information with the in-camera display is quite simple. If I were to take a shot and saw no clipping whatsoever followed by another with one additional stop of exposure and that shot shows some clipping, then I could be sure that whatever clipping has occurred, it would be recoverable.

In your case, you could take your second exposure at an increase of 1.30 f-stops and still be assured that you would be able to recover all clipping.

That's all we gain from our improved knowledge about clipping and recovery of lost detail - but that's better than not knowing at all, or thinking that the clipping is all non-recoverable, isn't it?

I really need to think further about this, but I think I'm with you.

Are we suggesting from this result that it sounds like there's about 1 1/3 stop latitude between a pixel flashing on the LCD display, and hard clipping?

David

One of the problems I've seen in the past is when clipping small areas. Since I shoot a lot of birds & animals I've had times when small details - like part of an egret's feather - blow out. If the blown out section is too small it might not show on the LCD. Each pixel on the LCD represents about 70 pixels, a little larger than an 8x8 block of pixels. It's pretty difficult to see a single blinking LCD pixel, too.

So I have a tendency to err on the side of caution - if I see blinkies on the LCD I'll back down the EC according to how many blinking pixels I see. That is, if I see small blocks of blinkies I may back down 1/3 stop, large blocks of blinkies maybe 2/3. And so on. Otherwise I like to see the histogram about 1/3 of a stop from the right edge. I've found that to be pretty good for me, depending on the scene.

I must say that RSP's highlight reduction feature works pretty well, and that's helpful, but I still don't like to blow out anything.

Geesh....more to study.

Maybe I'm saying the same thing, but the way I would put it is this:
We have located a point "A" on the Exposure Slider beyond which to the right we would be clipping more and more pixels. That point is a point at which only the hard clipped pixels are shown in the clipping display.

We have also located a point "B" on the Exposure slider which brings the ACR clipping display into exact correspondence with the in-camera clipping display. That point is a point at which we have all of the hard clipped pixels AND all of the soft clipped pixels showing in the clipping display.

By subtracting the position of point A from the position of point B we have the number of f-stops that correspond to the difference between B = (hard clipped + soft clipped) and A = (hard clipped), which leaves just the soft clipped pixels. B - A = (soft clipped)

In other words, if we have properly determined the locations of points A and B, then we know that for that exposure the exact amount of overexposure in f-stops that we were able to recover (all the soft clipped pixels).

There's no easy way to say all this.

If I properly interpreted the data that you gave on your camera (which was somewhat ambiguous as to point A) then your camera can recover up to 1.33 f-stops of overexposure, maximum.

I think I can agree with the way you worded it if you include that it's measured from the first point where the first pixels start blinking on the in-camera display.

I don't think I could argue against a conservative approach. Fortunately, I have no personal interest in any particular approach or any particular software tool(s). My sole interest is to promote a better understanding of the inner workings of the tools that we use. It's really challenging stuff to work with when you consider that you have two black boxes talking with each other in a format that is hidden from us, and all we can see are the user interfaces