Digital BW, The Print

> 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.

For 12/14 bit data setpointed (expanded) in 16 bit space, it depends on the
size of the move.  You can lose data by ending up having more different
values than can be fit into less values...such as compressing 10/11/12 into
10/11, you lose one of the values.  But, if your data is spread out...
1/10/19 and you reduce the range, to say 15/17/19, you lose no values.

> 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?

If your goal is only 8 bit data, then you are right to a large degree...but
then why do anything in 16 bits, why not just get the scan right in the
first place?  I believe that's an entire other topic.

> It only means you need less
> levels adjustment from the get go; less need to loose data through
> adjustments.

Hum.  I don't know that I believe that.  I think the level adjustments are
the same no matter what the bid depth...what you gain by higher bit depth
(in the file, not from the scanner...that is a very important point BTW) is
more discernable tones.

> 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?

I believe you have that pretty much 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

Yes, that sounds right.

> -- all by default, due to bit depth, as though bit depth is the prime
> determinant of dynamic range. Or, do I read you wrong?

The way CCDs work, and the way scanners are designed, yes, bit depth does
limit the dynamic range.  But, just because you have 16 bit data, that
doesn't mean the analog parts of the system are going to be able to give you
that dynamic range.

> 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).

Yes, but with raw data, it's compressed, until you set the setpoints and
expand it into the entire 16 bit range.  All an 8 bit histogram does for 16
bit data, is take the top 8 bits of the 16 bit data!

> You've yourself have been asking for a 16-bit histogram,

And selective zoom ;-)

> so I
> know you know
> this. The rest of those tones are just decimated.

Actually, they really aren't decimated.  Decimation means thrown away, they
are not thrown away...they are actually just combined with all other tones
that have the same top 8 bit value.  Yes, you lose the ability to discern
those tones, but they are there, though just rounded off...

> 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.

When you convert an 8 bit file to 16 bits, all you do is put zeros in the
lower 8 bits.  And of course, the histogram will look exactly the same,
simply because it's using the exact same 8 bits!

> 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.

It's a matter of representation.  It JUST SO HAPPENS that by design, yes,
most every film scanner made DOES represent density ratio values as simple
integer ratio values...so yes, number of bits does limit the dynamic
range...again, this is by design.  But, a scanner does not have to be
designed that way.

> 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,

Gamma only effects the midtones, not the endpoints.  Where white and black
were, they will still be.

The specific reason the data is "bunched up" in raw scans is because the
dynamic range of the film is less than the dynamic range of the scanner.
The scanner doesn't spread anything out...it only reads relative light
intensity, positioned within it's calibrated range.  Think of the scanner as
working just like a densitometer.  It simply measures the light intensity
value.