How many bits do you need for B&W film scanning

[Adrian Bacon]

I ran across this article that did a bunch of testing to see how many discrete tone steps humans could detect for a given luminance range and thought it would be interesting to post here. It’s in the context of medical imaging display bit depths, however, one could argue that it could apply to how many bits we really need from our scanners when scanning black and white film.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3043920/

If you don’t want to read the whole article, the main takeaway is that ~900 simultaneous discrete luminance tone steps under the most ideal viewing conditions possible is the upper limit of the human visual system, which is well inside of 10 bits.

This actually makes a lot of sense, as the cineon system started out at 10 bits and was 10 bits for the longest time (and still pretty much is) and nobody complained about a single thing in terms tonal resolution or image posterization.

So, this begs the question, is it really necessary to scan bw film at 16 bits? It certainly won’t hurt, however, I suspect that much beyond 10-11 bits is added information that we actually can’t perceive, even on a high bit depth monitor.

I realize most scanners only do 8 bits or 16 bits, so maybe the real question is: after scanning at 16 bits, is it really necessary to store all 16 bits? Less bits would certainly make for a smaller file size.

 

[shutterfinger]

Scanning at 16 bits vs 8 bits is not based on the human visual limit but on how well the electronic medium records the tone and displays it for us to see.

 

[Luckless]

Really depends on what you're doing, and how values eventually get binned together for final output. Given current storage prices I think you would have to have a very extensive collection on the go, or an exceptionally tight budget, before I would be overly worried about file size. A far bigger concern to me would be which format processes faster on my rig and with the software I'm using - Cramming 10-11bit data blocks into 64bit words is not really the most graceful process in all cases, and depending on the coding it may use the same amount of memory anyway, or come with a noticeable performance hit due to the software having to 'dig' the number it is dealing with out of a larger data block that doesn't fall gracefully on the normal boundaries.

8bit scans are very awkward to work with due to just how little overall data is there, and while 16bit is 'over kill' for what a human can actually see, it is however not complete overkill for processing. The extra data points allows more subtle shifting of values, such that the data remains cleaner and with less chance of introducing excessive noise into the final end values.

To simplify the problem, think of having 8 distinct values on your output. If you scan and edit with only those 8 distinct values to work with, then you increase the odds that you might make a change or edit that reduces nearby cells to the same value. If however you work with having sixteen different values that any given cell can be, then the odds of reducing two to being the same are far less during editing. Of course the kind of confusing point of why this matters if you're reducing to 8 values anyway on output comes up, but this is addressed by the 16 editing values allows you to retain the control over how and when a given value gets assigned during final output - If two cells are reduced to 4s during editing, then you are stuck with setting them both as 4s at output. If however you edit such that those cells are 7 and 8, then you retain the choice of whether you bin those values both go to 4, drop one to a 3, or bump one to a 5 - And that is so much easier to do with tweaking adjustment curves on an output stream than it is to go back and try and manually address individual cells that share the same value, as the computer doesn't know the difference between two 4s, but it sure can tell the difference between a 7 and an 8.

 

[Adrian Bacon]

To be clear, I’m not advocating scanning at 8 bits, however, scanning at 16 bits, processing it, then storing the final output at something like 12 bits at a straight gamma 2.2 (for black and white or color) would result in a 25% reduction in file size before compression with a fairly easy processing model to extract back out (2 bw pixels uses 3 bytes, 1 rgb pixel uses 5 bytes), and not really impact perceptual quality. People have a tendency to get caught up in the “more is better” mindset without realizing that for many things, we’ve matched, or even exceeded human perceptual capabilities quite some time ago.

Case in point: I’ve been scanning film with a DSLR that is 14 bits for quite some time now, and quite frankly, cannot tell the difference in terms of tonal rendition between that and a high end 16 bit scan, and this is on a calibrated 10 bit display with a 10 bit display pipeline feeding it. I also have a high end large format printer and cannot tell the difference there either. This is all with a very carefully calibrated end to end fully color managed workflow. I probably wouldn’t be able to the the difference with a 12 bit scan either (assuming I could find something that actually only scanned at 12 bits).

