Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 




      :: Filmscanners
Filmscanners mailing list archive (filmscanners@halftone.co.uk)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[filmscanners] RE: 8 bit versus 16

> From: Preston Earle
> I've been thinking more about this 8-bit vs. 16-bit question, and one
> thing puzzles me and has generally been ignored in this discussion.
> Someone (Arthur, Austin, Laurie, ????) brought up the question of
> "noise" in image data, but that issue has been bypassed in these
> discussions in favor of other comments. Yet it seems noise is the reason
> high-bit data is superfluous. What I'm thinking:
> 1. High-bit data is very small compared to low bit data. The ninth-bit
> is only 0.25% of the value of the full tonal range of 0-100%.
> 2. All visible files are the product of a final resize/pixel-combination
> of some sort, at least until we get 2800x4200 or larger video screens.
> 3. When scanners measure and assign digital values to image elements,
> adjacent pixels are given discrete values that are generally different
> by more than 0.25%, that is, the precision of the measurement is less
> than 8-bits for adjacent pixels.
> 4. Image editing steps which spread existing pixel ranges over larger
> ranges do not create more precise intermediate values than the starting
> value's precision. If an intermediate pixel value must be created
> between two pixels whose values are 128 and 130 (8-bit), the value won't
> be more precise if the original values are 127.504 and 129.504 (16-bit).
> I don't know how typical CCD scanners scan at lower resolutions than
> their maximum. Whether by averaging pixel values along the CCD array and
> making larger steps along the film movement, or by some other way, they
> still end up with adjacent pixel values that differ by more than 1 unit.
> Knowing these values to .5-unit precision doesn't change the average
> values reported.
> For 16-bit processes to be relevant, wouldn't adjacent pixels have to be
> identical to more than 8-bit precision?

I was the one who brought it up. A couple of points:

1) When you reduce an image by averaging the pixels, you reduce the noise.
Cutting the linear resolution in half, for instance, effectively averages a
square of four pixels together, which reduces the noise by a factor of the
square root of four, which is two, or 6db, so effectively allows for one
more bit of useful resolution.

2) To avoid all banding in 8-bit data, the signal-to-noise ratio must be
poorer than you might think. I've found from experimentation that you need
five or six lsbs of noise, peak-to-peak, to break up the banding. With only
two or three lsbs, you won't see outright posterization, but you'll see
bands of more noise alternating with bands of less noise. (This is only if
you apply a really drastic curve.)

I suspect, though, that most good film scanners have plenty of S/N, to where
more than eight bits really could be useful, if the film had a quiet enough
image. The question, then, is whether film grain itself supplies enough
noise to make the extra bits useless. In my experience, scanning Kodachrome
25 and E6 100, I've always seen plenty of film grain noise to render the
extra data useless, even for B&W. If I take a clear blue sky, which is about
as noiseless an image source as you can find, convert to 8-bit B&W, and then
apply a drastic curve to stretch the gradient out to the full black-to-white
range, I see no banding at all, just lots of noise. I've not done much
negative scanning--it may have less noise.

I've also done some pretty rigorous tests on my two digicams, the Minolta
DiMage 7 and the Canon 10D. In raw mode, the DiMage 7 has absolutely no
useful information in the extra four bits, under even the best
circumstances, but the 10D does.


Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

Unsubscribe by mail to listserver@halftone.co.uk, with 'unsubscribe 
or 'unsubscribe filmscanners_digest' (as appropriate) in the message title or 


Copyright © Lexa Software, 1996-2009.