Show clipped pixels in RAW

[tomczak]

I find it v. useful to map in preview which pixels are maxed out or blocked. In RAW, there is 'show clipped pixels' switch. It inverts pixels that are 0% and 100% in HSV-V or HSL-L (I think), but only if dynamic range black and white point sliders are moved beyond 0-100% range, even if the histogram shows blocked/blow pixels without touching the Dynamic Range slider.

My technique is to move the Dynamic Range sliders slightly beyond the edges (e.g. -.4% and 100.4%) to display the clipped pixels. Using this maneuver, one has to take care not to look at histogram any longer, because clipped pixels, which become inverted in preview, are now counted by the histogram as if they were actual pixels.

Is there an easier way of mapping pixels that the Preview predicts will be clipped. I'm not sure if this is in the plans, but perhaps aligning what I would considered clipped on the preview histogram (i.e. the 0% and 100% bars) and what the Show Clipped Pixels show/doesn't show could be useful?

I think that ideally, the most useful mode of mapping clipped pixels would be having a switch in all previews (RAW and transformations) that could map pixels clipped in HSV-V (to show clipping in at lease one channel) or HSL-L (to show clipping in all channels). If the clipping definition thresholds could be user adjustable, that would be even sweeter... Would other people find it useful?

This has been discussed in the past, but the reason I bring it up again, is that no matter how many images I process, I always seem to miss some areas that I inadvertently clip and have to redo them after I realize it - having a real-time warning system would be great.

[bobsofpa]

Yes, we need something. I have never been able to figure out how to use the "show clipped pixels".

[Marpel]

Not sure it is relevant to the questions posed by Maciej, but "show clipped pixels" only works on the clipping that is caused when the user moves one/some of the sliders. The literature indicates pixels that are clipped at the time of capture in camera are not shown as clipped when the image is opened in the raw dialogue (for which I'm sure there is a valid reason, but I can't understand why).

Not to hijack the thread but I agree with Bob. I can't figure out how to make "show clipped pixels" work, either. Either white is the colour used to show clipped pixels (which is useless) or the dialogue doesn't work as I don't see any change when I turn it on and off, even when purposely moving the sliders so the image is grossly clipped.

Maciej, you mention "inverted pixels" a couple times. Can you further explain what this means as it relates to clipped pixels? Thanks.

Marv

[bobsofpa]

The only way I have been successful in showing clipped pixels is after converting the RAW to TIFF I use the brighness curve transformation. Use the Stair Step curve and move the right end just so that it shows (as close to the right edge as you can get it). Then go to preview and you will see your clipped pixels on the high end.

[den]

Hmmm.... Showing "clipped channel pixels" ?

The possibilities:
HSV Color Space model...
...(1) Either one or both of the HSV-V and HSV-S channels could have clipping
HSL Color Space model...
...(2) Either one or both of the HSL-L and HSL-S channels could have clipping
RGB Color Space model...
...(3) Any one or more of the R, G, or B channels could have clipping
...(4) RGB Luminance could have clipping

I think one needs to be more specific when requesting 'show clipped pixels'... ...just as there were discussions a while back regarding the merits of camera over-exposure indicating systems... 'blinking' over-exposure image representations of RGB Luminance or a maxed individual R, G, or B channel...

PWP5's Histogram tool is useful to find which channel(s) are clipped, especially if set to 'High' and if a map is needed, Extract the channel(s) and Apply a Mask Tool-BrighnessCurve in the manner described by 'bobsofpa' for both the right and left ends of the histogram.

[tomczak]

I think that showing clipping in HSV-V and HSL-L would be most practical, and these are colour coordinates PWP uses most often anyway: between the two I would know which areas are pure white, maxed out in at least one RGB channel, or pure black. If thresholds were user-selectable I could identify areas that are nearly blown or blocked. If that could be shown while adjusting the image, that could be quite useful, I think.

p.s. Clipped luminance can only occur if all three RGB are clipped, so showing clipped HSL-L would be the same thing. Is that true?

[tomczak]

I seem to be a master of blowing single channels without realizing it until afterwards. When trying to process portraits, for example, I consistently maxed out the Red channel in some areas when doing touch ups (e.g. on Overlay using Composite, observing the changes in Preview).

While not ideal, there are three techniques that i used as a makeshift warning system:

1) Readout tool - it works on Preview!: I used large probe size, guessed what area I could have blown, probe it and looked at HSV-V value being close to 100% - (which means that at least one RGB channel is maxed out or near maxing out). You can switch to RGB readout to find out which one, but it's usually obvious.

2) Histogram tool doesn't work on Preview, but it's fairly easy to do adjustments, hit the Apply button and get the HSV-V histogram of that version of the image. Then close that window and keep adjusting the original image(s), then do it again.

3) Similarly to the above, while a bit more complex, the blown and near blown areas can be mapped (i.e. their location shown): make adjustments, then hit the Apply button. Open a Mask Tool on this output image, hit the Brightness Curve Button, choose Stair Step, and drag the right endpoint of the curve slightly to the left (or the left endpoint to the right to show near-blocked shadows). Apply mask - pixels covered by mask have at least one RGB channel blown or nearly blown (the mask tool histogram uses the HSV-V channel). Close the Mask Tool and the image, keep adjusting and do it again when needed...