Just food for thought. In practice, it’s just simpler and easier to have a 16 bit workflow from beginning to end because that’s what most systems do, though, it’s helpful to realize that 10-12 bits for 8 bit output is totally fine too.

 

[Ted Baker]

is it really necessary to scan bw film at 16 bits?

Yes, because modern equipment including your DSLR has a linear amplifier before the A/D circuit.

 

[Alan9940]

More data = good! Why not do it? Keeps tonal transitions smoother during editing.

 

[Adrian Bacon]

More data = good! Why not do it? Keeps tonal transitions smoother during editing.

Yes, that’s true, however, once you hit 10-12 bits worth of discrete tonal transitions, you pretty much stop seeing the difference, so using less bits to store the final outcome could result in a pretty good amount of size savings.

Yes, storage is cheap, but only if you’re only using a couple large drives. If you shoot a lot or have a large collection, storage is not so cheap and having something like a 25% savings in file size actually adds up to real dollars.

Case in point: my collection is approaching 10TB. I have 12TB of total storage. If I had a clean way to run through everything in my collection and store it as 12 bits I’d see an instant 2+TB free up, which means I could put off having to upgrade for a little while longer because while storage is cheap, 18-24TB of storage is not so cheap, especially when you factor in backing up that data.

 

[Ces1um]

Totally get where you're coming from. I'm not 100% sure if my scanning software actually offers any increments between 8 bit and 16 bit, so for me I choose 16 bit and leave it at that. I'm lazy so an additional step to downsample my 16 bit file to 12 bit is just more work than I care to do. I think you're absolutely right though, if we can't perceive the difference why bother storing your final file at anything above 10 bit?

 

[Alan9940]

I think you're absolutely right though, if we can't perceive the difference why bother storing your final file at anything above 10 bit?

On the storage side, this may be true. However, for editing purposes (in PS, anyway) 16-bit is preferred depending on extent of editing done. All calculations will be more precise at the higher bit level. For fact, I've read of folks starting to edit in 32-bit floating point, again, for more precision. Beyond editing, I don't think it really matters. I routinely down-sample files for printing to 8-bit because I've tested both 8- and 16-bit printing and, in my normal print sizes, I cannot see any difference.

 

[Bob Carnie]

On the storage side, this may be true. However, for editing purposes (in PS, anyway) 16-bit is preferred depending on extent of editing done. All calculations will be more precise at the higher bit level. For fact, I've read of folks starting to edit in 32-bit floating point, again, for more precision. Beyond editing, I don't think it really matters. I routinely down-sample files for printing to 8-bit because I've tested both 8- and 16-bit printing and, in my normal print sizes, I cannot see any difference.

I agree with Alan 100% ...

 

[faberryman]

Totally get where you're coming from. I'm I think you're absolutely right though, if we can't perceive the difference why bother storing your final file at anything above 10 bit?

On the programs I use, I am only given a choice between 8-bit and 16-bit. Since the science seems to indicate that we can only discern at 10-bit, I choose 16-bit. All the technical arguments kind of fall to the wayside to practicality.

 

[Wallendo]

8 bit and 16 bit images are easily stored as TIFF or PSD documents which are almost completely compatible with serious imaging software. Although there is no reason you couldn't create your own file format that saves native 10 bit files, this would not be compatible with current software. You could "trick" software into saving 12 bit files by first using the levels control to set the white point at 0.0625 before saving the file (and using lossless LZW compression when saving) and then using the levels control again when opening the file to expand it back to 16 bits. Unfortunately, there would be some data loss with each adjustment. Files would be significantly smaller as LZW could easily compress the unused bits. I personally don't think this run-around would be worthwhile. I doubt any major software developers will choose to support 10 or 12 bit native files since microprocessors, as well as most software languages, are designed to work with 8, 16, 32, and/or 64 bit units.

 

[nmp]

If you are going to manipulate the file to any significant way after scanning, better to use 16 bits. Otherwise 8 bit should suffice. I think most printers ultimately output still at 8 bits. And for the ones that boast of 16 bits printing, no one that I have come across has demonstrated that 16 bits was better in any appreciable way. Also, if you going to convert to jpg which is standard for sharing on the web, it is 8 bits by default anyway.

 

[Ted Baker]

