Banding Issues with the Nikon 9000

[Greg Miller]

Of course it is there even if one cannot see it, that's exactly why one uses the widest gamut possible. So you show a more or less monochromatic image. Whoohoo... whatever. I will scan in ProPhoto, you will eyeball your monochromatic images and scan in sRGB. Whatever. There's no banding with ProPhoto.

So which box of Crayolas would you choose? The one with only 8 tonal values for red (small gamut), or the one with 64 (wide gamut)?

[Greg Miller]

You want to use as large as a gamut your workflow can handle. This is why you use your own printer profiles and not sRGB through the printer driver.

What? No, you use a printer profile because it is device dependent, unlike a color space like sRGB which is device independent. The device dependent print profile corrects for color inadequacies that the printer has for any given printer/ink/paper combination.

LR uses ProPhoto like space, so scan outputting that space would lessen any translation issue on the input side. As you post process, the larger gamut keeps more of the info. Then when you print, that's the only time you need to convert to a different space.

What? LR only uses ProPhoto to display an image during LR processing (it was a safe choice to prevent out of temporary gamut display issues for large gamut images while working in LR). When you output the image, LR converts the RAW data directly to the output colors pace chosen in the output section.

[polyglot]

hey guys, this isn't APUG so you don't need to be fighty...

As to the subsequent ("which options") question, I would suggest the additional things:
- 64-bit RGBI
- AF on Scan
- Raw Save on Save
- IR clean: light*, except for silver-containing films
- make extensive use of Lock Exposure, Lock Film Base and the All Frames option on the Colour tab.
- inspect the Ctrl-1 (raw) and Ctrl-2 (inverted, with clip points) histograms carefully for scan faults like under- or over-exposure of the neg in the scanner Over-exposure does NOT go all the way to the right, you get a little tooth just short of where you expect it on the raw histogram.
- manually adjust your film-base colour to prevent unnecessary (negative) shadow clipping and shadow colour-cast; its auto-detection is sometimes painfully wrong
- save raw: Type Auto, DNG.
- DO NOT check the "Raw Save Film" box, it will save non-raw values i.e. after film-base subtraction, etc. I think if you leave it unchecked, you get basically raw data, prior to the inversion. I don't know if it includes IR cleaning.
- verify the file sizes are appropriate (48b = X*Y*6 bytes for the raw file) after the first save; this can save pain if you've accidentally bumped the Reduce Raw slider or something stupid
- verify the first jpeg to make sure you haven't accidentally left JPG B&W selected (also a hard lesson)
- don't forget you can open your saved RAWs in Vuescan (Scan From File in the Scan Source combo box) to reprocess/invert the jpegs differently if you find better colouring settings later in a roll

* this is contentious. There is a small loss of resolution sometimes, but I contend that in a print from a 120 neg, it's not relevant. The time savings alone when scanning C41 or E6 make it totally worth it. Don't do it if you don't want, but don't blame me for the hours you'll spend spotting your scans.

I'd link you to my "how to scan C41 in Vuescan" FAQ article but my idiot webhost has f*cked up a PHP upgrade and broken my site for the second time in 3 weeks.

[Greg Miller]

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

Say what? I haven't seen a sky (except for at night) that uses a valuer of 0 (black). So the sky will use significantly fewer available tonal values that the full 256. But 256 implies 8 bit processing. Everybody I know quit using 8 bit for landscapes years ago because iof banding they got in blue skies.

And where did ever mention blue skies anyway?

And I can write assembler code. Can;t say that ever had any impact on my knowledge of color management.

[rdenney]

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.

I'm not being theoretical. In theory, I agree with you. In practice, I see histograms that are clipped.

Rick "who has never seen banding from the Nikon except when making extreme tonal moves, irrespective of color space" Denney

[richardman]

re: the original question about Nikon banding. I used an LS-8000 for 3 years and then LS-9000 for 3 years now. I upgraded to the LS-9000 precisely because the LS-8000 shows more banding on scanning B&W. There are lots of google links on this, and the LS-9000 supposes to be better. However, I found that the LS-9000 still shows banding sometimes, but in all cases, it goes away when Fine Mode is checked.

[parasko]

Great! This was the type of advice I was seeking. Thanks!

hey guys, this isn't APUG so you don't need to be fighty...

