Banding Issues with the Nikon 9000

[richardman]

Is there a reference to this ProPhotoRGB may cause banding to appear? If any post processing is to be done, then one should use the widest Gamut possible. Besides, LR internally uses something similar to ProPhotoRGB so I'd like to see some references on it.

Thanks.

[Greg Miller]

Is there a reference to this ProPhotoRGB may cause banding to appear? If any post processing is to be done, then one should use the widest Gamut possible. Besides, LR internally uses something similar to ProPhotoRGB so I'd like to see some references on it.

Thanks.

It's just basic math. As I explained before, the number of discrete available tones in a larger color space must be spaced further apart than a color space with a smaller gamut color space (because both color spaces contain exactly the same number of total tonal values). Therefore the tones in the (continuous tome) image that must map to an actual color space tone must travel farther to the nearest tone, and more tones will end up at the same tone. That is banding. All digital color spaces cause banding. The larger gamut color spaces must by definition cause more banding than a smaller gamut color space, because the tones must be spread further apart from each other.

Think of 2 deserts. One desert called ProPhoto. The other desert called sRGB is smaller than ProPhoto desert. Within each desert there are 256 oases, called tones, that ares spaced equidistant from each other. Since ProPhoto is larger than sRGB, the Oases/tones in ProPhoto are spaced farther apart from each other than in the sRGB desert. Now lets say there are people that are scattered around the center of each desert (but not the outer regions). Each person needs to go to the nearest Oases/tone. The people in the ProPhoto desert will have to travel farther to get to the nearest tone, and there will be more people ending up at each oases/tone when they all arrive than there will be in the sRGB desert. That is the same as banding - ProPhoto will have more than sRGB. ProPhoto becomes even worse when you consider that many tones in ProPhoto are not visible to humans. All color spaces have the exact same number of available tones (as long as bit depth remains the same). So ProPhoto actually wastes some of those available tones, leaving fewer to be used to map continuous tones from the input image to.

So, for a person who want to minimize banding, ProPhoto is the worst color space to use (again assuming that a smaller color space contains all the necessary tones).

It is also incorrect to state that "If any post processing is to be done, then one should use the widest Gamut possible". If a smaller gamut color space contains all the tones of an image, the smaller color space is always the better choice for post processing.

And Lightroom does not actually convert image tonal values to RGB values until you export the image. When you export the image you may specify any color space that you want. So just because Lightroom uses something close to ProPhoto during the processing phase means nothing in terms of banding.

[richardman]

That's assuming that a blue sky uses up all 256 levels. BTW, I write C compilers for a living so I do know computer stuff fairly well, albeit that I do not play with photo processing algorithms.

You may be right, I'm just not convinced. Lets leave it at that.

[Greg Miller]

That's assuming that a blue sky uses up all 256 levels.

Given the multiple layers of problems with that comment, leaving it at that is a good idea.

[rdenney]

The problem with using narrower color space, though, is that it will clip the ends of the histogram. This may be a "feature" of Vuescan, but I always clipped the histogram when using a narrow colorspace output, and have largely solved that problem by using ProPhoto. I've never had banding issues with my Nikon 8000 using a wide space like ProPhoto, unless I'm doing something really extreme with a curve adjustment. I did get clipping when I used sRGB, which is worse.

The Raw space in Vuescan is Raw only from Vuescan's point of view, not from the scanner's point of view, near as I can tell. I always scan to a wide colorspace and store in a 48-bit TIFF file, rather than depending on a post-scan raw conversion. So far, I've not lost anything by doing so, that I can tell. I then open the TIFF file with Photoshop and make general corrections and most interpretations in the wide space. If I need specific (and narrower) downstream colorspace (such as for web display), I convert (NOT assign) to that colorspace as part of targeting the image to that output. (I keep correction--which applies to a standard file--and targeting as separate processes.) The only time I get banding is from noise in dense areas, and then only when I'm trying to move those tonal values far from their starting points.

The only time multiscanning does any good for me is in those cases, when there is a lot of density in the slide or negative. Multiscanning averages several samples from those parts of the image where the sensor is starved for photons and therefore subject to noise. For images that are mostly bright, or where I'm not trying to bring shadows up a lot, I don't notice much improvement. (Or for negatives that are mostly dense with highlights where I might be trying to pull them down a lot, particularly bright skies.) One way to avoid the the temptation to really move those values is to get the filtration close in the camera. The less I have to move those tonal values in Photoshop, the better the outcomes for me.

Rick "whose experience may not be universal" Denney

[Greg Miller]

The problem with using narrower color space, though, is that it will clip the ends of the histogram. This may be a "feature" of Vuescan, but I always clipped the histogram when using a narrow colorspace output, and have largely solved that problem by using ProPhoto. I've never had banding issues with my Nikon 8000 using a wide space like ProPhoto, unless I'm doing something really extreme with a curve adjustment. I did get clipping when I used sRGB, which is worse.

The Raw space in Vuescan is Raw only from Vuescan's point of view, not from the scanner's point of view, near as I can tell. I always scan to a wide colorspace and store in a 48-bit TIFF file, rather than depending on a post-scan raw conversion. So far, I've not lost anything by doing so, that I can tell. I then open the TIFF file with Photoshop and make general corrections and most interpretations in the wide space. If I need specific (and narrower) downstream colorspace (such as for web display), I convert (NOT assign) to that colorspace as part of targeting the image to that output. (I keep correction--which applies to a standard file--and targeting as separate processes.) The only time I get banding is from noise in dense areas, and then only when I'm trying to move those tonal values far from their starting points.

The only time multiscanning does any good for me is in those cases, when there is a lot of density in the slide or negative. Multiscanning averages several samples from those parts of the image where the sensor is starved for photons and therefore subject to noise. For images that are mostly bright, or where I'm not trying to bring shadows up a lot, I don't notice much improvement. (Or for negatives that are mostly dense with highlights where I might be trying to pull them down a lot, particularly bright skies.) One way to avoid the the temptation to really move those values is to get the filtration close in the camera. The less I have to move those tonal values in Photoshop, the better the outcomes for me.

Rick "whose experience may not be universal" Denney

I was very careful to state previously "one should always choose the smallest gamut color space that still encompasses all the tonal values of the image". Clipping will not occur if the color space can represent all the tonal values.
If the image tones, require ProPhoto RGB, then ProPhoto RGB will need to be used to represent those additional tones. But at the tradeoff of lager spacing between discrete tones.

[Greg Miller]

Actually clipping at the ends of the histogram would be shadow & highlight clipping - It would be hard to say why sRGB would limit the dynamic range and cause this clipping. I don't use Vuescan so I can't comment on why that would happen to you, but using sRGB should not limit dynamic range.

[photobymike]

try changing the cable between your computer and scanner ..use one with a ferrite coil on one end of the cable

[richardman]

Snarky snarky, I know so much. *roll eyes*

[richardman]

Your eyes and monitor can probably not be able to tell initially the difference between sRGB or ProPhoto. So why does it matter? It's when you start any sort of manipulation that you want the larger color gamut. If you do much post processing, then the simple workflow of using sRGB is fine. Otherwise, if you have banding, solve the problem other ways rather than picking on color space based on someone's theory.

Fine mode works for most, and also for OP.