mjm6 Offline Upload & Sell: On
|
AmbientMike wrote:
14 bit RAW beats 12 bit RAW. Both are compressed. 16 bit tiff has more bits and is uncompressed.
{{{sorry, this got to be "Dan Long" but I think it is worth going through bit depth in detail}}}
the 50S2 doesn't have 16-bit A2D converters as I understand it, so the absolute best bit depth you will get from the camera is 14 bits of color depth. This means that the camera, when it takes the light from the CMOS and converts it into a digital signal is only capable of differentiating the values into 14-bits of color depth.
If you then convert it to a 16-bit TIFF (which could be done in LR or in the camera), you "pad" the file with null data (most people say that it is "zeroes"). However, the original conversion to digital is the limiting factor and that remains locked at 14-bits, so you don't actually gain anything by padding the file to 16-bit, other than increasing the file size.
Here's an example of how this works, but vastly simplified:
Color bit depth of 2 bits; here's a data point for a single piece of RAW data for a single photosite:
01 Dark grey
It only has one value, because remember, each photosite in a Bayer CMOS array only records a single color because of the Bayer filter and when the RAW conversion is done, the other two channels are interpolated from adjacent photosites. Which color is immaterial to this discussion
2-bit color depth has 4 levels of delination; you can only effectively differentiate 4 (2^2 = 4) different levels of value (and that is normally assigned to full-black on one end and full white on the other). I'm going to make assignments in this imaginary color space that we''ll use.
11 Full white
10 Light grey
01 Dark grey
00 Full black
OK, so let's take this from 2-bit up to 4-bit. We now can get 16(!) levels of color information! (2^4 = 16) But, the file we started with is really only a 2-bit file. so this is what it looks like:
1111 Full white
1110 a little less white
1101 Just a little less white than above
1100 THIS IS THE PADDED DATA VALUE IN THE 4-BIT FILE FOR ALL OF THE 2-BIT INFORMATION FOR A WHITE PIXEL
1011 Shade of gray (light)
1010 Shade of gray (light)
1001 Shade of gray (light)
1000 THIS IS THE PADDED DATA VALUE IN THE 4-BIT FILE FOR ALL OF THE 2-BIT INFORMATION FOR A LIGHT GREY PIXEL
0111 Shade of gray (dark)
0110 Shade of gray (dark)
0101 Shade of gray (dark)
0100 THIS IS THE PADDED DATA VALUE IN THE 4-BIT FILE FOR ALL OF THE 2-BIT INFORMATION FOR A DARK GREY PIXEL
0011 Close to black
0010 A little closer to black
0001 Just a little bit closer to black than above
0000 Full Black THIS IS THE PADDED VALUE IN THE 4-BIT FILE FOR ALL THE 2-BIT INFORMATION FOR A BLACK PIXEL
Note that the reason people call the file "PADDED" is because if you take the two zeroes off the right of the 4-bit values, you get the exactly same value as the 2-bit file. Also, if you look, if you take the two right zero/one values off, you will see that all the rest of the four locations in the "White" or "Black" zones (and all the rest, by group) are identical , so if you were to convert a 4-bit file to 2-bits, the four values would all be grouped together into that single value, 1111, 1110, 1101, and 1100 would all go to 11, for example.
If the camera has the ability to generate (in the analogue to digital processing of the light (electrical signals) into the file data) the source light into a higher bit depth (4-bits in the example above), you would have the potential to use ALL of the values shown, from the 0000 value at the bottom to the 1111 value at the top. However, if the camera is limited in its' A2D conversion to only 2-bits, the best you can get is the four values I highlight above and the rest, while potentially possible in the file, won't actually exist in the file. What you have is a 2-bit file "padded" into a 4-bit structure.
So, converting to 16-bit in-camera is not going to give you a better file to work with (that you couldn't have gotten by converting to 16-bit in a RAW converter anyway).
It is true that when you get to making adjustments, having higher bitdepth will help avoid banding and other artifacts, but you have to be a bit careful about thinking that this solves all problems because unless you perform some form of data dithering on the original data as it comes out of the D2A conversion process, you don't really have data that occupies a full 16 bits worth of depth. It will look like what I have shown above (with all the data occupying only some of the possible levels in the file), only with a lot more bits.
|