8-bit to 16-bit in PS

[gkroeger]

OK, I have drum scanned files in 8-bit, but plan to do a lot of masking, levels and curves work, so I assume that I can avoid rounding issues (banding etc) by doing all of this in 16-bit math.

If I simply change the image mode from 8-bit to 16-bit, it doesn't change the pixel values. So the pixels still range from 0-255 in each channel. That won't fix rounding issues.  So I assume I want to do some sort of linear expansion so that the pixel values span a wider range, perhaps 0-64K? If so, how do I do that? And do I need to do it to each adjustment layer, or just once to the entire image?

Glenn

[John Sheehy]

OK, I have drum scanned files in 8-bit, but plan to do a lot of masking, levels and curves work, so I assume that I can avoid rounding issues (banding etc) by doing all of this in 16-bit math.

If I simply change the image mode from 8-bit to 16-bit, it doesn't change the pixel values. So the pixels still range from 0-255 in each channel. That won't fix rounding issues.  So I assume I want to do some sort of linear expansion so that the pixel values span a wider range, perhaps 0-64K? If so, how do I do that? And do I need to do it to each adjustment layer, or just once to the entire image?
[a href=\"index.php?act=findpost&pid=164904\"][{POST_SNAPBACK}][/a]

PS is converting the 16-bit values to 8-bit for the Levels tool, histogram, etc, but not in the actual image data.  The info tool can work in 16-bit mode if you look into its menu.

PS' 16-bit mode isn't really 16-bit, BTW.  It's 15-bit plus one extra value, so it has 0 to 32768, or 32769 possible values (16-bit would be 0 to 65535 or 65536 values).  True 16-bit images get a little bit quantized upon loading (but you will not likely see any visual detriment to the image).

[Panopeeper]

If I simply change the image mode from 8-bit to 16-bit, it doesn't change the pixel values. So the pixels still range from 0-255 in each channel. That won't fix rounding issues.  So I assume I want to do some sort of linear expansion so that the pixel values span a wider range, perhaps 0-64K? If so, how do I do that?

When you change the b ot depth, the existing data will be "spread" (projected over the larger space). You don't need to do anything extra. Were not it this way, you would see a black image after conversion.

However, do not expect to see these values. You still see the displayed RGB, which is 8-bit (your monitor control card could not do anything with more than 8 bits per channel).

[gkroeger]

When you change the b ot depth, the existing data will be "spread" (projected over the larger space). You don't need to do anything extra. Were not it this way, you would see a black image after conversion.

However, do not expect to see these values. You still see the displayed RGB, which is 8-bit (your monitor control card could not do anything with more than 8 bits per channel).
[a href=\"index.php?act=findpost&pid=164912\"][{POST_SNAPBACK}][/a]

Thanks.  I thought about the black image issue, but the histogram indicated that 0-255 was still the spread from Black to White... so if I understand you, that will always be the way that pixels are shown, even though internally, they will span the 0-32K range?

Glenn

[Panopeeper]

if I understand you, that will always be the way that pixels are shown, even though internally, they will span the 0-32K range?

What else should be shown? I don't think the majority of users would be happy to see large numbers of a linear scale - most of them would not understand it. (Though if it were optional...)

This will become a hot issue, when 10-bit monitors become commercially available.

[Schewe]

If I simply change the image mode from 8-bit to 16-bit, it doesn't change the pixel values. So the pixels still range from 0-255 in each channel.
[a href=\"index.php?act=findpost&pid=164904\"][{POST_SNAPBACK}][/a]

Have you set the Info display to show 16 bit numbers? If you do you will be able to see intermediate numbers when you start processing...but...(there's always a "but"), changing an 8 bit file to 16 bits ain't gonna buy you much if anything. You don't and won't have "real" high bit depth, you lost that when you got an 8 bit scan. If you are doing multiple and radical tone/color corrections, you "might" see some "mild" benefits to converting to 16 bit. But the odds are, you may as well just stay with processing in 8 bit because while you don't have real 16 bit data, you're gonna be carrying 16 bits worth of files size anyway.

Why would you have gotten an 8 bit scan if you really wanted 16 bit data?

[gkroeger]

Have you set the Info display to show 16 bit numbers? If you do you will be able to see intermediate numbers when you start processing...but...(there's always a "but"), changing an 8 bit file to 16 bits ain't gonna buy you much if anything. You don't and won't have "real" high bit depth, you lost that when you got an 8 bit scan. If you are doing multiple and radical tone/color corrections, you "might" see some "mild" benefits to converting to 16 bit. But the odds are, you may as well just stay with processing in 8 bit because while you don't have real 16 bit data, you're gonna be carrying 16 bits worth of files size anyway.

Why would you have gotten an 8 bit scan if you really wanted 16 bit data?
[a href=\"index.php?act=findpost&pid=164935\"][{POST_SNAPBACK}][/a]

These scans are ~5 years old... 16 bit was beyond my processing power, disk space, pocketbook, and practicability when done.  They look fine in 8 bit, but since I now have the disk space and processing power, I thought I would just avoid any possible banding or rounding issues.  I am doing multiple masked correction layers fixing some shadow and highlight compression issues. My latest scans are 16 bit to begin with.

Glenn

[Panopeeper]

Preservation of originally existing (real) data is not the only, not even the primary goal of working in 16bit mode. Many functions in image editing involve interpolations, which, when aggregated, lead to loss of data. This loss is less in 16bit mode.

On the other hand, the advantage of 16bit is often overstated. In response to such a discussion on another forum I made a demonstration with an image converted from raw with ACR, once in 8bit and once 16bit.

I carried out following adjustments identically on both images, always saving and reopening them between the steps (I think this is a far exaggeration for the sake of increased effect):

1. increasing contrast
2. increasing brightness
3. selective color adjustments
4. some curve applied
5. downsized to 16.66%
6. sharpened (somewhat oversharpened)

Here is the result, only in order to make the difference image understandable:

Resulting image

The above is actually from the 8-bit version. I can't discern any difference between the two versions, viewed even at 400%. The difference layer shows, that there are differences of 1 or 2 RGB value virtually overall; here is the difference layer, with levels amplified:

Difference layer

I made some tests with rotating the images, reversing the rotation and downsizing to a given pixel number; only three steps caused one RGB value differences, but again, not discernable for me.

I use 16bit TIFFs in panorama creation, which consists of at least five separate program steps: 1. raw conversion, 2. warping, 3. blending, 4. post-processing, 5. sharpening for presentation. Particularly the warping includes heavy interpolations and the post-processing often stretches over several sessions.

[John Sheehy]

What else should be shown? I don't think the majority of users would be happy to see large numbers of a linear scale - most of them would not understand it. (Though if it were optional...)[a href=\"index.php?act=findpost&pid=164922\"][{POST_SNAPBACK}][/a]

"16-bit" mode is no more linear than 8-bit mode.

They could use decimals, as another option, which shows differences beyond 8-bit, but are totally intuitive to someone used to 8-bit numbers.  Either base 10, or just the "remainder" after the decimal.

[Panopeeper]

"16-bit" mode is no more linear than 8-bit mode.

16bit is certainly "more linear" than 8bit, because 8bit can be shown linear or mapped, while 16bit can be shown only linear.

[JeffKohn]

16bit is certainly "more linear" than 8bit, because 8bit can be shown linear or mapped, while 16bit can be shown only linear.
[a href=\"index.php?act=findpost&pid=165048\"][{POST_SNAPBACK}][/a]

what are you talking about? 8-bit versus 16-bit has absolutely nothing to do with whether an image is linear- or gamma-encoded.

[Panopeeper]

what are you talking about? 8-bit versus 16-bit has absolutely nothing to do with whether an image is linear- or gamma-encoded.

Correct; however, do you mind posting a 16-bit JPEG file? And, if we are at it, which printer are you using with 16-bit TIFF?

[Kirk Gittings]

Have you set the Info display to show 16 bit numbers? If you do you will be able to see intermediate numbers when you start processing...but...(there's always a "but"), changing an 8 bit file to 16 bits ain't gonna buy you much if anything. You don't and won't have "real" high bit depth, you lost that when you got an 8 bit scan. If you are doing multiple and radical tone/color corrections, you "might" see some "mild" benefits to converting to 16 bit. But the odds are, you may as well just stay with processing in 8 bit because while you don't have real 16 bit data, you're gonna be carrying 16 bits worth of files size anyway.

Why would you have gotten an 8 bit scan if you really wanted 16 bit data?
[a href=\"index.php?act=findpost&pid=164935\"][{POST_SNAPBACK}][/a]

Many older drum and professional flatbed scanners only write to 8 bit files and there are still a ton of them in service. My Scitex Eversmart for example. They are still very servicable.

Of course 16 bit is better, but....there are still large benefits to converting 8 bit to 16 bit for PS work and this is easily demonstrated with the histogram. Apply steep curves to an 8 bit drum scan file till the histogram just breaks up. Do the same to a 16 bit converted file and convert it back to 8 bit and check the histogram. It will be significantly better.

[gkroeger]

Many older drum and professional flatbed scanners only write to 8 bit files and there are still a ton of them in service. My Scitex Eversmart for example. They are still very servicable.

Of course 16 bit is better, but....there are still large benefits to converting 8 bit to 16 bit for PS work and this is easily demonstrated with the histogram. Apply steep curves to an 8 bit drum scan file till the histogram just breaks up. Do the same to a 16 bit converted file and convert it back to 8 bit and check the histogram. It will be significantly better.
[a href=\"index.php?act=findpost&pid=165258\"][{POST_SNAPBACK}][/a]

So if I have an 8-bit scan that I have already added adjustment layers to, and I do a mode change to 16-bit, will all of the adjustment calculations automatically change to 16-bit... i.e. are the adjustment layer calculations done on-the-fly whenever the file is displayed or printed? Or, do I need to go back and convert the scan and then redo the adjustment layers? (seems unnecessary)

[Kirk Gittings]

So if I have an 8-bit scan that I have already added adjustment layers to, and I do a mode change to 16-bit, will all of the adjustment calculations automatically change to 16-bit... i.e. are the adjustment layer calculations done on-the-fly whenever the file is displayed or printed? Or, do I need to go back and convert the scan and then redo the adjustment layers? (seems unnecessary)
[a href=\"index.php?act=findpost&pid=165815\"][{POST_SNAPBACK}][/a]

I have not tested a conversion in the middle of a workflow, but I believe it is better to do it as the very first thing afterthe scan. I know a number of professional scanners with the older 8 bit machines. Our consensus is to change it to 16 bit at the very beginning. After discovering this I went back and redid many of my own files.

[TylerB]

the adjustment layers exist in no particular space, the background layer has not been altered at all yet. Flattening applies the adjustments.
So, you could mode change to hi bit, and then flatten, and get the same benefits.
Tyler

[Brian Gilkes]

the adjustment layers exist in no particular space, the background layer has not been altered at all yet. Flattening applies the adjustments.
So, you could mode change to hi bit, and then flatten, and get the same benefits.
Tyler
[a href=\"index.php?act=findpost&pid=165825\"][{POST_SNAPBACK}][/a]

Absolutely true.The problems with 8 bit are ,as Panopeeper demonstrated , a lot less than often claimed. In practice 8 bit works fine for most adjustment layers, especially if original RAW files have been matadata processed first. Even with JPEG vs 16 bit tiff, there is only very occasional discontinuities observable when cranking deep shadows in curves, and in very subtly graded areas like skies.
The problems emerge at odd times, say when blending masks or applying high radius filters.
If you only have an 8 file to start with, and it requires severe editing, a conversion to 16 bit does help a bit. A better approach may be to conduct luminosity edits with duplicated layers that are blended and masked. That way there is minimal pixel damage. Painting in softlight avoids the problems with burn and dodge tools.
In a few years, camera to print workflow will be 16 bit, with monitor gamuts exceeding that of printers, 16 bit histograms, rapid rendering and spooling etc etc. Then the virtues of 32 bit will be argued.
Cheers
Brian

[Kirk Gittings]

Absolutely right. With my work and many peoples work though, we are doing much more than adjustment layers and it is convenient to just do the conversion at the beginning perhaps unless the file size is a problem for someone.