Digital BW, The Print

Austin,

Thanks for the effort. Ready for more? ;-)

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

I see, that makes sense to me.
 
>> 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.

No, I don't want to talk about 8-bit, or about doing it in the scan. I want
to talk about highbit data, and how it is mapped to the histogram in PS
while in 16-bit mode. If this conversation starys the tiniest bit, it never
comes back to topic. ;-)

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

This suggests you'd prefer a more contracted set of tones, inside of a lower
bit depth, rather than a full set of tones in a higher bit depth.

It doesn't make sense to be worrying about loosing data when you already had
a nicely distributed histogram via a "full range of 16
bit data" (assuming we are both NOT assuming clipped endpoints of course).

I'd be far more fearful of an image getting degraded, or a histogram
combing, due to expansion of too few tones, than contraction of too many,
for precisely the reason you demonstrated above.

See how you are presenting two sides of the argument at once?

Not trying to trap you in a corner (well, maybe a little <g>), just showing
why I find the conversation confusing.
 
>> 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

Yes, that is my point! Why then wouldn't you prefer to have that 16-bit
scan? You've got the same levels adjustment to make, why not do it on a file
that has more tones to throw away without significant loss?

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

Right, more discernable tones between the end points (still talking raw
data), but I don't believe bit depth is what determines where your endpoints
fall. (Unless, your scanner really has a lower DR than your film, in which
case one or both of your endpoints would be clipped. But we've been talking
about compressed data, which is the opposite of that).

You've been arguing (or so it seems as evidenced below) that bit depth
determines where your endpoints fall. And you suggest that as bit depth
increases, so does the distribution of tones across the histogram. Higher
bit depth = a larger portion of the histogram filled.
 
>> 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 we are talking about compressed data, not clipped data. At this point of
the discussion the DR of the material HAS been captured. We are talking
about how it gets mapped to the histogram.

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

Could you elaborate? And elaborate how what you are saying fits in with my
point that DR is simply a ratio of Dmin to Dmax, and thus just one bit of
data can represent a high DR if it's two points are far apart (black/Dmin
and white/Dmax). If one bit can describe it, how does more bits make it
wider?

(Look, if getting into scanner design is required lets not go there. I'm
really interested in how the data is mapped to the histogram).

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

Okay, I think you're right about that.
 
> 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.

Okay, but this is confusing again. This seems to fly in the face of what you
stated above. Remember your premise was that 10-bit data will map to the
histogram, by default, due to lower bit depth, and hence lower Dynamic Range
(again your premise that DR is directly a function of bit depth), more
narrowly than 14-bit data.

But, the logic presented immediately above would suggest the opposite; that
as the bit depth of the scanner goes up, the raw scans would map more
narrowly to the histogram, as the difference between the DR capability of
the scanner further exceeds that of the film.

So where you started the conversation with the premise that a 16-bit raw
capture would by default fill more of the histogram, you seem to be implying
at the end that as bit depth goes up, so does DR, and the more the DR
potential of the capture device exceeds the DR of the film, the more
narrowly it should map to the histogram.

So, while I can not answer this conundrum, I do see why I'm confused. You?

Todd