Bit-Depth understanding required

[brucepercy1]

Hello All,

For many years, I've been happily using a Mamiya 7 and Coolscan scanner. I always now scan at 14-bits (the max my scanner can capture) when editing in Photoshop.

I've just been experimenting with a Canon 5D and I've seen what appears to me to be a lot more evidence of banding, in particular, in clear areas of sky where there is a very gradual tonal change. The images have been shot in RAW

So I'd like to ask a question regarding bit-depth. My understanding is that most DSLR's are 12-bit, including the 5D. This means that each channel should have 4095 discreet values possible.

My scanner samples at 14-bit, which produces scans where each channel should have 16384 discreen values possible.

What I would like to know is - have I got this right? Am I missing something here?

The difference between 12 bit and 14 bit is quite large, and I think this is why I am seeing such a difference - or evidence of banding when doing some serious adjustments in photoshop.

Also, I've been wondering for a while why most DSLR's at the moment are 12 bit.

Any info etc, would be greatly appreciated.

Lastly, my initial impressions of the 5D, when it's tripod mounted, is that the image quality is superb. I'm using primes and the cheap 24 F2.8 lens shows little softness at the edges. I've also noticed that opening the RAW files in Canon's DPP provides more neutral tones, but DPP has terrible sharpening, so I transfer to Photoshop and do an initial sharpen, whilst retaining the netural tones. ACR (which admittedly is not listed as supporting the 5D) does not produce the same neutral tones IMHO.

I feel I still have a long way to go, before I even consider selling up the Mamiya and Coolscan. I do love film, like the grain, like the response curves I get from films like Portra for people shots etc. It's an interesting time.

Any thoughts on the Bit-Depth understanding would be greatly appreciated.

Best Wishes,
Bruce Percy
The Light & the Land Photography
http://www.thelightandtheland.com

[bjanes]

Hello All,

For many years, I've been happily using a Mamiya 7 and Coolscan scanner. I always now scan at 14-bits (the max my scanner can capture) when editing in Photoshop.

I've just been experimenting with a Canon 5D and I've seen what appears to me to be a lot more evidence of banding, in particular, in clear areas of sky where there is a very gradual tonal change. The images have been shot in RAW

So I'd like to ask a question regarding bit-depth. My understanding is that most DSLR's are 12-bit, including the 5D. This means that each channel should have 4095 discreet values possible.

My scanner samples at 14-bit, which produces scans where each channel should have 16384 discreen values possible.

What I would like to know is - have I got this right? Am I missing something here?

The difference between 12 bit and 14 bit is quite large, and I think this is why I am seeing such a difference - or evidence of banding when doing some serious adjustments in photoshop.

Also, I've been wondering for a while why most DSLR's at the moment are 12 bit.

Any info etc, would be greatly appreciated.

Lastly, my initial impressions of the 5D, when it's tripod mounted, is that the image quality is superb. I'm using primes and the cheap 24 F2.8 lens shows little softness at the edges. I've also noticed that opening the RAW files in Canon's DPP provides more neutral tones, but DPP has terrible sharpening, so I transfer to Photoshop and do an initial sharpen, whilst retaining the netural tones. ACR (which admittedly is not listed as supporting the 5D) does not produce the same neutral tones IMHO.

I feel I still have a long way to go, before I even consider selling up the Mamiya and Coolscan. I do love film, like the grain, like the response curves I get from films like Portra for people shots etc. It's an interesting time.

Any thoughts on the Bit-Depth understanding would be greatly appreciated.

Best Wishes,
Bruce Percy
The Light & the Land Photography
http://www.thelightandtheland.com
[{POST_SNAPBACK}][/a]

Bruce,

This thread on DPReview should give you some insight into these matters, although this thread is more concerned with dynamic range than the number of levels. Just because your scanner has a 14 bit analog to digital converter does not mean that the sensors are capable the implied level of performance.

