Digital BW, The Print

on 9/25/01 2:18 PM, Austin Franklin wrote:

> They also claim "ideally suited for...16-bit compatible software such as
> Adobe Photoshop"...  And as I said, if you are getting a full range of 16
> bit data, you can NOT do any level shifts to it in PS without losing data.

Austin, as you can imagine I write this with great trepidation, as I'm sure
you will read it with with great suspect, but I'd like to try to work
through this with you again. ;-)

I want to separate this as much as possible from a discussion about any
particular scanner, or any one film type, i.e., color or BW, or any
particular output. I think we need to focus on how PS6 deals with data,
including raw scanner data.

There are basically two points you've made in the past around this subject
which have confused me, and I *think* are either wrong, or besides the
point, but I'm not *certain* of that, so I'd like you to take the
opportunity to explain yourself more fully, if you would please.

Forgive me cause I suck at math, and don't relate to the world through it,
so I'm going to ask you to please try to utilize some form of visual
metaphor when possible.

When you say, "if you are getting a full range of 16 bit data, you can NOT
do any level shifts to it in PS without losing data." I believe this is
true, but beside the point. I believe there is NO condition under which you
can do a levels move and not loose data, (including what you imply is a
better scenario: expanding 12, or 14-bit data in 16-bit space) If I'm right,
I'm not certain why you make mention of this here and in the past. If I'm
wrong, please explain.

Furthermore, assuming one generally wants to end up with a fully toned 8-bit
file (most of histo occupied -- not talking highkey or low key images), why
wouldn't you want the same of a 16-bit file? It only means you need less
levels adjustment from the get go; less need to loose data through
adjustments.

The other point is from the past. You've implied or stated that the reason
raw highbit scans have PS histograms which are very contracted, with tones
placed in predominantly in the lower end of the tonal scale, is because they
are 12, or 14-bit files mapped into a 16-bit space. In other words, 16-bit
space holds some 65,000 tones (I forget the number, and my dysfunctional
math won't allow me to figure it out, so my numbers are guesses and meant
only for illustrative purposes), while 14-bit may only hold some 4,000
tones, and what we are seeing are where those 4,000 tones sit in a space
which can hold 65,000 tones. Right?

This notion suggests a raw 10-bit scan by definition would occupy a very
narrow range in the histogram, 12-bit somewhat less less narrow, 14-bit
getting considerably wider than the 10-bit, and 16-bit virtually filling it
-- all by default, due to bit depth, as though bit depth is the prime
determinant of dynamic range. Or, do I read you wrong?

But I don't believe that's what's happening, because PS, even in 16-bit
mode, shows you how that data is mapped relative to 8-bit data (256 tones).
You've yourself have been asking for a 16-bit histogram, so I know you know
this. The rest of those tones are just decimated. If you take an 8-bit file
and convert it to 16-bit, it's histogram will look essentially the same in
each bit mode, it doesn't automatically expand by virtue of increased bit
depth. Likewise when you convert a 16-bit file to 8-bit, it's histogram
looks the same at each bit mode.

Your scenario makes a case that Dynamic Range is directly a function of bit
depth, which it is not. As you've stated before you only need one (or was it
two) bit data to have a large dynamic range.

I believe the reason the histos of the raw scans are bunched up is because
the scanner writes the data out in linear gamma (1.0). As we increase the
GAMMA of the file it stretches out in the histogram, not by increasing the
bit depth. The larger bit depths merely allow us to increase the gamma
without dropping a significant number of tones, but tones are being dropped.

So, before you get too deep into formulae, please answer broadly if I've
represented your concept fairly (I'm still not sure), then try to explain
broadly where I'm astray in my understanding of your premise, then as a last
resort, backup your theory (OK, facts <g>) with mathematics.

Thanks,
Todd