Yes, that’s true, however, once you hit 10-12 bits worth of discrete tonal transitions

That is only true if use a non-linear storage, 8 and 10 bit linear scanner is not adequate, you really need at least 12 bits though that is not adequate for film, there is a good reason a DSLR has 14bits and most scanners have that kind of A/D. Some old equipment had non-linear A/D (they have a log amplifier) so they need less bits at scan time.

. I routinely down-sample files for printing to 8-bit because I've tested both 8- and 16-bit printing and, in my normal print sizes, I cannot see any difference.

As Alan points out, 8 bit stored with a gamma of 2.2 is fine, and the image is not further post processed is hard to tell from a 16bit image.

As a further example Kodak reckon 10bit Log used in cineon is almost good enough to store Vision 3 negative stock.

if we can't perceive the difference why bother storing your final file at anything above 10 bit?

If you only interested in the final product which is gamma encoded then your statement is true, if your interested in the intermediate works steps, then it is not true at all, a photographer is often interested in being able control some of the intermediate works steps.

 

[Chan Tran]

If you scan a print and you adjust the scanner just right and use the result as is then 8 bit is good enough. If you scan a negative and then making a lot of adjustment especially brightness and contrast then you do need 16 bit but the final result can be converted to 8 bit.

 

[Ces1um]

That is only true if use a non-linear storage, 8 and 10 bit linear scanner is not adequate, you really need at least 12 bits though that is not adequate for film, there is a good reason a DSLR has 14bits and most scanners have that kind of A/D. Some old equipment had non-linear A/D (they have a log amplifier) so they need less bits at scan time.



As Alan points out, 8 bit stored with a gamma of 2.2 is fine, and the image is not further post processed is hard to tell from a 16bit image.

As a further example Kodak reckon 10bit Log used in cineon is almost good enough to store Vision 3 negative stock.



If you only interested in the final product which is gamma encoded then your statement is true, if your interested in the intermediate works steps, then it is not true at all, a photographer is often interested in being able control some of the intermediate works steps.

Why I underlined "final". Surprised how many people missed that...

 

[Ces1um]

On the programs I use, I am only given a choice between 8-bit and 16-bit. Since the science seems to indicate that we can only discern at 10-bit, I choose 16-bit. All the technical arguments kind of fall to the wayside to practicality.

Same as my software, as noted in my post.

 

[Ces1um]

On the storage side, this may be true. However, for editing purposes (in PS, anyway) 16-bit is preferred depending on extent of editing done. All calculations will be more precise at the higher bit level. For fact, I've read of folks starting to edit in 32-bit floating point, again, for more precision. Beyond editing, I don't think it really matters. I routinely down-sample files for printing to 8-bit because I've tested both 8- and 16-bit printing and, in my normal print sizes, I cannot see any difference.

again, see the underlined word "final".

 

[Ted Baker]

Why I underlined "final". Surprised how many people missed that...

Fair point, and perhaps that's why the possible successor to jpeg, HEIC is 10bit, but remember this along with jpeg and most other formats of that bit depth are gamma encoded.

I think perhaps the reason many people missed your point about "final" is so many assumed you would actually want to keep a file that could be re-purposed. Many don't throw away their film I don't through away a scan I might want to use again.

 

[Luckless]

Given that most of my digital photos live through Lightroom, and that I may change my mind on editing styles in the future, I much prefer to keep the original working scan and delete local copies of the 'final' image.

Plus, I can say that I like the idea of trying to fiddle and adjust file formats between different stages based on whether or not I think I'm done editing. I would much rather stick with one core working standard after I import, and if I'm really tight on data storage then I would rather make better use of my delete key rather than trying to cram more in the barrel.

 

[slackercrurster]

I generally use 8 bits. Am happy with it.

 

[Adrian Bacon]

8 bit and 16 bit images are easily stored as TIFF or PSD documents which are almost completely compatible with serious imaging software. Although there is no reason you couldn't create your own file format that saves native 10 bit files, this would not be compatible with current software. You could "trick" software into saving 12 bit files by first using the levels control to set the white point at 0.0625 before saving the file (and using lossless LZW compression when saving) and then using the levels control again when opening the file to expand it back to 16 bits. Unfortunately, there would be some data loss with each adjustment. Files would be significantly smaller as LZW could easily compress the unused bits. I personally don't think this run-around would be worthwhile. I doubt any major software developers will choose to support 10 or 12 bit native files since microprocessors, as well as most software languages, are designed to work with 8, 16, 32, and/or 64 bit units.