[a href=\"http://forums.dpreview.com/forums/read.asp?forum=1021&message=18931888]http://forums.dpreview.com/forums/read.asp...essage=18931888[/url]

Norman Koren's website has some good information on tonality and the number of levels in the various zones. Blue sky is about Zone V and a 12 bit capture should have 128 levels in that zone, more than the eye can distinguish. If you are converting your raw images at a bit depth of 16 and are seeing banding in the sky, something is wrong with your workflow. Banding is most likely to show up in the shadows, where there are fewer levels.

http://www.normankoren.com/digital_tonality.html#measure

BTW, the latest version of ACR does support the 5D. You can download it from the Adobe web site. It does require Photoshop CS2.

Bill

[John Sheehy]

I've just been experimenting with a Canon 5D and I've seen what appears to me to be a lot more evidence of banding, in particular, in clear areas of sky where there is a very gradual tonal change. The images have been shot in RAW
http://www.thelightandtheland.com
[a href=\"index.php?act=findpost&pid=71254\"][{POST_SNAPBACK}][/a]

I assume you're talking about contour banding in the gradients (as opposed to vertical and horizontal lines super-imposed on the shadows, which is also referred to as "banding").

Contour banding occurs when noise is low and quantization is coarse.  Blue sky has a very weak red component, because digital cameras are very insensitive to red, and there isn't much red in deep blue sky to begin with.  You really need to expose as high as you can without clipping highlights, and this can't be done properly at ISO 50, so don't use that.  Also, don't make dark conversions to brighten in post-processing, get the levels high in the conversion and do only darkening in PP.  Convert to 16 bits if you're going to do any editing of levels or saturation.

[bjanes]

I assume you're talking about contour banding in the gradients (as opposed to vertical and horizontal lines super-imposed on the shadows, which is also referred to as "banding").

Contour banding occurs when noise is low and quantization is coarse.  Blue sky has a very weak red component, because digital cameras are very insensitive to red, and there isn't much red in deep blue sky to begin with.  You really need to expose as high as you can without clipping highlights, and this can't be done properly at ISO 50, so don't use that.  Also, don't make dark conversions to brighten in post-processing, get the levels high in the conversion and do only darkening in PP.  Convert to 16 bits if you're going to do any editing of levels or saturation.
[{POST_SNAPBACK}][/a]

While I agree with exposing to the right, a blue sky has more red than you might think, since it is not that saturated. For example, Bruce Lindbloom gives a value for the blue sky patch of a ColorChecker in ProPhotoRGB as 95, 102, 134. In one of my photos I measured a clear north blue sky at 104, 119, 184 in ProPhotoRGB. I have Canon 1D Mark II image of a ColorChecker where the sky patch reads 122, 128, 162 and the white patch reads 253, 252, 248 when converted into ProPhotoRGB with DCRaw. The values of the sky patch in raw are 1365, 2264, and 1365. The normalized pixel value for the red is 1365/4095 or 0.33. With the 12 bit raw, that should give over 512 levels for that zone, plenty to avoid posterization.

[a href=\"http://www.normankoren.com/digital_tonality.html]http://www.normankoren.com/digital_tonality.html[/url]

[jani]

While I agree with exposing to the right, a blue sky has more red than you might think, since it is not that saturated. For example, Bruce Lindbloom gives a value for the blue sky patch of a ColorChecker in ProPhotoRGB as 95, 102, 134. In one of my photos I measured a clear north blue sky at 104, 119, 184 in ProPhotoRGB. I have Canon 1D Mark II image of a ColorChecker where the sky patch reads 122, 128, 162 and the white patch reads 253, 252, 248 when converted into ProPhotoRGB with DCRaw. The values of the sky patch in raw are 1365, 2264, and 1365. The normalized pixel value for the red is 1365/4095 or 0.33. With the 12 bit raw, that should give over 512 levels for that zone, plenty to avoid posterization.

Uhm, I think you misunderstand how RGB works.

For instance, 128,128,255 is a medium blue. There is absolutely no red in it whatsoever.

64,128,255 would be a blue with a green tint.

[dlashier]

For instance, 128,128,255 is a medium blue. There is absolutely no red in it whatsoever.

[a href=\"index.php?act=findpost&pid=71306\"][{POST_SNAPBACK}][/a]

Huh? r=128 is not no red. Just because it happens to be balanced by green doesn't mean there's no red.

- DL

[bjanes]

Uhm, I think you misunderstand how RGB works.

For instance, 128,128,255 is a medium blue. There is absolutely no red in it whatsoever.

64,128,255 would be a blue with a green tint.
[a href=\"index.php?act=findpost&pid=71306\"][{POST_SNAPBACK}][/a]

 

[sgwrx]

what's interesting is one of my photos with a circular polarizer, shows about 6 distinct bands in the "gradient" of the darkest blue to lightest blue when i see it in any of my color managed photo editors. when i soft proof it with a generic silver rag profile, it has really bad banding but about 10 distinct bands.  when i printed it on the SR, 6x9, i can't seem to see those banded areas.  this told me that perhaps it's a monitor limitation? but maybe it's just not big enough?

[John Sheehy]

The values of the sky patch in raw are 1365, 2264, and 1365. The normalized pixel value for the red is 1365/4095 or 0.33.
[a href=\"index.php?act=findpost&pid=71293\"][{POST_SNAPBACK}][/a]

That's quite impossible.  How could the red be equal to the blue when red is less sensitive in the camera?  That would mean the sky-blue square actually had more red than blue.

You didn't shoot this with a warm light, did you?

[John Sheehy]

The values of the sky patch in raw are 1365, 2264, and 1365. The normalized pixel value for the red is 1365/4095 or 0.33. With the 12 bit raw, that should give over 512 levels for that zone, plenty to avoid posterization.
[a href=\"index.php?act=findpost&pid=71293\"][{POST_SNAPBACK}][/a]

I am looking at the RAW values from a patch of NYC blue sky (which isn't really very blue in the summer, with the humidity), and the RAW values for the sky are 85:255:244.  That's without a polarizer.  A polarizer in the desert would be much more extreme.  In another one, where the sky isn't quite as blue, and exposure is such that white clouds are just about reaching with the maximum RAW value, the values of the bluer corner of sky are about 350:870:740.

[jani]

Huh? r=128 is not no red. Just because it happens to be balanced by green doesn't mean there's no red.

Yes, that's exactly what it means.

When green and red are balanced, all you're dealing with is various brightnesses of blue.

If it wasn't, it would be impossible to create brighter blues than 0,0,255, and RGB would be completely useless for imagery.

Edit:

Maybe you're confused by the RGBG pattern of colour filters across the sensor. If you were to access the raw format and find that there is indeed red light, then that's another matter.

[jani]

what's interesting is one of my photos with a circular polarizer, shows about 6 distinct bands in the "gradient" of the darkest blue to lightest blue when i see it in any of my color managed photo editors. when i soft proof it with a generic silver rag profile, it has really bad banding but about 10 distinct bands.  when i printed it on the SR, 6x9, i can't seem to see those banded areas.  this told me that perhaps it's a monitor limitation? but maybe it's just not big enough?

Assuming that the rest of your colour managed workflow is allright:

It does resemble a calibration problem, for instance that LUT adjustments have provided you with significantly less than the full 24-bit spectrum. But it could also be that your monitor isn't able to represent all the gradients.

[dlashier]

Yes, that's exactly what it means.

When green and red are balanced, all you're dealing with is various brightnesses of blue.
[a href=\"index.php?act=findpost&pid=71354\"][{POST_SNAPBACK}][/a]

No, what your dealing with is various saturation levels of blue. Brightness level of blue is determined by the "b" value.

Maybe you're confused ...
[a href=\"index.php?act=findpost&pid=71354\"][{POST_SNAPBACK}][/a]

I'm not the one who is confused  . No red in a color would be only when r = 0. For a color be be a red, r would need to be the highest value, for a color to be reddish or have a red cast, r would need to be at least the second highest value, but for the color to have no red, r would have to be 0. That's what no means - none, zip, nada, zilch  

- DL

[jani]

No, what your dealing with is various saturation levels of blue. Brightness level of blue is determined by the "b" value.
I'm not the one who is confused  . No red in a color would be only when r = 0. For a color be be a red, r would need to be the highest value, for a color to be reddish or have a red cast, r would need to be at least the second highest value, but for the color to have no red, r would have to be 0. That's what no means - none, zip, nada, zilch 

In that case, this is a case about terminology confusion, and I'm at blame.

Yes, I mean that the sky doesn't have a red cast.

Let me try to be a bit more precise about what I meant to say (and keep in mind that I'm not Bruce Fraser or Andrew Rodney ).

The original claim was that "a blue sky has more red than you might think, since it is not that saturated", and bjanes then proceeds to use an RGB representation of the sky as a proof.

This is where I think that he misunderstands the RGB colour model, and forgets that it's just a simulation. That there is a "red" value in RGB doesn't mean that the sky "has red" in it.

Keep in mind that RGB (regardless of colour space) is used to simulate a part of the visible spectrum by using a three-colour composite. Yes, the representation in RGB is using red to simulate the visible spectrum, but you could just as well say that a sky with 128,128,255 "has yellow" (since 128,128,0 is a dark yellow), or that a bright blue sky "has cyan", "has turquoise", "has mauve", "has maroon", "has green", "has violet", "has ultraviolet", "has x-ray", ...

Since it's possible to use an N-colour composite instead of the 3-colour composite RGB, and still be able to simulate the visible spectrum, it's possible to have models where red isn't one of the components. CIA L*a*b* is one model that doesn't use red as a component (its three axes are lightness from black to white, green to magenta and blue to yellow). Or you could've used a two-colour composite of orange and blue.

Would you still claim that -- in that two-colour composite -- the sky "has red"?

Going back to RGB, the value set of 128,128,255 isn't a simulation of a colour with red in it. It's a simulation of a clear blue.

[Ray]

Let me try to be a bit more precise about what I meant to say (and keep in mind that I'm not Bruce Fraser or Andrew Rodney ).

Going back to RGB, the value set of 128,128,255 isn't a simulation of a colour with red in it. It's a simulation of a clear blue.
[a href=\"index.php?act=findpost&pid=71362\"][{POST_SNAPBACK}][/a]

 

Jani,
As much as I sympathise with you for not having the knowledge of Bruce Fraser and Andrew Rodney, I have to agree with Don that 128, 128, 255 is not a clear blue. It's a blue that contains both red and green, both of which change the hue of the blue dramatically so that one really needs another name for the color.

Below is an example I created. The numbers might have changed slightly in the conversion, but it's clear that 128, 128, 255 is 'bluish' but not blue.

[attachment=834:attachment]

[jani]

Below is an example I created. The numbers might have changed slightly in the conversion, but it's clear that 128, 128, 255 is 'bluish' but not blue.

When I save the file and check the colour values with jpegtopnm, I see that it's 129,128,255. (A quick test in the Gimp verifies this.)

Perhaps you're reinterpreting it according to some colour space? That would explain the colour shift.

Try creating the colour with HSL adjustments instead.

[bjanes]

That's quite impossible.  How could the red be equal to the blue when red is less sensitive in the camera?  That would mean the sky-blue square actually had more red than blue.

You didn't shoot this with a warm light, did you?
[a href=\"index.php?act=findpost&pid=71335\"][{POST_SNAPBACK}][/a]

John,

You are correct, as usual. On rechecking my raw readings and converting to 12 bit, the RGB values of the blue patch are 288, 736, 800. The white balance in ACR is 5200 -7, and the white patch is neutral when converted; therefore, the white balance is good and the illumination is daylight. The normalized red is then 288/4095 = 0.07, and  that zone would have about 128 levels in the 12 bit file and 20 levels in the gamma 2.2 eight bit file according to Norman's chart. With much editing banding could well occur with this number of levels, but using 16 bit for editing would preserve all 128 levels and banding should not occur with reasonable editing.

Bill

[Ray]

When I save the file and check the colour values with jpegtopnm, I see that it's 129,128,255.
[a href=\"index.php?act=findpost&pid=71368\"][{POST_SNAPBACK}][/a]

Not surprising! I work in ProPhoto and the image has been converted to sRGB and jpeg compressed. But 128 or 129 is nitpicking. The color is essentially as it was when created. It's no longer a clear blue because of the presence of green and red. You might give it a name containing the word 'blue' because blue is the predominant primary, but the presence of red and green changes the hue whether or not the red and green channels have exactly equal value.

[bjanes]

In that case, this is a case about terminology confusion, and I'm at blame.

The original claim was that "a blue sky has more red than you might think, since it is not that saturated", and bjanes then proceeds to use an RGB representation of the sky as a proof.

This is where I think that he misunderstands the RGB colour model, and forgets that it's just a simulation. That there is a "red" value in RGB doesn't mean that the sky "has red" in it.
[{POST_SNAPBACK}][/a]

Well, our eyes and the camera both use RGB tristimulus values to simulate the color of the blue sky. For that color to be recorded by the camera or perceived by a human, it is necessary to have the red sensor activated. As you may recall, the Rho (red), Gamma (green) and Beta (blue) sensors of the eye have considerable overlap, especially for green and red. The camera sensors have less overlap.


[a href=\"http://www.photo.net/photo/edscott/vis00010.htm]http://www.photo.net/photo/edscott/vis00010.htm[/url]

In the RGB model, an unsaturated blue must have red and green components. If the red sensor of the camera is activated, this is equivalent to saying that the unsaturated blue has a red component as well as a green component. It may all be a matter of terminolgy, so why don't we just drop this topic?

[John Sheehy]

The normalized red is then 288/4095 = 0.07, and  that zone would have about 128 levels in the 12 bit file and 20 levels in the gamma 2.2 eight bit file according to Norman's chart. With much editing banding could well occur with this number of levels, but using 16 bit for editing would preserve all 128 levels and banding should not occur with reasonable editing.
[a href=\"index.php?act=findpost&pid=71369\"][{POST_SNAPBACK}][/a]

Normally, noise prevents contour banding.  Perhaps something in the workflow is smoothing it away, or something in the display hardware or calibration is quantizing it further.