Shadows, 16-bit to 8-bit conversion, brightness transform

[Robert Schleif]

The useful dynamic range of many cameras now exceeds eight bits if images are recorded in raw format and if they are then converted to 16-bit tiff (sometimes called 48-bit when counting the three rgb colors). Because computer monitors and prints display eight bits of dynamic range or less, any useful information contained in bits nine and below, i.e. shadows, is lost or must be squeezed into the eight bits that are retained when jpegs or 8-bit tiffs are generated or when printing. (In converting 16-bit tiff to 8-bit tiff or jpeg, the bottom eight bits are just discarded.) Manipulating 16-bit images to preserve this shadow information (if the shadow information has not been specifically amplified in the course of the transformation from the raw file) is not as easy in PWP as it might be because the abscissa scale in the brightness curve transformation is linear. This means that all the shadow information below the eighth bit is compressed into the bottom 0.5% of the input brightness coordinate. To see this shadow information in an image and to shift everything else in the image to pure white, apply the following brightness curve. (Because it is too difficult to define the appropriate transformation by the usual method of shift-clicking on parts of the brightness histogram, save the following as an asci text file with the name shadow.crv, and load this file from the Gray/Brightness Curve transformation.)

Curve 1.0
npts 3
style linear
histexpand 0
point 0 0 1
point 1 1 255
point 2 255 255
end

The following observations can be made.
1. It would be useful if the brightness curve transformation in PWP would permit, as an option, the use of logarithmic intensity scales which, in the case of 16-bit images would cover the full 2 exp(16)= 65,535-fold intensity range possible. This would also require appropriate changes to curve files.

2. A brightness transformation that transforms some shadow detail into the top eight bits of a file, while for some images, retains decent contrast in the brighter part of an image is the following. I expect that more complicated spline curves would do a better job.

Curve 1.0
npts 5
style linear
histexpand 0
point 0 0 1
point 1 1 3
point 2 2 5
point 3 8 8
point 4 255 255
end

3. If brightness transformation curves could readily be defined for 16-bit files, it would be possible with high-grade digital cameras to mimic with a high degree of control the forgiving S-shaped density vs light intensity curves that are characteristic of film. The transformation given in #2 is a step in this direction. Such an approach may prove easier than adjusting slider controls in the raw converter.

[jsachs]

I don't believe you are thinking about the difference between 8 and 16 bits correctly.

First, the eye cannot distinguish even 256 different gray levels, so 16 bits is overkill.

Second, the use of gamma 2.2 ensures that the 256 brightness levels in an 8-bit image are pretty well aligned with the more or less logarithmic sensistivity of the eye, so the 256 levels provide enough gradations to handle what the eye can distinguish.

Third, what discarding the low order 8 bits does is not throw away shadow detail but throw away intermediate gradations between each of the 256 gray levels. If a 16-bit image is scaled so that its dynamic range extends more or less over the full range of available values, the corresponding 8-bit image will be visually equivalent to the 16-bit image. Thus, once you set the brightness curve for the image using 16 bits, for most purposes you can convert down to 8 bits and not lose any useful information.

[den]

Nuances: ...perhaps not necessary for human visual, monitor, and printer capacities...

...but if one is concerned about transformation of the "lower 8 bit depths" that affect "pixel to pixel graduations" of 16-bit [48-bit color] image files [or Black-White images where initially R=G=B, 48-bit color], then the transformation needs to take place in the RGB color space model where all three channels interact with each other and not independently as in either the HSV or HSL color space models... ...when changing brightness/contrasts

[Robert Schleif]

In “The Negative” and “The Print”, Ansel Adams pointed out that the difference in luminosity of some scenes may be as large as 4,000 or more (think HDR), and in other scenes, as small as ten. He also noted that to make a pleasing print, it was necessary in the first case, to compress the important parts of the image into the 50 to 100-fold brightness range that can be reproduced on paper, and in the second case, to appropriately expand the range of image brightness so that in general, a print includes one area of pure black and one area of pure white and all important detail can be discerned. The 256-fold range of intensities that can be represented in 8-bit files closely matches (within a factor of two) what can be represented in differences in reflectivity between white and black areas in a print or what is normally represented on a computer monitor. The 256-fold range is not sufficient however when one is photographing a scene in which the luminosities of important features differ by larger factors. In this case, the broader range of image luminosities must be recorded, and then it must be possible to accurately control any desired compression. This is the issue my initial comments were directed to, not the number of levels of gradation.

HDR methods with multiple images and very substantial compression can handle subjects with wide luminosity differences, and graduated neutral density filters are another. I am suggesting that with the ability of work effectively with images generated by 12 or 14-bit camera sensors, we can do a little HDR with single-shot images.

[den]

It has been my experience that if one wishes to preserve the maximum image data to simulate HDR from a single RAW conversion image using PWP's converter, than one should do only a basic conversion with no edits, sharpening, etc... with 'Medium' contrast expansion and Camera WhiteBalance to a 16-bit tiff [48-bit color] image file... then...

...use the RGB BrightnessCurve with a 'High Histogram Expansion' view to set the black point and white point.

From the resulting RGB BrightnessCurve image, create subsequent images whose brightness/contrast/white balance are optimized for shadows, mid-tone, and highlights. Blend these three or more image versions in StackImages with asymmetrical/symmetrical and 'mask of a mask' Amount masks.

The SI 'Final Shaping Curve' may be sufficient to 'tone-map' the Preview image to a preference but if not... try the 2/3-Zone Adjustment transforms... but I tend to favor using "3-Tone Adjustments/Masks" [ http://www.ncplus.net/~birchbay/3tone/3tone.htm ] and transforms set for the HSL color space model [highlights], the RGB color space model [mid-tones], and the HSV color space model [shadows]... as the SI and the 2/3-Zone transforms only provide access to the HSV-V channel data for tone and HSV-S channel data for color [2/3-Zone Adjustment transforms]...

Sometimes 'local contrast enhancement' and sharpening can provide preference tone-mapping.

Of course this is all done without generating objectionable dark/light halos and is rather manually intensive...

...but 'customized' for the starting image, and most of all, image alignment and 'main subject movement' concerns are non-existent...

[den]

RobertS....

My apologies...

...after a more considered attention to your postings, I now realize what my confusion is/was.

Manipulation of a 16-bit pixel's lower 8-bits of data [shadow - high dynamic range] versus manipulation of a captured scene's 0-255 tone dynamic range, i.e., the manipulation of the upper 8-bits of a 16-bit pixel's data.