Digital BW, The Print

> >> I've
> >> heard it said over and again, including from Andrew Rodney, that
> >> DR and bit
> >> depth are totally unrelated. When people say that, do they mean in all
> >> instances other than at point of capture?
>
> > I don't know why they say this, because it's simply wrong!  Yes, you CAN
> > represent any dynamic range with any number of bits 2 or more...BUT you
> > don't get the intermediate values (tones).
>
> Right, but doesn't that just show you CAN have one independent of
> the other?
> That IS the point, no?

I don't know what their point is, but scanners/CCDs/ADs work the way I said
they do.

> You've always maintained that you can't
> get to a high
> DR w/o sufficient bit depth, but what you offer above, to my
> mind, violates
> that. I understand high DR with low BD won't give us imagers what
> we want or
> need, but on a fundamental level.....

IMO, it's a silly exercise, that has absolutely no substance or meaning.
What is the point of it?  It's not the way CCDs work, it's not the way
density works...and it makes no sense to attempt to encode things
differently.  When you are encoding density ratio values, you use integer
values...and you also need to have just so many integer values to be able to
represent every ratio value in the dynamic range.  It's just so simple.

Sometimes things just naturally work well and fit together a particular way,
and unless there is a compelling reason to do it differently, why bother?

Also, if you do remap the dynamic range, you then have to know what the
mapping is.  If you map it to a lower bit depth, then you lose data.

I really don't get the big deal and why this is even an issue to anyone.  It
only comes about because of a lack of understanding that density is a ratio,
and ratios are integer values.  Once you understand that this is a ratio
issue, and how ratios are represented, it all just makes sense.  You know
that a ratio of 1.5 to 1 is the exact same as 3:2?  You can represent ANY
ratio value in integers.

> Did you see the one I posted a couple of days ago from Dan
> Margulis (he spoke of the extra digits on the thermometer, and
> related it to
> noise)?

Yes, I saw that...but that relates to some things, and not others.  I don't
recall what his exact point was...

> But, in short, most people are of the mind that bit depth and
> dynamic range
> are independent qualities, or that's how I've interpreted them.

Well, they just aren't.  You absolutely do need so many bits to represent an
entire range of integer density values over a particular dynamic range.  It
just works that way.  It's like saying counting and numbers are independent.

> I'll venture
> they may be right when considering the attributes of a file already before
> us, but not realize it's a little different when we are discussing the
> elements of a capture device.

I am specifically talking only about image capture devices.  I don't know
what you mean by the attributes of a file already before us.


> From Andrew Rodney:
>
>
> Todd asks:
> > First off, when in 16 bit mode in PS does the histogram indicate how the
> > file maps into 16 bit space, or an 8 bit space?
>
> Andrew answers:
> In a way both. The numbers in the Histogram (0 to 255) remain the same.

That is correct.

> Technically that\ufffds not really correct as there are a whole lot
> more numbers
> in a high but file.

That doesn't matter.  The histogram only uses the top 8 bits, so as he said
above, the histogram remains the EXACT same.

> The Histogram you see is accurate to the bit depth you are
> currently in.

I believe that is simply because the data is always high bit justified.

> > More specifically, when I capture a raw unmanipulated HDR file
> from my Leaf
> > scanner, which I believe scans in 14 bit, and bring it into 16
> bit space in
> > Photoshop, the tones in the histogram are bunched up.
> >
> That\ufffds because Leaf provides you untonede (linear) raw data.
> Newer scanners
> can provide high bit files that are toned.

Toning has nothing to do with it.  Toned data is NOT raw data.  Toning data
also does NOT really spread it out, setting the setpoints spreads it out,
whether you chose to tone it or not.  He is talking about something other
than raw data.  You CAN get both high bit raw data, and high bit toned data
out of newer scanners.

> > Or, Does it indicate that the dynamic range of the film scanned
> was just not
> > as large as that possible even in an 8 bit space?
> >
> Dynamic range has nothing to do with bit depth! They are completely
> different spec\ufffds.

As you know, I know that is completely incorrect.

> You can have a scanner with 16 bits per color and a
> dynamic range of 3.3

That is in fact correct, only by virtue of the fact that the number of bits
is NOT limiting the dynamic range.

> and you can have a scanner with 12 bits and a dynamic
> range of 3.8.

Absolutely wrong.  A dynamic range of 3.8 specifies integer ratio values
from 1 to 6,309, which means you need a number of bits that can hold these
numbers, and 12 bits can only hold 4,096 different values.

> Bit depth is the number of steps. Dynamic range is
> the height
> of the star case. You can have a staircase that\ufffds 20 feet high and have 40
> steps. You can have a staircase that\ufffds 30 feet high and have 30 steps.

He is right, but contradicts his example above!  If you have a bit depth of
12, as he states above, you only have 4,096 steps.  If your dynamic range is
3.8, which is 10**3.8 or 6,309...you don't have enough steps to hold it.
Pass this along to him and see what he has to say.

The only way to put a dynamic range of 3.8 into 12 bits is to lose data
values, period.


I snipped Rafe's comments, since I believe that is all covered in our recent
discussions...and we can get back to that if they still confuse you.

> *********
>
> Dynamic range is a separate concept from bit-depth.

Yes, they are separate concepts, BUT, YOU NEED A MINIMUM NUMBER OF BITS TO
CONTAIN A PARTICULAR DYNAMIC RANGE.  In other words, the number of bits does
limit the maximum dynamic range you can represent if you want to include all
intermediate integer density ratio values.

> Think of bit depth as
> the number of data points that can exist between dMin and dMax.

That's true.

> In Photoshop
> Levels, dMin and dMax will always be 255_0.

Yes, but that's only the top 8 bits if the file is of higher bit depth, so
it is not a 1:1 representation of the actual data

> In 16-bit mode, the Levels
> theoretically should be 65,535_0, but since that would be impractical to
> display on screen, the distributions are scaled to 255_0.

Correct.

> If the levels in your histogram (14bit-16bit) are bunched up or
> do not fill
> up the entire range (255_0), it is caused by your capture settings and/or
> the dynamic range of the captured image.

Well, not exactly.  The number certainly ARE limited by the capture device
or the image, but they can also be bunched up simply because of bit
justification, as we have discussed over the past few days.