As to the subsequent ("which options") question, I would suggest the additional things:
- 64-bit RGBI
- AF on Scan
- Raw Save on Save
- IR clean: light*, except for silver-containing films
- make extensive use of Lock Exposure, Lock Film Base and the All Frames option on the Colour tab.
- inspect the Ctrl-1 (raw) and Ctrl-2 (inverted, with clip points) histograms carefully for scan faults like under- or over-exposure of the neg in the scanner Over-exposure does NOT go all the way to the right, you get a little tooth just short of where you expect it on the raw histogram.
- manually adjust your film-base colour to prevent unnecessary (negative) shadow clipping and shadow colour-cast; its auto-detection is sometimes painfully wrong
- save raw: Type Auto, DNG.
- DO NOT check the "Raw Save Film" box, it will save non-raw values i.e. after film-base subtraction, etc. I think if you leave it unchecked, you get basically raw data, prior to the inversion. I don't know if it includes IR cleaning.
- verify the file sizes are appropriate (48b = X*Y*6 bytes for the raw file) after the first save; this can save pain if you've accidentally bumped the Reduce Raw slider or something stupid
- verify the first jpeg to make sure you haven't accidentally left JPG B&W selected (also a hard lesson)
- don't forget you can open your saved RAWs in Vuescan (Scan From File in the Scan Source combo box) to reprocess/invert the jpegs differently if you find better colouring settings later in a roll

* this is contentious. There is a small loss of resolution sometimes, but I contend that in a print from a 120 neg, it's not relevant. The time savings alone when scanning C41 or E6 make it totally worth it. Don't do it if you don't want, but don't blame me for the hours you'll spend spotting your scans.

I'd link you to my "how to scan C41 in Vuescan" FAQ article but my idiot webhost has f*cked up a PHP upgrade and broken my site for the second time in 3 weeks.

[Denverdad]

While all of this discussion of color spaces is interesting, I believe it came out of a misinterpretation of the OP's question. Let me first explain that the Nikon Coolscan 8000/9000 scanners are notorious for sometimes producing a particular scan artifact usually called "banding". This artifact appears as a regular pattern of parallel lines running along the same axis as the scaner's tri-linear sensor array; i.e., perpendicular to the scan direction. It occurs (when it occurs at all - some users apparently never see it) only when scanning at maximum resolution (4000 spi), and can manifest itself with B&W, color negative or color positive film, and as far as I know at any bit depth and with any color space. Regular spacing is a key aspect - and just as an example, the banding produced by my 9000 has a period of exactly 36 columns of pixels. At the heart of it all is apparently some undefined calibration issue associated with the simultaneous use of the tri-linear array's 3 sensor rows. And as reported, using super fine mode makes the banding go away to "solve" the problem. I have to put that in quotes because while superfine mode does elminate the banding artifact, it also results in substantially longer scan times, as you might expect since it makes use of just one row of the sensor as opposed to all three. Also just for reference, many claim that Nikon solved the banding problem when they came out with the Coolscan 9000, but like richardman, I can report that my particular 9000 does in fact exhibit this artifact too.

So that is "Nikon banding". In contrast, when people are referring to banding as related to color spaces, bit depths, histograms and so forth, I believe they are referring to an effect which is otherwise known as posterization. I am happy to stand corrected on that, but this sense of the word is pretty much unrelated to the OP's banding problem. In any event this has been my attempt to disambiguate the term banding, and hopefully it has been helpful and not just pedantic.


Jeff

[richardman]

Jeff, I concur with your assessment, and I apologize for participating in a "side-tracking" subthread.

When I get banding, it is exactly as you describe, regular columns.

[cabbiinc]

Thanks for your comments. Much appreciated. It looks like Fine Mode does the trick.

I'm trying to extract as much information as possible from my 35mm slides in order to be able to print as large as possible. For those of you familiar with Vuescan, is there a setting I should be using other than the following below?

Input
Scan resolution =4000dpi
Fine Mode
(Still experimenting with Multi Exposure-I cannot see a noticeable difference at this stage)
Number of Samples =1 (Does image quality improve by using a larger number of samples?)

From what I've read fine mode uses only one line of the CCD to be used. http://www.hamrick.com/vuescan/html/...#inputfinemode Why that would cut down on banding I don't know, but there's plenty of other discussions saying that it does.
Multi-Exposure is only useful with slide film with contrast that exceeds the dynamic range of the scanner.

Filter
Infrared Clean =Light

Output
Output = Raw file 48bitRGB (Is there a real world difference between the 48bit and 64bit option?)
What setting should I choose for Printed Size?

Keep in mind that Vuescan defines "bits" per pixel. So what Photoshop would call 8 bits Vuescan would call 24 (8 bits per pixel. Red Green Blue pixels). PS's 16 bit is Vuescan's 48 bit. And 64 bit in Vuescan is adding the Infrared channel, i.e. RGBI. If you're not going to use that IR channel info then you'll not see a difference. If however you plan to revisit the file within Vuescan and possibly use the IR channels data then saving it would be needed.