Challanging assumptions about scanning B&W

[Bruce Watson]

Basically, I meant what Straun actually said. Nice explanation Straun.

[Struan Gray]

Ah. But you were brief :-)

[Chuck_1686]

Struan, thanks for the education. I'll probably only have to read it a couple more times but I can see how things are working.

[Kirk Gittings]

Ed read Michael Mutmansky's contribition to the new thread "Ideal film/developer-drum scanning B&W Landscapes", which explains my approach better than I can.

[Ed Richards]

> The linearity of the light measurement means that there is no benefit in terms of image data quality from applying a gamma curve or a custom tonal curve at scan time. There may well be workflow benefits, but the data doesn't care if it gets scaled in the digital domain inside the scanner or inside the computer. One caveat: often cheap scanner firmware is optimised to be small and fast, so tonal manipulations in the computer can in principle offer you more control, less noise and fewer artifacts.

I think that is where I started.:-)

The second point is that b/w points only matter if your scanner does change the gain. I wonder how many consumer flatbeds really change the gain in the hardware, as opposed to the scanning software? For example, the Canon 9950, which is a pretty good consumer level scanner, does not change the hardware gain. It would be interesting to know how many really do - Ed Hamrick would probably know, since he lets you change the gain/exposure in Vuescan if the scanner allows it.

Thus, unless your scanner changes the gain in hardware, we converge, 37 messages later, on the my original hypothesis that it is better to manipulate the data in the computer than to mess with scanner data manipulation, based on the original assumption that the scanner cannot change the exposure.

[Kirk Gittings]

Your original hypothosis is what I was taught and what is what most people are taught at the two universities that I teach at. It is not new thinking in my experience but old thinking that I have found through my testing creates problems down the road in the workflow at least with imagery like mine which requires tonal expansions.

By the time you got to the thread it had moved well past the point made by Michael that I was refering to. This is not a pissing match. My experience directly contradicts yours and I have tested the hypothosis thoroughly and repeatedly for over a year now with my own work and with my students. Michael simply explained my point in more scientific terms than I can. The section I was pointing you to starts with this statement:

"Kirk,

Yes, it does. That is part of the reason that I believe it is important to get is reasonably close to right in the scan, and not leave it to PS manipulation later on. Every manipulation to the file after it's creation destroys data in some manner, with the exception of some basic rotaional transpositions and other minor things like that.

Curves, Levels, color adjustments, etc. all ultimately are destroying data that was in the original file, which is why it is so important that the manipulations are made as Levels adjustments, and are not applied directly to the background.

In the case of Curves, as you have suggested, the adjustment of the midtones causes a seperation in the steps somewhere in the curve, and a compression of the steps in another part of the curve. When the seperation is drastic enough, it will cause an increase in the apparent 'grain' that is visible. In this case, I mean noise more than grain, but it does ultimately come off looking like digital grain.

This is partially exacerbated by the fact that most people consider a digital file to be a continuum, rather than a stepped data source. Further, PS is apparently not truely 16 bit, it actualy operates at 15 bits. Even more, most B&W files don't have anywhere near the theoretical number of possible levels of gray in them, most have much fewer than 1/2 and high bit files (16 bit) may often have 1/3 or 1/4.

Additionally, the problems most easily crop up in areas where there is a discontunity in the tonal structure of the file, because this is where a large step is already being made in the data.

This can be made worse if the source file is a general scan to cover the entire density range (the raw scan output approach), because then the useful data does not cover the entire range of the image file, and if there were possibility for some interpolated data within the useful data set, it was thrown out in favor of capturing useless data beyond the image density range.

Suddenly, 16 bit doesn't sound like too much, does it? Image how careful you have to be when scaning at 8 bit? My drum scanner has a 12 bit output, and writes a 16 bit file so it is useable in PS, but it only has 12 bits of true data in it. Because of the fine control over the input data, I am able to easily produce good scans that require only minor adjustments to the fie, and these types of scanning artifact problems do not show their head too much. I still have to be careful in open sky areas, though."

The point is simple and confirmed by Michael in his text. I have spent about two years now testing many scanners and software and service bureaus preparing for my current retrospective show, and I came to the conclusion that a workflow as you descirbe was not as effective for imagery like mine as the one I currently use which coincidentally is similar to the one developed by Michael M. and Ed Harris. I am simply sharing this so others do not waste as much time as I have on less "targeted scans".

[Struan Gray]

Kirk, I don't see any contradiction between what Michael has said and what I and Ed are saying. The essential point is the 'if': whether your scanner adjusts gain at the analogue stage or not, and if so, how?.

Most LF-ers are old enough to have recorded to tape. Ed and I are merely saying that some cheap scanners are like tape recorders that don't have a levels setting knob, and that if the knob is missing it is better to control the volume with a quality circuit in your amp than to use the one-cent volume potentiometer in the tape deck.

The biggest problem is that whereas it is usually clear that a tape deck is missing a levels control, scanner software is user-opaque: gain control comes and goes without the user explicitly being told.

Ed: I know that Ed Hamrick has posted a lot of info about which scanners do and do not adjust their gain (or integration time) in the newsgroup comp.periphs.scanners. Or you can email him a specific question. I don't use Viewscan, but I have learnt a lot from studying Ed's explanations of how it works. He's always friendly and informative in person.

FWIW, a lot of the effects that Kirk describes are the classic signatures of roundoff error. If you have 16 bits to play with (or 15) they will disappear, with the caveat that the code is properly written. Unfortunately, even Photoshop seems to get it wrong from time to time, and it's reluctant and grudging support for 16 bits per channel suggest to me that there may be problems under the hood. Note that if you pack a 12-bit number into the top bits of of a 16-bit file, that actually gives you more overhead when compared to the original signal to noise because you can fill those lower zeros with what would otherwise have been rounding errors.

That said, I have run my scans as double precision reals and as 64-bit integers through the package I use for my microscopy (IDL from Research Systems) and I can confidently say that I am limited by random and pattern noise in my scanner (an Epson 3200). In this case, squeezing every last bit of information out of the scanner helps, even at the expense of some sharpness.