moondigger
Offline
• • • • •
Upload & Sell: Off
|
InnomnateViem -- The following explanation is an oversimplification, but maybe it will help.
The brightness range is the same no matter how many bits are being used to capture the data. If you used (for example) 4 bits per channel, you would only be able to encode 16 levels of brightness, from completely dark to fully bright. Going to 5 bits per channel would allow you to encode 32 levels of brightness, covering the same range but with smaller increments. 6 bits gives 64 brightness levels, 7 gives 128 brightness levels, and 8 bits per channel gives 256 brightness levels for each channel.
Note too how binary values are actually recorded in this example using 8-bit values:
11111111
From LEFT to RIGHT, the place values are 2^7 (128), 2^6 (64), 2^5 (32), 2^4 (16), 2^3 (8), 2^2 (4), 2^1 (2), and 2^0 (1). So 11111111 would be 128+62+32+16+8+4+2+1, or 255 (fully bright). 00000000 would be 0+0+0+0+0+0+0+0, or 0 (fully dark). 00101101 would be 0+0+32+0+8+4+0+1, which equals 45. Here's a table showing a few more:
00010100 (20)
01000000 (64)
10000000 (128)
10010110 (150)
11000111 (199)
11100001 (225)
Alright, so it should be evident that the first bit on the left is the MOST significant, because it represents a value of 2^7, which is equal to 128. Therefore this bit encodes half of the entire range of brightness, and is equal in value to all of the remaining bits combined. The second bit is the second most significant, since it encodes 2^6, or 64. Following this all the way through, we see that the last bit encodes 2^0, which is 1 -- which in this 8-bit encoding scheme, records only 1/256th of the brightness range. It is the LEAST significant bit, because its value affects the total value by an almost imperceptible amount.
Now consider what happens if we use a 10-bit encoding scheme instead:
1001011100
(=604)
Instead of that first digit on the left being worth 2^7, as in the 8-bit example, it's worth 2^9 (512) in this example. But what happens to the bit all the way on the right end? Instead of the last bit recording 1/256 of the total brightness level, it encodes only 1/1024th of the total brightness level. It's not just the least significant bit -- it's 4X less significant than the last bit in the 8-bit example.
The same thing happens when you go to a 12 bit scheme. Instead of the last digit being worth 1/256 or 1/1024 of the brightness range, it's only worth 1/4096. The least significant bits are getting less and less significant as we go.
Now consider a 14 bit encoding scheme. That last bit on the right is being used (or attempting to be used) to encode a brightness level that is only 1/16,384 of the full brightness range. We're probably running into limitations in the granularity that the sensor can record due to electromagnetic interference, heat, etc.
At some point along the way, the differences in brightness being encoded are so small that other effects can interfere with a true reading. When alundeb says going from 14 bits to 16 bits is pointless because the last two bits would just be filled with noise, it means that the increments of brightness being encoded by the 14th bit is already so tiny that smaller divisions are more likely to encode variations due to noise than real differences in brightness.
For what it's worth, it has been repeatedly demonstrated that human beings cannot distinguish colors that differ by only one bit in a 24 bit image (3 channels x 8 bits). So for example, the RGB color 184,102,27 is indistinguishable from 184,102,28. That's part of the reason why some printers don't accept 16 bit data, and even if they do, many of them simply truncate to 8 bits/channel anyway. If you have a printer that shows differences in output depending on whether you feed it 8 bit or 16 bit data, then something weird is going on there, or the algorithm being used is interpreting or manipulating the data in some strange way that makes the images visibly different. They shouldn't be visibly different.
|
Happy you enjoyed Sonoma county.