Yahoo Groups archive

Digital BW, The Print

Index last updated: 2026-04-28 22:56 UTC

Message

Re: [Digital BW] Bit depth, was Minolta DiMAGE Scan Multi PRO

2001-09-26 by Todd Flashner

Austin, 

In another post I accused you of contradicting yourself. I should give you
the opportunity to defend yourself. I think you do understand this stuff, so
if we disagree it's probably in my misunderstanding, as you've said all
along. ;-)

We were here (scenario #1):

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

Austin:
> I believe you have that pretty much right...

Todd: 
>> 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

Austin:
> Yes, that sounds right.

Further in the same post I stated (Scenario #2):

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

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

So right in this one post, in scenario 1, each step up in bit depth gives a
larger histogram. In this second scenario, as the bit depth goes up the
histogram should get smaller, as the scanners DR would further exceed that
of film. Do you see that?

I will come back to the linear gamma later.

Then we go here (scenario #3):

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

Austin: 
> I really don't understand your term "map to the histogram".  You're missing
> something here...  No matter WHAT the bit depth is, only the top 8 bits are
> used for the histogram.  Nothing is mapped.  Also, dynamic range is LIMITED
> by bit depth.
> 
> If you take a 10 and 14 bit scan of the SAME image, using the same
> setpoints, and expand the data into the 16 bit range...you will get the
> exact same histograms...for two reasons.  One, the image data will be the
> same whether the scan is 10 or 14 bits, providing you have not exceeded the
> dynamic range of number of bits, and two, because only the top 8 bits of the
> data are used for the histogram.

What I mean by "mapping to the histogram" is how the scanners software
assigns tonal values to the inputs received by the CCD.

Your second paragraph  seemingly refutes scenario #1 which you agreed to, by
stating the histo of a 10 bit file will be the same as that of a 14 bit
file.

Then we go here (scenario #4):

Austin:
> I've given this explanation before, you can check the archives.  The way the
> CCD works is quite simple.  It's all relative.  It gives values of 1 to
> N...and a value of 1 means a density ratio of 1:1.  When the CCD gives you a
> value of 2, that means it is twice as dark as 1.  These just so happen to be
> the exact same thing as integer density ratio values.

You say the same thing here:
> that you can REPRESENT any dynamic
> range with two or more bits...but as I have said, that is NOT how scanners
> happen to be designed.  And for a very good reason.  CCDs output an analog
> signal that is (more or less) proportional to the light that the sensor
> elements see...and when the light is twice as strong as the another light,
> the signal has twice the strength!  AND that happens to pretty much coincide
> with "integer density ratio values".  This is just REALLY simple.

Okay, really simple, but isn't this just an explanation of the linear gamma
I was speaking of in Scenario #2? There you shoo off my linearity premise
and tie the shape of the histogram into DR as a function of bit depth again.

I suspect there are specific conditions which are causing these statements
to appear contradictory, but they are too spread out in our posts for me to
get a handle on. Do you want to take a crack at tying them together? You've
been generous about trying to explain this to me, but get frustrated by not
knowing what I am missing. I'm just still trying to provide you with what
that missing is. I suggest a from scratch approach, as the
point/counter-point gets confusing after a couple of rounds. Perhaps if you
took it from the top: Light passes through the film to the CCD. The
brightest light is that which passes through the least film density and it
gets assigned a tonal value of -blank-. The next brightest bit of light gets
the whole integer value of -blank- assigned to it.... and so on. Which, side
of the scale does get assigned first, the side that passes through the least
film density, or the most? What determines what value that is assigned? How
is it different on a 10 bit scanner than a 14 bit scanner? See what I'm
saying?

I hope this isn't TOO tedious for everybody. I think if from this we could
come up with a short, one page primer on how scanners assign tonal values to
their inputs, and how that changes with changes in bit depth, it would be a
nice addition to the files section, and cut down on a lot of chatter about
this in the future.

Todd

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.