There is no need to come up with a custom or fancy file format. The TIFF format natively supports bit depths other than 8 or 16 bits, it’s just that the vast majority of software out there doesn’t expose writing it. If you really wanted to, you could write a program that sucks in a 16 bit file, scales the samples from 0-65536 to 0.0-1.0 then scales to 0-4096 and writes it out to a tiff file with the sample size set to 12 bits.

 

[alanrockwood]

I started a thread on the same topic in January of 2106. The title of the thread was "Scanner bit depth".

One thing the discussion in the current thread overlooks is the effect of noise in the signal, with grain being one source of noise and electronic noise in the scanner system being another source of noise. I think in most cases grain is going to be the dominant source of noise.

From signal processing theory one can show that if the digital increment is comparable to the noise level there is virtually nothing to be gained by using more bits. Aside from theory, you can arrive at the same conclusion by doing some signal simulations on the computer with judicious use of a random number generator. I show some examples in the thread I referenced.

One thing that is sometimes brought up in these discussions is banding. However, one can show that if you digitize at with a relatively course digitizer (let us say 8 bits) and as long as the noise from grain is comparable to or greater than the ADC step size, you will not get banding when you do image manipulation, even with extreme manipulations. However, for this to hold true you need to convert to a higher bit depth before doing the image manipulations. This is very different from doing the same thing with a noiseless/grainless image. When I say "noiseless image" I mean that the only noise present in the signal is the round-off error that comes from the analog to digital conversion.

Some scanners can only scan 8 bits. For example, the Leafscan scanner is limited to 8 bits under certain conditions. However, that is not a problem, provided that the film is sufficiently grainy, which is usually going to be the case. However, as mentioned above, if you want to do any extensive image manipulation it is important to convert to higher bit depth (e.g. 16 bits) first. Also, you should scan at the highest resolution setting of your scanner for reasons I won't go into right here.

I realize that I am going to get some push-back from some people on this. All I can say is to either delve deeply into the image processing theory or do some simulations on the computer, or better yet, scan some black and white film with an image of an almost featureless blue sky (i.e. with only smooth gradients in the original object). Alternatively take a photo of some ordinary scene with smooth gradients generated by extreme defocusing of the lens. Scan the same slide or negative twice, once with 8 bits and once with 16 bits. Then convert the 8 bit image to 16 bits, and finally do some extreme image manipulation on the two images. Be sure to do exactly the same manipulation on both images. I submit that you will not be able to tell the difference, including the banding issue.

Now do the same thing with a grainless/noiseless image, e.g. one produced by some kind of drawing program. In that case you will see banding if the image processing is extreme enough. Alternatively, take the file of the real photo discussed above, do some rather extreme smoothing of the image to eliminate the grain/noise in the smooth gradients, convert to 8 bits and then do the extreme image manipulation. You will have the possibility of banding in this case. You may also see banding of you convert the smoothed image to 8 bits and then back to 16 bits before you do the image manipulation.

So the bottom line is that if your scanned image is noisy enough (with grain being one component of noise) it is sufficient to scan with 8 bits, but convert to 16 bits before you do extreme image manipulation.

 

[Ted Baker]

So the bottom line is that if your scanned image is noisy enough (with grain being one component of noise) it is sufficient to scan with 8 bits, but convert to 16 bits before you do extreme image manipulation.

IMHO, part of the confusion is that when someone states they are scanning with 8bits, is that they are in fact actually not scanning with 8bits at all. For example if you choose 8bits on an Epson flat bed you are still scanning at either 16bit or possibly 14bit, because that is how the hardware works.

If you use a Nikon DSLR you will always be using a 14bit A/D, even if just save it as JPEG. 8Bit is enough in most cases AFTER you have gamma encoded the data. 10bits gamma encoded may eventually become the standard which replaces jpeg, and similar for cinema, home theatre etc.

You can simulate the effects of actually scanning at 8bits easy enough. and see the difference.