Digital BW, The Print

Hi again, Martin!

> > > So as an example let's say that a raw scan of a particular
> negative from
> a
> > > 12-bit scanner produces 2500 levels with the highest falling on
> > > say 3500 and
> > > the lowest on 1000. I assume that in 12-bit space these 2500
> > > levels are all
> > > adjacent without any levels that have no pixels (assuming it is a
> > > continuous
> > > tone negative.)
> >
> > Exactly correct again, except that there is no such thing as 12
> bit space,
> > 12 bit space IS 16 bit space.
>
> Austin,
>
> I see, it is not coming from a 12-bit space but rather is a stream of data
> with values that will fall between 0 and 2^12-1.

Correct.

> > > Now when this is mapped to 16-bit space let if
> > > each level is
> > > multiplied by 16 then the highest value would be on 56,000 and
> > > the lowest on
> > > 16,000 giving a spread of 40,000 in 16-bit space.
> >
> > Nope...it is simply the exact same values, except there are
> four more high
> > bits, the data is exactly the same.
> >
> > > Or is the highest value mapped to 56,000 and the lowest to
> 56,000 - 2500
> =
> > > 53,500?
> >
> > No...again, the data values are EXACTLY the same, 1000-3500, all
> contiguous.
> >
> > > This second case seems unlikely from the raw scans I have
> > > seen from
> > > 12-bit scanners. 2500 adjacent levels in 16-bit space would
> be extremely
> > > narrow when you looked at a histogram.
> >
> > Yes, it is very narrow.
>
> Okay understood. I guess my misunderstand comes from the fact that the
> histograms I see of raw scans, while narrow, are often considerably larger
> then 6% of the 16-bit range I would have expected. However since the
> histograms are 8-bit I guess we cannot take them literally.

Yeah, that is why I want to understand what on earth is going on with the
raw data...and how it's justified.

A digression:

Let's say a typical film scanner has a dMax of say, 3.6...and it's got a 12
bit A/D...  12 bits can only represent 4096 distinct values...  Now, typical
film scanners we use do not have adjustable front ends, they do have
adjustable exposure time, but that doesn't change the data relativeness that
the sensor sees...they record the data with linear differences in density.

Now, this is a tough one, and I know it doesn't make practical sense, but
bear with me.  B&W film has a density range of say, 2...well, according to
how our scanner works, that's only 100 discernable tones if the scanner
records linearly throughout the entire density range, where each discernable
density step is the same, and that's how most all of them work as far as I
know.

The scanner, when recording, doesn't know what the density range of the film
is, that it is scanning, it has to record the entire range of 3.6 for EVERY
film that it scans.  That assumes that it doesn't have an adjustable front
end, and none of the typical film scanners do...  The density range of the
film comes into place when you set the setpoints, you are telling the image
file what the density limits of the scanned film is.

Now back to our regularly scheduled program ;-)

> So we have 2500 adjacent levels in 16-bit space. Obivously then if you do
> any gamma, curves or similar adjustment without first adjusting the end
> points outward you will lose or damage the data.

Exactly correct, and why you need to set setpoints first, then expand the
setpointed image data over the larger range, to give you gaps between the
data to allow for tonal corrections.

> pixels will be moved from
> one level to another level and added to the pixels already at that level
> resulting in spikes and gaps in the data reducing the number of total
> levels.

Bingo.

> If you spread or remap the end points on your data set first, you create
> room to move the pixels from one level to another without adding them to a
> level that already contains pixels or at least reduce the certainty to a
> possibility.

Correct.

> With our example of 2500 adjecent level from 1000 to 3500 in
> 16-bit space let's say we move the 3500 value to 65,000 and the 1000 value
> to 10. We still only have pixels assigned to 2500 discrete levels
> but those
> levels are now scattered across a range of 64,000 possible levels
> and while
> moving them around during adjustments the chances of their
> interferring with
> eachother is small. Am I tracking this correctly so far?

Absolutely.  That's exactly what happens.

> > > So, if the first case is correct, in 16-bit space are there then 15
> levels
> > > with not pixels at those values between each of the mapped
> > > values? In other
> > > words is the highest level in my example now 56,000 and the
> next lowest
> > > value 55,984, then 55,968, etc.?
> >
> (snip)
> > >
> > > I suspect it may have been a victim of a phenomenon in Silverfast
> > > where you
> > > can specify a gamma setting to be applied to the raw scan on the fly
> which
> > > then of course it is not really a raw scan.
> >
> > You should not apply ANY tonal curve adjustment to raw data until you
> > setpoint it, for obvious reasons!
>
> Believe it or not Silverfast is designed to do just that if you check a
> certain option box.

Well, they still sell matches ;-)

> > > When you open this
> > > "raw", gamma
> > > adjusted file directly in PS it initially has a good
> histogram but after
> > > applying Levels the histogram looks mildly combed. No full gaps
> > > but it gets
> > > rather spiky. Doing a raw scan in Silverfast and not applying
> the gamma
> > > setting seems to avoid this issue.
> >
> > That is exactly what I would suspect would happen if you apply tonal
> changes
> > to un-setpointed data.
>
> Well this makes a lot more sense. If you know what is going on the problem
> is easy to avoid.

Hence why I like having these discussions for not only my self, but others
to understand the theory behind this stuff.  I DO believe it helps allow you
to get better images.

> Thanks for helping me sort this out.

I believe you have the justification and understanding of it's implications
spot on, except for the "right" and "left" issue, which I believe I clarify
above.

Regards,

Austin