Digital BW, The Print

Any experiences with this outstanding 4.8 dynamic range scanner?

Been using the original Scan Multi with the Multi II software 
upgrade. I like it.

Is the PRO out yet? It was supposed to be released in October.  
I'd be interested in taking a look at it. Especially with the various 
problems the Nikon 8000 has been having and the 
questionability of Polaroid with its money problems.

Butch Hulett
 
--- In DigitalBlackandWhiteThePrint@y..., "Andre Vallejo" 
<avs@p...> wrote:
> Any experiences with this outstanding 4.8 dynamic range 
scanner?

Andre,

I looked up the specs and they are pretty impressive. In the 35mm 
department 4800 dpi at a full 16-bit depth surpasses the competition. 
In medium format the dpi drops to 3200. I wonder in comparison to the 
Polaroid and Nikon which is more important, the extra 800 dpi or the 
extra bit depth (16 vs. 14)?

Comes with a glass carrier that should please a lot of people. Did 
not like the fact that you have to cut your medium format negs down 
to single frames. I like to keep mine is strips of 2 or 3.

Also take manufacturer's dynamic range specs with a grain of salt. 
There are other factors besides just the A/D converter.

Still I am glad to see more competition in this area. It will help to 
bring down prices and add features. Now if it just took 4x5 I would 
be really excited!

Martin Wesley


--- In DigitalBlackandWhiteThePrint@y..., "Andre Vallejo" <avs@p...> 
wrote:
> Any experiences with this outstanding 4.8 dynamic range scanner?

> I wonder in comparison to the
> Polaroid and Nikon which is more important, the extra 800 dpi or the
> extra bit depth (16 vs. 14)?

I doubt it is really 16 bits...  Do you have a URL that says that the actual
A/D being used is a 16 bit A/D?  If it were, there would be no room for
tonal curve moves.  You always have to provide more space (higher bit depth)
than the actual data, or you can't make tonal adjustments without losing
data.  16 bit data would require a 24 or 32 bit space to work in.

Also, 16 bits is entirely unnecessary to capture image data at, since no
film you will be scanning can have a dynamic range of 4.8!

Hi Austin,

Here is the URL that will get you to the spec sheet for the scanner:

http://www.dimage.minolta.com/

Be sure to have your magnifying glass ready! Some idiot set the whole 
thing in 4 or 6-point type. Talk about trying to read the fine print!

I share you skepticism on this one. Is it perhaps a numbers game 
where the 16-bit A/D converter cost very little but let's them make 
more outrageous claims?

Martin



--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" 
<darkroom@i...> wrote:
> > I wonder in comparison to the
> > Polaroid and Nikon which is more important, the extra 800 dpi or 
the
> > extra bit depth (16 vs. 14)?
> 
> I doubt it is really 16 bits...  Do you have a URL that says that 
the actual
> A/D being used is a 16 bit A/D?  If it were, there would be no room 
for
> tonal curve moves.  You always have to provide more space (higher 
bit depth)
> than the actual data, or you can't make tonal adjustments without 
losing
> data.  16 bit data would require a 24 or 32 bit space to work in.
> 
> Also, 16 bits is entirely unnecessary to capture image data at, 
since no
> film you will be scanning can have a dynamic range of 4.8!

> Hi Austin,
>
> Here is the URL that will get you to the spec sheet for the scanner:
>
> http://www.dimage.minolta.com/
>
> Be sure to have your magnifying glass ready! Some idiot set the whole
> thing in 4 or 6-point type. Talk about trying to read the fine print!
>
> I share you skepticism on this one. Is it perhaps a numbers game
> where the 16-bit A/D converter cost very little but let's them make
> more outrageous claims?
>
> Martin

I believe they are not being honest here, or just plain don't know what they
are talking about.  There is a little link to a URL that shows 14 bit vs 16
bit.  It claims 16 bits "resolves the image with greater fidelity...".  That
is a physically impossibility.  First off, the shadow detail they show is
not near real shadow detail!  It's mid range detail.

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.

I believe the curve they show is erroneous.  All, both 16 and 14 bit
values/steps, would be in the MIDDLE of the curve, and they wouldn't be
steps, they would be dots.  Pixel depth doesn't have "steps", they are ratio
values and more bits just give you larger numbers, the "steps" between the
numbers is exactly the same.  Steps happen with PPI, NOT with pixel depth.
This is very very misleading.

Click on "16-bit A/D..." on the Pro page, then click on "16-bit vs.
14-bit...".  Take a look and see if you agree.  This really irks me.  I
believe it's totally outrageous.

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" 
<darkroom@i...> wrote:
> 
> > Hi Austin,
> >
> > Here is the URL that will get you to the spec sheet for the 
scanner:
> >
> > http://www.dimage.minolta.com/
> >
> > Be sure to have your magnifying glass ready! Some idiot set the 
whole
> > thing in 4 or 6-point type. Talk about trying to read the fine 
print!
> >
> > I share you skepticism on this one. Is it perhaps a numbers game
> > where the 16-bit A/D converter cost very little but let's them 
make
> > more outrageous claims?
> >
> > Martin
> 
> I believe they are not being honest here, or just plain don't know 
what they
> are talking about.  There is a little link to a URL that shows 14 
bit vs 16
> bit.  It claims 16 bits "resolves the image with greater 
fidelity...".  That
> is a physically impossibility.  First off, the shadow detail they 
show is
> not near real shadow detail!  It's mid range detail.
> 
> 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.
> 
> I believe the curve they show is erroneous.  All, both 16 and 14 bit
> values/steps, would be in the MIDDLE of the curve, and they 
wouldn't be
> steps, they would be dots.  Pixel depth doesn't have "steps", they 
are ratio
> values and more bits just give you larger numbers, the "steps" 
between the
> numbers is exactly the same.  Steps happen with PPI, NOT with pixel 
depth.
> This is very very misleading.
> 
> Click on "16-bit A/D..." on the Pro page, then click on "16-bit vs.
> 14-bit...".  Take a look and see if you agree.  This really irks 
me.  I
> believe it's totally outrageous.

Austin,

Don't you just love graphs that have no labels on the axis not to 
mention no units. Wouldn't want to confuse the poor consumer with too 
much information.

The only way I can look at it that might make sense is if the x-axis 
is distance across the image and the y-axis is a varying intensity of 
the R channel. Given that if you go from 0 to 100% intensity 14-bit 
would represent that with 16,384 levels and 16-bit would use 65,536, 
but we cannot distinguish between 16,384 shades of red or gray much 
less 65,536 nor can the film, so it all seems meaningless to the end 
result.

There is a relationship between bit depth and the noise floor if I 
understand it correctly. I did notice in comparing 12-bit to 14-bit 
RGB slide scans on a Polaroid SprintScan 4000 to a SprintScan 120 
that there was a decrease in noise in dark portions of the slides. 
This was an improvement but not an overwhelming one. With B&W 
negative scans from the two I don't see any noticeable difference in 
the final prints.

Assuming you did go to 16 or 18-bits in a 24-bit or larger space 
would you see a significant reduction in noise or is it a case of 
getting smaller and smaller improvements with each increase in bit 
depth?

Looking at three factors in a scanner, optical path sharpness, pixels 
per inch and bit depth, which is going to be the biggest contributor 
to a good scan? Assuming that all three are at a least an adequate 
level, which one would you be most interested in improving first, 
then second?

Martin

> Click on "16-bit A/D..." on the Pro page, then click on "16-bit vs.
> 14-bit...".  Take a look and see if you agree.  This really irks me.  I
> believe it's totally outrageous.

There's a little disclaimer at the bottom of the page that says "Images are
simulated".  In otherwords, the dramatic differences they're showing are BS.

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

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

> > Click on "16-bit A/D..." on the Pro page, then click on "16-bit vs.
> > 14-bit...".  Take a look and see if you agree.  This really irks me.  I
> > believe it's totally outrageous.
>
> There's a little disclaimer at the bottom of the page that says
> "Images are
> simulated".  In otherwords, the dramatic differences they're
> showing are BS.

Yes, on a different page than the images I was talking about!  Amazing!
Thanks for pointing that out.

> The only way I can look at it that might make sense is if the x-axis
> is distance across the image and the y-axis is a varying intensity of
> the R channel. Given that if you go from 0 to 100% intensity 14-bit
> would represent that with 16,384 levels and 16-bit would use 65,536,
> but we cannot distinguish between 16,384 shades of red or gray much
> less 65,536 nor can the film, so it all seems meaningless to the end
> result.

Yes, but the difference would only be 1/2 of what they show it is...since
it's +/-.

> Assuming you did go to 16 or 18-bits in a 24-bit or larger space
> would you see a significant reduction in noise or is it a case of
> getting smaller and smaller improvements with each increase in bit
> depth?
>
> Looking at three factors in a scanner, optical path sharpness, pixels
> per inch and bit depth, which is going to be the biggest contributor
> to a good scan? Assuming that all three are at a least an adequate
> level, which one would you be most interested in improving first,
> then second?

Yes, this is actually a pet peeve of mine.  The current way CCDs/ADs etc.
work, is the value out of the A/D is basically the same as an INTEGER
density ratio value.  Given that, more bits (than 14) don't do you any good,
especially for B&W...   Show me a chrome that has near the dynamic range of
16 bits!  I know of no chromes that have a dynamic range of 4.8!  May be
they exist, but I've never seen them!

There's something more in this soup,because even with the dynamic range of a
chrome not being more than 3.6,a scanner about 4.3DR as the new Nikon 4000
or cylinder scan better than a 3.6 one...

>
> Also, 16 bits is entirely unnecessary to capture image data at, since no
> film you will be scanning can have a dynamic range of 4.8!
>

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

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> 
wrote:
(snip)
> 
> 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).

Todd, Austin,

Let's see if I can muddy the waters here. Any time you make any 
adjustment in any size space you change the data set. If you stretch 
it out then you have holes that ultimately will be filled by 
interpolated data and if you compress it then values are rounded off. 
In either case, in any size bit space the "new" data set after 
manipulation is determined by whoever wrote the software to handle 
the manipulation.

How the histogram looks before and after may or may not have anything 
to do with what actually happened to the data but only shows how the 
software calculated the data so that it can be represented in an 8-
bit histogram.

If you stretch out a 14-bit set of data to match the end points of a 
16-bit working space there are holes in the data set. It is combed. 
But the software that draws the 8-bit histogram does not see any 
holes because stretching 16384 values out over a 65536 value range is 
going to leave a lot of empty values. But the software that 
calculates the 8-bit histogram representation of this still has 16384 
values to spread over 256 values and does not show the holes.

Think about how long it can take Photoshop to calculate a 256 value 
histogram. Think about how long it would take do display a 65636 
histogram. We would never look at it.

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

Well the end result is at best 4 or 6 shades of gray ink. If each is 
capable of 256 shades of gray, which I am willing to believe after 
looking at the mono-ink prints. Then the quad printers give you 1024 
shades of gray and the hex printers 1536 if everything works 
perfectly which it doesn't. Tops you probably need 1024 (10-bit) 
shades of gray and can get away with less. So at 14-bit you are going 
to dump about 15,000 of the 16,384 values. At 14-bit you have data to 
burn big time. (Assuming that the scanner could really pull 16,384 
shades off the film.) Going to 16-bit means you get to throw away 
64,000 values. In the end if 

What I don't understand is how far above 10-bit you need to go to 
have an acceptably low noise level? What benefit, if any, is there in 
the signal to noise ratio in going from a 14 to 16-bit A/D converter?

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

If you spread the full 14-bit data over 16-bits 3 out of 4 values 
will be zero. Fingers of death big time but the software maps it to 
256 values throwing away all the holes and 16128 values as well 
making it look perfectly smooth and unbroken.

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

This is where the much-praised Silverfast is using trickery in its 
raw scan mode. In its raw scan mode you can set the "gamma" and 
the "brightness" giving the impression you are controlling the 
scanner but in reality you are just telling it to manipulate the data 
on the fly and it is no longer giving you a raw scan. The end result 
is no different than say Polacolor Insight which allows you to select 
levels and curves prior to the raw scan, makes the raw scan and then 
the software applies the changes as an action to the raw file after 
the scan. The only difference is the Silverfast method is faster but 
with the Polacolor method you can preview it. Both are very useful in 
that you wind up with a data in 16-bit space that is closer to the 
center of the space and not so bunched up making fine tuning easier 
but the end result must be the same as taking it into Photoshop and 
doing multiple Levels and Curves in 16-bit mode.

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

Or the range of the film and scanner combined is smaller than the 
space it is mapping to.

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

If the range of the film stays fixed and the bit depth goes up the 
width of the raw scan shouldn't change. If you decrease the bit depth 
to less than the range of the film then the raw scan would get 
narrower?

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

Probably wouldn't make use any better print makers but what we need 
is a 16-bit histogram utility (with zoom) and very, very, very fast 
computers to run it on. <<g>>  

Martin

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

No.  It means that you need to have headroom within the space to make
adjustments.

> 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 don't know what you mean.  Be careful when you say "16 bit data".  There
are different types of 16 bit data.  One where the data was expanded into a
16 bit range, such as you do with 12/14 bit data, by seting the setpoints,
then the data gets expanded into the entire 16 bit range...and once
expanded, has holes between every data value.  Second, REAL 16 bits out of
the A/D, with no headroom, with no holes between any of the image data. And
third, the actual raw data from the scanner, typically with no holes in the
actual image data values

> I'd be far more fearful of an image getting degraded, or a histogram
> combing,

Taking 12/14 bit data and putting it into a 16 bit data will comb a 16 bit
histogram...many values between data points have no pixels that have that
value.  That is fine, if your goal is ultimately 8 bit data...as only the
top 8 bits are used, and the 8 bit data won't be "combed".

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

No, sorry, I don't.  I'm merely explaining how things work...I don't see
that as an argument.

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

I don't see anything as being two sides of an argument.  It all depends on
what your "goal" is.  There's nothing to "trap", and I don't understand your
point.  As I said, I am only stating how things work...so I don't understand
how you could argue with how they work.  Perhaps not understand them...or
perhaps my explanations are bad...but I'm really only relaying my direct
knowledge of how this works.

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

It depends on what you mean by 16 bit data, and what your goal is.  As I
keep saying, you need headroom, and 16 bit data in a 16 bit space gives you
NO headroom.

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

No, I didn't say it does.  It CAN determine one or both endpoints mind you,
but not always.

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

No, that is not what I said.  As I said above, bit depth CAN determine one
or both of the endpoints.  Also, as bit depth increases the distribution of
the SAME IMAGE does NOT give more tones in the raw scan.  That is what is
misunderstood.  IF and only IF the image is up against one side of the bit
depth, will higher bit depth give you more tones.

These numbers aren't hard, but they are just an example.  Say you have a B&W
image that gives you a range of 1:1 to 1:100 tones (dynamic range of 2.0).
In the 16 bit scanner, the data will only occupy a range of 100 values out
of 65k, and in the 8 bit scanner it will occupy a range of 100 values out of
256.

The point is, bit depth does NOT mean you get more tones out of the same
image.  It ONLY means you CAN get more tones on ONE end of the scale (dark
side) IF and ONLY IF the image you are scanning has detail in that "area".

> We are talking
> about how it gets mapped to the histogram.

I don't understand the question/issue.  There is no mapping.  Mapping means
values get changed.  No values are changed in a histogram.  The histogram is
nothing more than a graphical representation of a count of the values of the
upper 8 bits of the data in the image buffer.

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

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.

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

I have no idea what your asking here, sorry.

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

Not at all.  It fits exactly with everything I've been saying.  You're
missing something, and I just don't know what it is you're missing.

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

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.

> But, the logic presented immediately above would suggest the
> opposite;

Not trying to be snyde, but misunderstanding would suggest the opposite.
You're not understanding what density ratio values are, and that they are
not dependant on bit depth, unless you are clipping.

> So where you started the conversation with the premise that a 16-bit raw
> capture would by default fill more of the histogram

ONLY if the image being captured HAD the dynamic range to do so.

> you seem to
> be implying
> at the end that as bit depth goes up, so does DR

As bit depth goes up, you can represent more dynamic range...but unless the
image is clipping, more bits will not give you more DR.  You will only get
more DR by adding more bits if you are clipping.

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

No.  As I said above, if you have an image that fits in 10 bits, no matter
how many bits your scanner is, you're going to get the exact same data
values from the scanner...and the histogram will be exactly the same.  It's
that "integer density ratio value" thing again ;-)  You've GOT to get that
understanding down for this all to make sense.

I need to ask you a favor.  Can you please try to cut this down to fewer
questions/points?  I just don't have time (near an hour!) to respond ...

> If the range of the film stays fixed and the bit depth goes up the
> width of the raw scan shouldn't change. If you decrease the bit depth
> to less than the range of the film then the raw scan would get
> narrower?

Martin, 

I believe this is confusing because Austin has been trying for a long time
to make dynamic range a function of bit depth, and it just doesn't work that
way. Allow me to quote Andrew Rodney (digitaldog.com):

"Dynamic range has nothing to do with bit depth! They are completely
different spec¹s. You can have a scanner with 16 bits per color and a
dynamic range of 3.3 and you can have a scanner with 12 bits and a dynamic
range of 3.8. Bit depth is the number of steps. Dynamic range is the height
of the star case. You can have a staircase that¹s 20 feet high and have 40
steps. You can have a staircase that¹s 30 feet high and have 30 steps."

That's what the Minolta link that irked Austin was trying to establish. Bit
depth is how many tones are used within the dynamic range, not how many
tones it takes to give you dynamic range.

http://www.dimage.minolta.com/multipro/p01_02.html

Of course someone will mention A/D converters and I will get lost, but
perhaps someone else will handle that part for me.

Todd

> Any time you make any
> adjustment in any size space you change the data set. If you stretch
> it out then you have holes that ultimately will be filled by
> interpolated data and if you compress it then values are rounded off.

I believe that's not really right.  The "holes" in the values don't get
interpolated...the holes are just left as holes.  Think about it, what
pixels are you going to assign the interpolated values to?  You'd have to
make up new pixels in the image!

> If the range of the film stays fixed and the bit depth goes up the
> width of the raw scan shouldn't change.

BINGO!  Unless you were clipping...

> > If the range of the film stays fixed and the bit depth goes up the
> > width of the raw scan shouldn't change. If you decrease the bit depth
> > to less than the range of the film then the raw scan would get
> > narrower?
>
> Martin,
>
> I believe this is confusing because Austin has been trying for a long time
> to make dynamic range a function of bit depth

This is a fact. Please.  Bit depth IS a limiting factor of dynamic range in
the way current scanners are designed.

> and it just
> doesn't work that
> way.

Well, yes it does.  I'll bet you anything you want on it!  It does not HAVE
to work that way, bit it IS the way designers have chosen to design
scanners.

> Allow me to quote Andrew Rodney (digitaldog.com):
>
> "Dynamic range has nothing to do with bit depth!

He is right, and I have said this too, 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.

> They are completely
> different spec\ufffds. You can have a scanner with 16 bits per color and a
> dynamic range of 3.3 and you can have a scanner with 12 bits and a dynamic
> range of 3.8. 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 talking about theoretically, and I have stated this exact case too
time and time again, but is had nothing to do with the reality of how
scanners ARE designed and how they work.  A two bit scanner, though it could
REPRESENT a dynamic range of say, 4.0, could only give you line are!  You
would get NO tonality.

This is a typical thing that someone, first exploring how a scanner works,
brings up...as evidenced by countless explanations on the filmscanner news
group...  It is an EXCELLENT venue to discuss how scanners work, and
typically indicates that the person is understanding something...but this is
also a hurdle...and it seems you're hung up on this hurdle.

Wayne Fulton (www.scantips.com) and I had a very good discussion on this a
while ago, and he updated his web site based on some "issues" I had with his
explanation of this.  You might want to poke around there and read, I
believe it was tip 14...

> That's what the Minolta link that irked Austin was trying to
> establish.

That's why it's WRONG!

> Bit
> depth is how many tones are used within the dynamic range, not how many
> tones it takes to give you dynamic range.

No, that isn't how scanners are designed.  Bit depth does nothing but expand
the tonal capture ability into the dark regions...it does NOT give more
tones within the same dynamic range...for the same image (unless the image
is clipping).

> Allow me to quote Andrew Rodney (digitaldog.com):

Where did you get that quote from?  I tried www.digitaldog.com, and it's a
web site about dogs...real dogs...as in woof, woof ;-)

on 9/26/01 1:41 AM, Austin Franklin wrote:

>> Allow me to quote Andrew Rodney (digitaldog.com):
> 
> Where did you get that quote from?  I tried www.digitaldog.com, and it's a
> web site about dogs...real dogs...as in woof, woof ;-)

Sorry

His site is www.digitaldog.net, but I got it from a discussion on another
list. Perhaps I'll get you the entirety of the post at a later point.
Wearing down now....;-)

Todd

It wouldn't take any longer to calculate a 16 bit histogram. To calculate
the distribution of pixels values in an image you have to count every pixel.
The number of pixels to count is the same whether you're dividing the
distribution into 256 buckets or 64K.

-Jason

-----Original Message-----
From: Martin Wesley [mailto:mwesley250@...]
Sent: Wednesday, September 26, 2001 12:28 AM
To: DigitalBlackandWhiteThePrint@yahoogroups.com
Subject: Re: [Digital BW] Bit depth, was Minolta DiMAGE Scan Multi PRO

Think about how long it can take Photoshop to calculate a 256 value
histogram. Think about how long it would take do display a 65636
histogram. We would never look at it.

...

Probably wouldn't make use any better print makers but what we need
is a 16-bit histogram utility (with zoom) and very, very, very fast
computers to run it on. <<g>>

> It wouldn't take any longer to calculate a 16 bit histogram. To calculate
> the distribution of pixels values in an image you have to count
> every pixel.
> The number of pixels to count is the same whether you're dividing the
> distribution into 256 buckets or 64K.

I would agree, especially if you just index your counter off the
value...then all you are taking up is more memory, but no more processing.
The counters would basically have to be the same size anyway, since the
number of pixels determines the counter size requirement, not the bit depth.

Austin,
 
let's see if I got it right: the DR tells us how deep the scanner can see
into the film, and so higher DR values mean higher ranges of the  analog
signal strength we get from the CCD. On the other hand, bit depth is the
number of bits that the analog to digital converter (I suppose there must be
one somewhere) uses to map that signal. Given that the analog signal is
continuous, any number of bits we pick will be a limiting factor in that it
will not represent all the analog values (theoretically infinite), but this
is not a problem due to human eye limitations. We have a real limiting
factor when we use a number of bits which is not sufficient to represent the
ratio between the highest and the lowest analog value (which I think is the
actual definition for DR): so if we have an analog signal ranging from 1 to
10 (silly numbers, I know) and only use 3 bits (0-7), we lose some
information, whereas if we use 4 (0-15) we don't. Is this correct?
I don't know how scanners are designed, but I guess that once you have an
analog signal from the CCD (whose range defines the scanner's DR), you could
use different A-D converters: therefore the bit depth (defined as the number
of bits we translate the signal into), would be independent from the DR.
Does this make sense?
 
Alex

-----Original Message-----
From: Austin Franklin [mailto:darkroom@...]
Sent: mercoledì 26 settembre 2001 07.39
To: DigitalBlackandWhiteThePrint@yahoogroups.com
Subject: RE: [Digital BW] Bit depth, was Minolta DiMAGE Scan Multi PRO



> > If the range of the film stays fixed and the bit depth goes up the
> > width of the raw scan shouldn't change. If you decrease the bit depth
> > to less than the range of the film then the raw scan would get
> > narrower?
>
> Martin,
>
> I believe this is confusing because Austin has been trying for a long time
> to make dynamic range a function of bit depth

This is a fact. Please.  Bit depth IS a limiting factor of dynamic range in
the way current scanners are designed.

> Allow me to quote Andrew Rodney (digitaldog.com):
>
> "Dynamic range has nothing to do with bit depth!

He is right, and I have said this too, 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.

> They are completely
> different spec¹s. You can have a scanner with 16 bits per color and a
> dynamic range of 3.3 and you can have a scanner with 12 bits and a dynamic
> range of 3.8. Bit depth is the number of steps. Dynamic range is
> the height
> of the star case. You can have a staircase that¹s 20 feet high and have 40
> steps. You can have a staircase that¹s 30 feet high and have 30 steps."

He is talking about theoretically, and I have stated this exact case too
time and time again, but is had nothing to do with the reality of how
scanners ARE designed and how they work.  A two bit scanner, though it could
REPRESENT a dynamic range of say, 4.0, could only give you line are!  You
would get NO tonality.




[Non-text portions of this message have been removed]

> let's see if I got it right: the DR tells us how deep the scanner can see
> into the film,

A higher DR gives that, yes.

> and so higher DR values mean higher ranges of the  analog
> signal strength we get from the CCD.

No.  Typically, the input to the A/D will be +- 3 volts, for a 6V total
swing.  Then each bit represents N millivolts.  For a 10 bit A/D, each bit
is 0.005859375 mv.  For a 14 bit scanner, each bit is 0.0003662109375
mv....BUT...the scale is now shifted, since the CCD is more "sensitive".
Remember, no matter how many bits you have, 2 is always twice 1...and we are
dealing with integer density ratio values.

> On the other hand, bit depth is the
> number of bits that the analog to digital converter (I suppose
> there must be
> one somewhere) uses to map that signal.

As my arithmetic shows above...

> Given that the analog signal is
> continuous, any number of bits we pick will be a limiting factor
> in that it
> will not represent all the analog values (theoretically
> infinite),

I don't know quite what you mean here...we only measure relative values, as
in 2 times, 3 times, 4 times....1000 times...only integer ratio values.

> but this
> is not a problem due to human eye limitations. We have a real limiting
> factor when we use a number of bits which is not sufficient to
> represent the
> ratio between the highest and the lowest analog value (which I
> think is the
> actual definition for DR)

I believe all three statements there are correct.

> so if we have an analog signal ranging
> from 1 to
> 10 (silly numbers, I know) and only use 3 bits (0-7), we lose some
> information, whereas if we use 4 (0-15) we don't. Is this correct?

No, we always lose information...but...what you need to accommodate with the
number of bits is just how small a signal you want to be able to handle...in
other words, that voltage of 1-10 represents a dynamic range (which is an
integer ratio value)...and the number of bits must accommodate that.

> I don't know how scanners are designed, but I guess that once you have an
> analog signal from the CCD (whose range defines the scanner's
> DR), you could
> use different A-D converters: therefore the bit depth (defined as
> the number
> of bits we translate the signal into), would be independent from the DR.
> Does this make sense?

You could design it anyway you wanted...but what you would find, is the
methodology that is currently used, not only make sense to do given the way
CCDs work, and A/Ds work, but it just so happens to fit the integer density
ratio value very very nicely, which is what we need to represent in our data
values.

I am glad to see that others finally got involved in the old bit depth 
discussion Austin and I have been having!
I'll address the issues below, \/

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> 
> > > If the range of the film stays fixed and the bit depth goes up the
> > > width of the raw scan shouldn't change. If you decrease the bit depth
> > > to less than the range of the film then the raw scan would get
> > > narrower?
> >
> > Martin,
> >
> > I believe this is confusing because Austin has been trying for a long time
> > to make dynamic range a function of bit depth
> 
> This is a fact. Please.  Bit depth IS a limiting factor of dynamic range in
> the way current scanners are designed.

Austin, here you are saying one thing, below you say another. Ill point 
it out later.

> > Allow me to quote Andrew Rodney (digitaldog.com):
> >
> > "Dynamic range has nothing to do with bit depth!
> 
> He is right, and I have said this too, 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.
> 
> > They are completely
> > different spec1s. You can have a scanner with 16 bits per color and a
> > dynamic range of 3.3 and you can have a scanner with 12 bits and a dynamic
> > range of 3.8. Bit depth is the number of steps. Dynamic range is
> > the height
> > of the star case. You can have a staircase that1s 20 feet high and have 40
> > steps. You can have a staircase that1s 30 feet high and have 30 steps."
> 
> He is talking about theoretically, and I have stated this exact case too
> time and time again, but is had nothing to do with the reality of how
> scanners ARE designed and how they work.  A two bit scanner, though it could
> REPRESENT a dynamic range of say, 4.0, could only give you line are!  You
> would get NO tonality.

Here it is.
In this case (and many less extreme ones) how is bit depth the limiting 
factor?

All scanners used to be only 8bit, but they still captured film with 
the same d-range that the film we scan today has.  But then higher bit 
scanners came along and that allowed us to capture more tones in those 
same negatives.


> > Bit
> > depth is how many tones are used within the dynamic range, not how many
> > tones it takes to give you dynamic range.
> 
> No, that isn't how scanners are designed.  Bit depth does nothing but expand
> the tonal capture ability into the dark regions...it does NOT give more
> tones within the same dynamic range...for the same image (unless the image
> is clipping).

It does if you are talking about the old scanners vs the new. There is 
no reason to limit ourselves by saying todays scanners give us more 
than we could ever use. Film is analog, scanner makers should come out 
with a scanner that captures the full 16bits with a density range of 
todays 14bit scanners. Which would entail differentiating more tones 
rather than the ability to capture a more dense negative. I am not 
saying it is possible, but I would think someone would be able to 
figure it out. Nobody has yet because it hasn't been necessary, 10bits 
of smooth information is more than enough for any of todays output 
devices. But 16 would allow us more wiggle room for playing with the 
curves, etc...

I have taken issue with the term dynamic range. Scanner companies use 
it to mean their scanners capture more information. Which it did when 
they first started using it (comparing them to the earliest models) but 
now it only hurts the amount of information you can capture. If a 
scanner could really capture 4.5 density-range in a 12 bit space, then 
a normal negative's range would have to fit into a much smaller space 
than 12 bits. Which would mean that, with that negative, that scanner 
would actually capture less information than a 3.3 d-range, 12 bit, 
scanner.  Does this make sense?

That is one of the reasons I think they should have called it density 
range. And left the term dynamic range to something more along the 
lines of bit depth.


-mikeH
toomanyartists.com

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
> > and so higher DR values mean higher ranges of the  analog
> > signal strength we get from the CCD.
> 
> No.  Typically, the input to the A/D will be +- 3 volts, for a 6V total
> swing.  Then each bit represents N millivolts.  For a 10 bit A/D, each bit
> is 0.005859375 mv.  For a 14 bit scanner, each bit is 0.0003662109375
> mv....BUT...the scale is now shifted, since the CCD is more "sensitive".
> Remember, no matter how many bits you have, 2 is always twice 1...and we are
> dealing with integer density ratio values.
> 
> > On the other hand, bit depth is the
> > number of bits that the analog to digital converter (I suppose
> > there must be
> > one somewhere) uses to map that signal.
> 
> As my arithmetic shows above...
> 
> > Given that the analog signal is
> > continuous, any number of bits we pick will be a limiting factor
> > in that it
> > will not represent all the analog values (theoretically
> > infinite),
> 
> I don't know quite what you mean here...we only measure relative values, as
> in 2 times, 3 times, 4 times....1000 times...only integer ratio values.

What he is saying is that the CCD's voltage is analog and therefore 
infinite.

Why can't, using your above example, someone make a scanner using the 
more sensitive 14bit A/D converter on the less sensitive CCD from the 
10bit scanner. (I assume you mean sensitive as in the ability of the 
CCD to judge brighter or darker tones)  This should allow more tonal 
information over the same Density Range.

-mikeH

Austin,

I'm going to take a different approach here. The point/counter-point has got
my head spinning. We've spanned too many posts for me to put it all
together. Clearly you possess an understanding of this I don't, but often,
probably due to the sprawling nature of these discussions, you appear to me
to be contradicting yourself. Perhaps you don't but there are too many
little pieces of info, spanning too many posts, for me to tie it together.

BTW, when I accused you of taking sides of an argument I only meant that we
were each arguing A CASE, in the dispassionate sense. I never felt either of
us were being quarrelsome.

I'm starting from scratch. Below is a draft of a question I will post
elsewhere . I hope it will help you see what I'm left with from our
discussion. I'm thinking we might both benefit from seeing how the topic is
addressed from other's perspective. If you'd like to discuss any of it's
points that'd be fine, or perhaps you could just help me craft it better as
a question.

********

What determines where the endpoints of a RAW highbit scans (no tonal
manipulation by the driver or image editor, and no profile assigned) get
written to Photoshop's histogram in 16-bit mode? In other words, why does it
appear to be of such low dynamic range, and bunched into the dark end of the
histogram? If you scan a chrome which has a dynamic range of 3.7 on a
scanner which has a true dynamic range of 3.7, why wouldn't the data span
the histogram? It would still be bunched up.

This is a cerebral pursuit for me, I just want to be sure I'm
conceptualizing this properly. Often people say "it's because you haven't
set your end points, or corrected it's gamma". Yes, I understand about
toning the data, but my question is, what determines where that RAW data
will sit in the histogram prior to toning?

I've heard a couple of different explanations, but they are contradictory or
incomplete. 

One premise suggests that as the bit depth of the capture device increases
so will it's scans occupy a larger portion of the histogram. IOW, a 10-bit
capture would contain less tones than a 14-bit capture, and thus would
occupy a smaller portion of the histogram. This suggests that dynamic range
is directly a function of bit depth, which I don't believe to be the case
(though someone always throws in a snippet about A/D converters, which only
confuses me).

Another theory proposes exactly the opposite of that, though it still tries
to tie dynamic range to bit depth. It suggests that the reason the tones are
compressed is that it is a representation of how the dynamic range of the
capture device is greater than that of the film. In this scenario, as the
bit depth of the capture device increases, so will it's dynamic range, and
as the dynamic range of the scanner exceeds that of the film, this will be
represented by "empty space" in the histogram -- IOW, empty space reveals
unutilized dynamic range of the scanner. Again, I don't buy this because
it's still trying to tie DR to bit depth.

Yet another suggests it is because scanners write out raw data in linear
gamma and the histogram is representing a working space of a higher gamma.
But gamma is a function of the distribution of the tones inside of the
endpoints, not where the endpoints lie, no? Furthermore, if I convert the
file to a 1.0 gamma working space, the histogram remains essentially
unchanged.

So what is it? Just why does the raw data appear so compressed, and how is
it's shape within the histogram affected by the bit depth of the capture
device?

Todd Flashner

> > This is a fact. Please.  Bit depth IS a limiting factor of
> dynamic range in
> > the way current scanners are designed.
>
> Austin, here you are saying one thing, below you say another. Ill point
> it out later.

I didn't see you point this out anywhere in your post here...  I just don't
understand why we're discussing this, it's just a plain fact when
representing INTEGER DENSITY RATIO VALUES (which is how scanners work), the
number of bits are the limiting factor of the dynamic range.  If you are
representing some other "values", then the number of bits may or may not be
the limiting factor.

> Here it is.
> In this case (and many less extreme ones) how is bit depth the limiting
> factor?
>
> All scanners used to be only 8bit, but they still captured film with
> the same d-range that the film we scan today has.

Show me one example of a scanner that used 8 bits, and captured a dynamic
range of 3.2 or greater.  They may have RETURNED 8 bits of data, after the
setpoints and curves were done in the scanner driver...but the actual A/D
output was much higher.

> > > Bit
> > > depth is how many tones are used within the dynamic range,
> not how many
> > > tones it takes to give you dynamic range.
> >
> > No, that isn't how scanners are designed.  Bit depth does
> nothing but expand
> > the tonal capture ability into the dark regions...it does NOT give more
> > tones within the same dynamic range...for the same image
> (unless the image
> > is clipping).
>
> It does if you are talking about the old scanners vs the new.

Show me an "old" scanner that does as you claim.

> There is
> no reason to limit ourselves by saying todays scanners give us more
> than we could ever use. Film is analog, scanner makers should come out
> with a scanner that captures the full 16bits with a density range of
> todays 14bit scanners. Which would entail differentiating more tones
> rather than the ability to capture a more dense negative.

That is not necessarily true.  Because it's analog, doesn't mean it's
infinite.  You're forgetting a little thing called noise.  Noise will limit
the number of tones you can get.

> I am not
> saying it is possible, but I would think someone would be able to
> figure it out.   Nobody has yet because it hasn't been necessary...

It IS possible, I've already "figured it out", but, as you say, it just
isn't necessary.  It's actually very simple.  The data out of the A/D does
not represent integer density ratio values, but fractional density ratio
values.

> I have taken issue with the term dynamic range. Scanner companies use
> it to mean their scanners capture more information.

The term "dynamic range" has been around long before scanners, and has a
fixed meaning in the engineering community.  Because it is
misrepresented/misunderstood by some does not change the definition of it.

> If a
> scanner could really capture 4.5 density-range in a 12 bit space,

As I've said, you CAN capture (if you design a scanner to do so) any density
range into 2 or more bits...BUT...the values you get are NOT integer density
ratio values.

> then
> a normal negative's range would have to fit into a much smaller space
> than 12 bits.

For that particular scanner, IF that scanner was designed to operate that
way, that could be true.  Perhaps the scanner could expand the data to fit
the entire 12 bits.

> Which would mean that, with that negative, that scanner
> would actually capture less information than a 3.3 d-range, 12 bit,
> scanner.  Does this make sense?

Only if the scanner was designed to operate that way.

> That is one of the reasons I think they should have called it density
> range. And left the term dynamic range to something more along the
> lines of bit depth.

But they are both the exact same thing.  Density is a ratio, just like
dynamic range is.

> > I don't know quite what you mean here...we only measure
> relative values, as
> > in 2 times, 3 times, 4 times....1000 times...only integer ratio values.
>
> What he is saying is that the CCD's voltage is analog and therefore
> infinite.

That's a misnomer.  Analog is not infinite.  It is limited by noise, and
that is what dynamic range is...the largest signal over the noise.  If you
have a maximum 6V signal, and your noise level is .003 volts, you have a
dynamic range of 3.3.

> Why can't, using your above example, someone make a scanner using the
> more sensitive 14bit A/D converter on the less sensitive CCD from the
> 10bit scanner. (I assume you mean sensitive as in the ability of the
> CCD to judge brighter or darker tones)  This should allow more tonal
> information over the same Density Range.

Nope.  The values you get out of the CCD/AD are RELATIVE.  2 is twice as
bright as 1, and 4 is twice as bright as 2, no matter what CCD or A/D you
use.

You need to have a more sensitive CCD to give you less noise...hence the
need for more bits to increase the dynamic range so you can read the smaller
signals that are less than 10 bits can represent...which is why you get an
increase in the shadow detail (for chromes).

Keep in mind, the analog output of the CCD, no matter what it's noise, is
matched (voltage wise and/or current wise) to the input range of the A/D
through analog circuitry.  The A/D (as in number of bits) is chosen (as well
as the analog interface circuitry) to match the CCD...one typically doesn't
use 24 bit A/Ds when the noise level is only good for 10 bits of that 24!
Even if you did use a 24 bit A/D, only 10 bits of it would be "useful",
because of the noise.

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> > > This is a fact. Please.  Bit depth IS a limiting factor of
> > dynamic range in
> > > the way current scanners are designed.
> >
> > Austin, here you are saying one thing, below you say another. Ill point
> > it out later.
> 
> I didn't see you point this out anywhere in your post here...  I just don't
> understand why we're discussing this, it's just a plain fact when
> representing INTEGER DENSITY RATIO VALUES (which is how scanners work), the
> number of bits are the limiting factor of the dynamic range.  If you are
> representing some other "values", then the number of bits may or may not be
> the limiting factor.
> 

Never mind about that, I guess when you said "the way current scanners 
are designed" you were correct.

> > Here it is.
> > In this case (and many less extreme ones) how is bit depth the limiting
> > factor?
> >
> > All scanners used to be only 8bit, but they still captured film with
> > the same d-range that the film we scan today has.
> 
> Show me one example of a scanner that used 8 bits, and captured a dynamic
> range of 3.2 or greater.  They may have RETURNED 8 bits of data, after the
> setpoints and curves were done in the scanner driver...but the actual A/D
> output was much higher.

I don't know about 3.2 drange, but how about the Microtek 300Z or the 
Apple One Scanner.


> > > > Bit
> > > > depth is how many tones are used within the dynamic range,
> > not how many
> > > > tones it takes to give you dynamic range.
> > >
> > > No, that isn't how scanners are designed.  Bit depth does
> > nothing but expand
> > > the tonal capture ability into the dark regions...it does NOT give more
> > > tones within the same dynamic range...for the same image
> > (unless the image
> > > is clipping).
> >
> > It does if you are talking about the old scanners vs the new.
> 
> Show me an "old" scanner that does as you claim.
> 
> > There is
> > no reason to limit ourselves by saying todays scanners give us more
> > than we could ever use. Film is analog, scanner makers should come out
> > with a scanner that captures the full 16bits with a density range of
> > todays 14bit scanners. Which would entail differentiating more tones
> > rather than the ability to capture a more dense negative.
> 
> That is not necessarily true.  Because it's analog, doesn't mean it's
> infinite.  You're forgetting a little thing called noise.  Noise will limit
> the number of tones you can get.
> 
> > I am not
> > saying it is possible, but I would think someone would be able to
> > figure it out.   Nobody has yet because it hasn't been necessary...
> 
> It IS possible, I've already "figured it out", but, as you say, it just
> isn't necessary.  It's actually very simple.  The data out of the A/D does
> not represent integer density ratio values, but fractional density ratio
> values.

Why do they have to be integers?


> > I have taken issue with the term dynamic range. Scanner companies use
> > it to mean their scanners capture more information.
> 
> The term "dynamic range" has been around long before scanners, and has a
> fixed meaning in the engineering community.  Because it is
> misrepresented/misunderstood by some does not change the definition of it.

The dynamic range of sound does not relate to the intensity (volume)

> > If a
> > scanner could really capture 4.5 density-range in a 12 bit space,
> 
> As I've said, you CAN capture (if you design a scanner to do so) any density
> range into 2 or more bits...BUT...the values you get are NOT integer density
> ratio values.

Who says they have to be integers?

> > then
> > a normal negative's range would have to fit into a much smaller space
> > than 12 bits.
> 
> For that particular scanner, IF that scanner was designed to operate that
> way, that could be true.  Perhaps the scanner could expand the data to fit
> the entire 12 bits.
> 

Wouldn't this be something we would want? Does this throw off the look 
of the image in some way (emphasizing certain tones more than others or 
something)? I am just trying to think of why this isn't done other than 
to make a scanners specs look better by saying it can capture something 
ridiculous like 4.5

> > Which would mean that, with that negative, that scanner
> > would actually capture less information than a 3.3 d-range, 12 bit,
> > scanner.  Does this make sense?
> 
> Only if the scanner was designed to operate that way.

I am thinking that this would be true with the scanners on the market 
now, yes?

> 
> > That is one of the reasons I think they should have called it density
> > range. And left the term dynamic range to something more along the
> > lines of bit depth.
> 
> But they are both the exact same thing.  Density is a ratio, just like
> dynamic range is.

Yes and no, density is a ratio compared to the darkest one can see. 
Dynamic range is a ratio compared to the sublest change one can see.
Because of the way scanners are made, they end up being the same.

-mikeH

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> > > I don't know quite what you mean here...we only measure
> > relative values, as
> > > in 2 times, 3 times, 4 times....1000 times...only integer ratio values.
> >
> > What he is saying is that the CCD's voltage is analog and therefore
> > infinite.
> 
> That's a misnomer.  Analog is not infinite.  It is limited by noise, and
> that is what dynamic range is...the largest signal over the noise.  If you
> have a maximum 6V signal, and your noise level is .003 volts, you have a
> dynamic range of 3.3.

okay, well why don't you make a CCD with more volts and less noise?
You can't put aside our theoretical arguments by saying a CCD has 
noise.

> > Why can't, using your above example, someone make a scanner using the
> > more sensitive 14bit A/D converter on the less sensitive CCD from the
> > 10bit scanner. (I assume you mean sensitive as in the ability of the
> > CCD to judge brighter or darker tones)  This should allow more tonal
> > information over the same Density Range.
> 
> Nope.  The values you get out of the CCD/AD are RELATIVE.  2 is twice as
> bright as 1, and 4 is twice as bright as 2, no matter what CCD or A/D you
> use.

Why does it have to be that way though?

> 
> You need to have a more sensitive CCD to give you less noise...hence the
> need for more bits to increase the dynamic range so you can read the smaller
> signals that are less than 10 bits can represent...which is why you get an
> increase in the shadow detail (for chromes).
> 
> Keep in mind, the analog output of the CCD, no matter what it's noise, is
> matched (voltage wise and/or current wise) to the input range of the A/D
> through analog circuitry.  The A/D (as in number of bits) is chosen (as well
> as the analog interface circuitry) to match the CCD...one typically doesn't
> use 24 bit A/Ds when the noise level is only good for 10 bits of that 24!
> Even if you did use a 24 bit A/D, only 10 bits of it would be "useful",
> because of the noise.

I guess this is why the older Scanmaker 5 always made very noisy scans.

-mikeH

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> 
> What determines where the endpoints of a RAW highbit scans (no tonal
> manipulation by the driver or image editor, and no profile assigned) get
> written to Photoshop's histogram in 16-bit mode? In other words, why does it
> appear to be of such low dynamic range, and bunched into the dark end of the
> histogram? If you scan a chrome which has a dynamic range of 3.7 on a
> scanner which has a true dynamic range of 3.7, why wouldn't the data span
> the histogram? It would still be bunched up.

Simple answer; because you are scanning into a 16bit space and the 
scanner is not 16bits. That 3.7 worth of information is linearly placed 
along the 16bit histogram.

-mike

> > > > I don't know quite what you mean here...we only measure
> > > relative values, as
> > > > in 2 times, 3 times, 4 times....1000 times...only integer
> ratio values.
> > >
> > > What he is saying is that the CCD's voltage is analog and therefore
> > > infinite.
> >
> > That's a misnomer.  Analog is not infinite.  It is limited by noise, and
> > that is what dynamic range is...the largest signal over the
> noise.  If you
> > have a maximum 6V signal, and your noise level is .003 volts, you have a
> > dynamic range of 3.3.
>
> okay, well why don't you make a CCD with more volts and less noise?
> You can't put aside our theoretical arguments by saying a CCD has
> noise.

What "theoretical arguments"?  I'm talking reality.

> > > Why can't, using your above example, someone make a scanner using the
> > > more sensitive 14bit A/D converter on the less sensitive CCD from the
> > > 10bit scanner. (I assume you mean sensitive as in the ability of the
> > > CCD to judge brighter or darker tones)  This should allow more tonal
> > > information over the same Density Range.
> >
> > Nope.  The values you get out of the CCD/AD are RELATIVE.  2 is twice as
> > bright as 1, and 4 is twice as bright as 2, no matter what CCD
> or A/D you
> > use.
>
> Why does it have to be that way though?

It doesn't, but it's designed TO be that way.  It is easier TO design it to
be this way.  What advantage would you see to doing it some other way?

This design makes things VERY easy, since the data out of the A/D pretty
much matches integer density ratio values.

I don't doubt that.  It could be better CCD, better analog front end, better
A/D...basically, better linearity, better noise, better optics...better
transport.  Many, many other factors make digital image soup ;-)

> There's something more in this soup,because even with the dynamic
> range of a
> chrome not being more than 3.6,a scanner about 4.3DR as the new Nikon 4000
> or cylinder scan better than a 3.6 one...
> >
> > Also, 16 bits is entirely unnecessary to capture image data at, since no
> > film you will be scanning can have a dynamic range of 4.8!

> Never mind about that, I guess when you said "the way current scanners
> are designed" you were correct.

OK.

> I don't know about 3.2 drange, but how about the Microtek 300Z or the
> Apple One Scanner.

Got the specs for them?

> > It IS possible, I've already "figured it out", but, as you say, it just
> > isn't necessary.  It's actually very simple.  The data out of
> the A/D does
> > not represent integer density ratio values, but fractional density ratio
> > values.
>
> Why do they have to be integers?

Because that's what ratio values typically are.  Ratios are relative to 1.
You set 1 to some density value, and when something is twice as dark, that
gets a value of 2, as in 2:1.


>
> > > I have taken issue with the term dynamic range. Scanner companies use
> > > it to mean their scanners capture more information.
> >
> > The term "dynamic range" has been around long before scanners, and has a
> > fixed meaning in the engineering community.  Because it is
> > misrepresented/misunderstood by some does not change the
> definition of it.
>
> The dynamic range of sound does not relate to the intensity (volume)

Actually, it does.  It's typically measured just below clipping.  Dynamic
range is very simple.  It is the largest signal over the smallest
discernable signal.

> > > If a
> > > scanner could really capture 4.5 density-range in a 12 bit space,
> >
> > As I've said, you CAN capture (if you design a scanner to do
> so) any density
> > range into 2 or more bits...BUT...the values you get are NOT
> integer density
> > ratio values.
>
> Who says they have to be integers?

See above, and that's the way they are designed.  What advantage would you
get by not using integer density ratio values?


> > > then
> > > a normal negative's range would have to fit into a much smaller space
> > > than 12 bits.
> >
> > For that particular scanner, IF that scanner was designed to
> operate that
> > way, that could be true.  Perhaps the scanner could expand the
> data to fit
> > the entire 12 bits.
> >
>
> Wouldn't this be something we would want?

No, not if YOU wanted to manually set the setpoints.

> > > Which would mean that, with that negative, that scanner
> > > would actually capture less information than a 3.3 d-range, 12 bit,
> > > scanner.  Does this make sense?
> >
> > Only if the scanner was designed to operate that way.
>
> I am thinking that this would be true with the scanners on the market
> now, yes?

No.

> >
> > > That is one of the reasons I think they should have called it density
> > > range. And left the term dynamic range to something more along the
> > > lines of bit depth.
> >
> > But they are both the exact same thing.  Density is a ratio, just like
> > dynamic range is.
>
> Yes and no, density is a ratio compared to the darkest one can see.
> Dynamic range is a ratio compared to the sublest change one can see.
> Because of the way scanners are made, they end up being the same.

It isn't because of the way scanners are made...it's because of the way CCDs
measure light, as well as being convenient and make sense.  What the heck is
the problem with using integer density ratio values?  Can you propose some
other methodology that can be standardized so all data files pretty much
"mean" the same thing?  Your arguing about why car wheels are round IMO.
You could make them something else, but why and to what advantage?

> Simple answer; because you are scanning into a 16bit space and the
> scanner is not 16bits. That 3.7 worth of information is linearly placed
> along the 16bit histogram.

Do you believe it is high bit justified, or just left low bit justified?  In
other words, does the scanner A/D give you a 12 bit value of 0101 1010 1010.
Does that end up in the 16 bit space as 0101 1010 1010 0000 OR 0000 0101
1010 1010?

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> 
> > Simple answer; because you are scanning into a 16bit space and the
> > scanner is not 16bits. That 3.7 worth of information is linearly placed
> > along the 16bit histogram.
> 
> Do you believe it is high bit justified, or just left low bit justified?  In
> other words, does the scanner A/D give you a 12 bit value of 0101 1010 1010.
> Does that end up in the 16 bit space as 0101 1010 1010 0000 OR 0000 0101
> 1010 1010?

What difference does it make? I was answering his question of why the 
raw scan doesn't fill the whole 16bit space. Luckily, we don't have to 
worry about what our images look like written out in binary.

This does raise the question of, if the scanner is only capable of 
capturing 3.7 worth of information, why doesn't it automatically expand 
the range to fill the 16bit space, even in a raw scan.

-mikeH

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

on 9/26/01 2:41 PM, mh@... wrote:

> This does raise the question of, if the scanner is only capable of
> capturing 3.7 worth of information, why doesn't it automatically expand
> the range to fill the 16bit space, even in a raw scan.

I believe some scanners can do this, like the Imacon for one, but I don't
consider that a raw scan anymore. That's a manipulated scan.

Todd

> > This does raise the question of, if the scanner is only capable of
> > capturing 3.7 worth of information, why doesn't it automatically expand
> > the range to fill the 16bit space, even in a raw scan.
> 
> I believe some scanners can do this, like the Imacon for one, but I don't
> consider that a raw scan anymore. That's a manipulated scan.
> 
> Todd

I agree ;-)

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
> > I don't know about 3.2 drange, but how about the Microtek 300Z or the
> > Apple One Scanner.
> 
> Got the specs for them?

They could probably be found on the internet somewhere. I'm sure they 
are pretty bad. I don't think they rated dynamic range for them back 
then.


> > > It IS possible, I've already "figured it out", but, as you say, it just
> > > isn't necessary.  It's actually very simple.  The data out of
> > the A/D does
> > > not represent integer density ratio values, but fractional density ratio
> > > values.
> >
> > Why do they have to be integers?
> 
> Because that's what ratio values typically are.  Ratios are relative to 1.
> You set 1 to some density value, and when something is twice as dark, that
> gets a value of 2, as in 2:1.

I ask because if they were't, according to you, that would allow us to 
get a smooth, longer histogram out of the same d-range negative.

> 
> >
> > > > I have taken issue with the term dynamic range. Scanner companies use
> > > > it to mean their scanners capture more information.
> > >
> > > The term "dynamic range" has been around long before scanners, and has a
> > > fixed meaning in the engineering community.  Because it is
> > > misrepresented/misunderstood by some does not change the
> > definition of it.
> >
> > The dynamic range of sound does not relate to the intensity (volume)
> 
> Actually, it does.  It's typically measured just below clipping.  Dynamic
> range is very simple.  It is the largest signal over the smallest
> discernable signal.

That doesn't mean they are the same.

> > > > If a
> > > > scanner could really capture 4.5 density-range in a 12 bit space,
> > >
> > > As I've said, you CAN capture (if you design a scanner to do
> > so) any density
> > > range into 2 or more bits...BUT...the values you get are NOT
> > integer density
> > > ratio values.
> >
> > Who says they have to be integers?
> 
> See above, and that's the way they are designed.  What advantage would you
> get by not using integer density ratio values?

So that we could scan a negative of 3.2 d-range into a 12 bit space 
(something you can't do with scanner capable of 4.0, 12 bits)

> > > > then
> > > > a normal negative's range would have to fit into a much smaller space
> > > > than 12 bits.
> > >
> > > For that particular scanner, IF that scanner was designed to
> > operate that
> > > way, that could be true.  Perhaps the scanner could expand the
> > data to fit
> > > the entire 12 bits.
> > >
> >
> > Wouldn't this be something we would want?
> 
> No, not if YOU wanted to manually set the setpoints.

But it wouldn't be clipping, so I would always like it to fill more of 
the histogram and get more tonality. I could always compress it myself 
if that is what I wanted.

> 
> > > > Which would mean that, with that negative, that scanner
> > > > would actually capture less information than a 3.3 d-range, 12 bit,
> > > > scanner.  Does this make sense?
> > >
> > > Only if the scanner was designed to operate that way.
> >
> > I am thinking that this would be true with the scanners on the market
> > now, yes?
> 
> No.

why not?

> > >
> > > > That is one of the reasons I think they should have called it density
> > > > range. And left the term dynamic range to something more along the
> > > > lines of bit depth.
> > >
> > > But they are both the exact same thing.  Density is a ratio, just like
> > > dynamic range is.
> >
> > Yes and no, density is a ratio compared to the darkest one can see.
> > Dynamic range is a ratio compared to the sublest change one can see.
> > Because of the way scanners are made, they end up being the same.
> 
> It isn't because of the way scanners are made...it's because of the way CCDs
> measure light, as well as being convenient and make sense.  What the heck is
> the problem with using integer density ratio values?  Can you propose some
> other methodology that can be standardized so all data files pretty much
> "mean" the same thing?  Your arguing about why car wheels are round IMO.
> You could make them something else, but why and to what advantage?

ideally, to get a smooth, full, 16bit histogram from a negative with 
less dynamic range than 4.8 or whatever it would take using current 
methodologies.

-mikeH

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> 
> > > This does raise the question of, if the scanner is only capable of
> > > capturing 3.7 worth of information, why doesn't it automatically expand
> > > the range to fill the 16bit space, even in a raw scan.
> > 
> > I believe some scanners can do this, like the Imacon for one, but I don't
> > consider that a raw scan anymore. That's a manipulated scan.
> > 
> > Todd
> 
> I agree ;-)

I don't disagree, but if the scanner is ONLY capable of capturing that 
range and nothing outside of it, it seems to me that it should, maybe 
even as a default, spread that range over the 16bits.

-mikeH

> --- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
> darkroom@i...> wrote:
> >
> > > > This does raise the question of, if the scanner is only capable of
> > > > capturing 3.7 worth of information, why doesn't it
> automatically expand
> > > > the range to fill the 16bit space, even in a raw scan.
> > >
> > > I believe some scanners can do this, like the Imacon for one,
> but I don't
> > > consider that a raw scan anymore. That's a manipulated scan.
> > >
> > > Todd
> >
> > I agree ;-)
>
> I don't disagree, but if the scanner is ONLY capable of capturing that
> range and nothing outside of it, it seems to me that it should, maybe
> even as a default, spread that range over the 16bits.

Any time the data is manipulated it is NOT raw, plain and simple.  Spreading
it out makes it NOT raw data.  That was the only point.  I don't understand
your point about "capturing only that range".  What do you mean by that?

Do you guys not have to work or something?  This has been many hours of back
and forth already today...

> > > Simple answer; because you are scanning into a 16bit space and the
> > > scanner is not 16bits. That 3.7 worth of information is
> linearly placed
> > > along the 16bit histogram.
> >
> > Do you believe it is high bit justified, or just left low bit
> justified?  In
> > other words, does the scanner A/D give you a 12 bit value of
> 0101 1010 1010.
> > Does that end up in the 16 bit space as 0101 1010 1010 0000 OR 0000 0101
> > 1010 1010?
>
> What difference does it make? I was answering his question of why the
> raw scan doesn't fill the whole 16bit space. Luckily, we don't have to
> worry about what our images look like written out in binary.

It matters in how much space the values will occupy in the 16 bit space when
you get them from the scanner.  If the values are low bit justified, they
will occupy a smaller span than if the values were high bit justified.  Do
you know the answer?

> This does raise the question of, if the scanner is only capable of
> capturing 3.7 worth of information, why doesn't it automatically expand
> the range to fill the 16bit space, even in a raw scan.

I don't see that as significant, at least to me.  One reason is so you have
room to make tonal/endpoint adjustments.  You need headroom on top of the
data, below the data and between the data.  Just because you capture
something doesn't mean it's exactly what you want...you may want to re-set
the setpoints.  To what advantage does having the scanner/firmware/driver do
that operation for you, vs, you doing it in PS?  PS can do autoranging I
believe, which basically does what you are saying you want.  Why is this an
issue for you?

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> 
> 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....
>

What Todd should have said is in linear fashion, not GAMMA (that threw 
Austin for a loop)

What Austin should have said at the end there is; data is bunched up in 
raw scans because the d-range of the film is less than the d-range of 
the scanner which is less than the 16bit space. It is mostly bunched 
because of the 16bit aspect.


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

He is saying a 10bit scan and a 14bit scan of the same thing will be 
the same because 14bit scanners are capable of capturing more dense 
negs and therefore the the scan will occupy the same space on the 16bit 
histogram as with the 10bit scanner. 

My argument was for a scanner capable of capturing more tones in the 
same density range rather than more tones because of a larger density 
range.

-mikeH

> > 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....
> >
>
> What Todd should have said is in linear fashion, not GAMMA (that threw
> Austin for a loop)
>
> What Austin should have said at the end there is; data is bunched up in
> raw scans because the d-range of the film is less than the d-range of
> the scanner which is less than the 16bit space. It is mostly bunched
> because of the 16bit aspect.

That is correct.  There are two possible places of "bunching".  One, in the
actual span of the data in the actual scanner dynamic range (bit depth), and
then if the data is low bit justified, mapping that into a higher bit space.
If the data is high bit justified, then that doesn't add to the "bunching",
it would spread it out.

> My argument was for a scanner capable of capturing more tones in the
> same density range rather than more tones because of a larger density
> range.

What would you do with those tones?

Wow, there is a whole lot of "techno babble" laced, pompous opinions about a
device that apparently no one has used! To read the opinions that are
expressed in this thread one could draw the conclusion that this unit is a
piece of junk. Further, that the Minolta people are just a mendacious bunch
and have just entered the commercial world of photography.

It is surprising that on this list of over 500 members who are involved in
digital photography that no member has used this scanner and/or has seen a
product of the machine. I have read the very recent and comprehensive review
of this scanner at www.imaging-resource.com An excerpt from that review
states:"...First and foremost, the Dimage Scan Multi Pro delivers an
extraordinary level of detail, in this respect eclipsing all desktop
scanners we've recently tested (September, 2001)...This is a scanner that
takes a back seat to no one in image quality although it (sic) we found its
scan times to be a little slow, at least on a Mac platform".

I wonder which marvelous scanner is being used by those on this list that is
better than this Minolta model.

I do not now own or have a every owned or used a film scanner, have no bias
about a Minolta or any other film scanner. I would like to read users'
opinions about film scanners that would be useful in helping one make a
prudent buying decision for a scanner in this category. I am not really
interested in best quality for the price--only quality.

Peter Palmer

on 9/26/01 3:06 PM, Austin Franklin wrote:

> Do you guys not have to work or something?  This has been many hours of back
> and forth already today...

I know, I'm dying. If this goes on much longer my business, health, and sex
life will suffer --more! ;-)

I just hate that I haven't gotten to the Ah-ha! breakthrough point, and this
topic raises it's ugly head again later, and we get fried all over again....

I don't mean to put it all on your shoulders. I posted my question on
Apple's Colorsync list. A lot of PS geeks reside there and I haven't worn
out my welcome there yet, so will see what comes of it...

Todd

on 9/26/01 3:14 PM, Austin Franklin wrote:

>>> Do you believe it is high bit justified, or just left low bit
>> justified?  In
>>> other words, does the scanner A/D give you a 12 bit value of
>> 0101 1010 1010.
>>> Does that end up in the 16 bit space as 0101 1010 1010 0000 OR 0000 0101
>>> 1010 1010?
>> 
>> What difference does it make? I was answering his question of why the
>> raw scan doesn't fill the whole 16bit space. Luckily, we don't have to
>> worry about what our images look like written out in binary.
> 
> It matters in how much space the values will occupy in the 16 bit space when
> you get them from the scanner.  If the values are low bit justified, they
> will occupy a smaller span than if the values were high bit justified.  Do
> you know the answer?

I know I for one await *your* answer (Austin) with baited breath. If you can
explain this clearly, and why the difference yields differing spans, we will
have come a long way.

T

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> > > > Simple answer; because you are scanning into a 16bit space and the
> > > > scanner is not 16bits. That 3.7 worth of information is
> > linearly placed
> > > > along the 16bit histogram.
> 
> > This does raise the question of, if the scanner is only capable of
> > capturing 3.7 worth of information, why doesn't it automatically expand
> > the range to fill the 16bit space, even in a raw scan.
> 
> I don't see that as significant, at least to me.  One reason is so you have
> room to make tonal/endpoint adjustments.  You need headroom on top of the
> data, below the data and between the data.  Just because you capture
> something doesn't mean it's exactly what you want...you may want to re-set
> the setpoints.  To what advantage does having the scanner/firmware/driver do
> that operation for you, vs, you doing it in PS?  PS can do autoranging I
> believe, which basically does what you are saying you want.  Why is this an
> issue for you?


This isn't an issue for me, but it has to do with the original 
question.  Which is why, if you are scanning something with a range of 
3.7 on a scanner only capable of 3.7, do you get a partial histogram.
We all know the answer.

But if that is all it can capture, then why not spread that out? If you 
want half your histogram empty you can always compress it with levels 
later and you'll end up with the same thing. Why is the whitest a 
scanner can capture NEVER white in raw scan mode? same with black?

Also, there is technology out there that will artificially smooth the 
histogram, which I could see as useful if combined with something like 
that. In 16bits, the difference is probably not noticeable, but still 
the option would be nice. (I don't need a speech on whether or not you 
would ever use something like that)

-mikeH

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" 
> > My argument was for a scanner capable of capturing more tones in the
> > same density range rather than more tones because of a larger density
> > range.
> 
> What would you do with those tones?

I would go crazy with the tones!  i would love them and feed them and 
keep them forever and ever!

on 9/26/01 3:17 PM, mh@... wrote:

> He is saying a 10bit scan and a 14bit scan of the same thing will be
> the same because 14bit scanners are capable of capturing more dense
> negs and therefore the the scan will occupy the same space on the 16bit
> histogram as with the 10bit scanner.

Come again please? I don't get this. They should look the same BECAUSE the
14 bit scanner is capable of capturing more dense negs?

Todd

> --- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin"
> > > My argument was for a scanner capable of capturing more tones in the
> > > same density range rather than more tones because of a larger density
> > > range.
> >
> > What would you do with those tones?
>
> I would go crazy with the tones!  i would love them and feed them and
> keep them forever and ever!

Unless you're scanning for another species, they are completely useless, and
you will never see them in a final image that contains all the range of
tones from the image.

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> 
wrote:
> on 9/26/01 3:17 PM, mh@t... wrote:
> 
> > He is saying a 10bit scan and a 14bit scan of the same thing will be
> > the same because 14bit scanners are capable of capturing more dense
> > negs and therefore the the scan will occupy the same space on the 16bit
> > histogram as with the 10bit scanner.
> 
> Come again please? I don't get this. They should look the same BECAUSE the
> 14 bit scanner is capable of capturing more dense negs?
> 
> Todd

A 14bit scanner captures (maps you could say) to a larger piece of the 
16bit histogram than the 10bit. But at the same time it captures more 
dense negs. So a scan of the same neg would use the same piece of the 
16bit histogram using both scanners. This is according to what Austin 
has been saying. I have no real world experience comparing this.
Does that make sense?

-mikeH

>> My argument was for a scanner capable of capturing more tones in the
>> same density range rather than more tones because of a larger density
>> range.

Isn't that the case if you have a film with a DR which is small enough that
it can be captured by a 10-bit scanner, but you scan it with a 14-bit
scanner? This is a common occurrence with color negative films, no?

Todd

> But if that is all it can capture, then why not spread that out?

WHY spread it out?  Why have the scanner do something you may not want it to
do, or do it not optimally?  For 8 bit data, this is done...but you have to
set the setpoints...or you lose data that you may or may not have wanted.

> If you
> want half your histogram empty you can always compress it with levels
> later

I don't want my histograms compressed.  I don't understand why you would
either.  What I want is to set the setpoints, and then expand the data to
fill the histogram.  It can be done automatically, or manually.  This is
just such minutia!  It is something that is just a no brainer little feature
that you want (I'm not saying it's a bad feature...but what is up with
spending so much time on it?)...and I don't get what the big deal is with
it.  It's not like you can't do it in PS!

> and you'll end up with the same thing. Why is the whitest a
> scanner can capture NEVER white in raw scan mode? same with black?

Because it's in the middle of the space.

> Also, there is technology out there that will artificially smooth the
> histogram, which I could see as useful if combined with something like
> that. In 16bits, the difference is probably not noticeable, but still
> the option would be nice. (I don't need a speech on whether or not you
> would ever use something like that)

I don't see how that's useful.  What is it useful for?  How is that going to
make your output any better?

> > > He is saying a 10bit scan and a 14bit scan of the same thing will be
> > > the same because 14bit scanners are capable of capturing more dense
> > > negs and therefore the the scan will occupy the same space on 
> the 16bit
> > > histogram as with the 10bit scanner.
> > 
> > Come again please? I don't get this. They should look the same 
> BECAUSE the
> > 14 bit scanner is capable of capturing more dense negs?
> > 
> > Todd
> 
> A 14bit scanner captures (maps you could say) to a larger piece of the 
> 16bit histogram than the 10bit. But at the same time it captures more 
> dense negs. So a scan of the same neg would use the same piece of the 
> 16bit histogram using both scanners. This is according to what Austin 
> has been saying. I have no real world experience comparing this.
> Does that make sense?
> 
> -mikeH

You are right, but only if the data is low bit justified.

> >> My argument was for a scanner capable of capturing more tones in the
> >> same density range rather than more tones because of a larger density
> >> range.
>
> Isn't that the case if you have a film with a DR which is small
> enough that
> it can be captured by a 10-bit scanner, but you scan it with a 14-bit
> scanner? This is a common occurrence with color negative films, no?
>
> Todd

Color negative film has a higher dynamic range, and therefore will occupy a
wider range of values...you get more tones, but it's not from intermediate
tones, but from wider range of tones on the end(s).

I like short questions like this ;-)

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> 
> 
> > --- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin"
> > > > My argument was for a scanner capable of capturing more tones in the
> > > > same density range rather than more tones because of a larger density
> > > > range.
> > >
> > > What would you do with those tones?
> >
> > I would go crazy with the tones!  i would love them and feed them and
> > keep them forever and ever!
> 
> Unless you're scanning for another species, they are completely useless, and
> you will never see them in a final image that contains all the range of
> tones from the image.

Are you saying that todays scanners capture all the tones in any given 
negative or chrome, as long as their density is not out of the scanners 
range?

Because if you are I don't agree. Film is analog, and while it might 
not be practical to call it infinite, it still has an awful lot of 
tones.

You could use a scanner like that and see them in a print if you 
expanded a small section of tones to use the whole gamut.


-mikeH

> Wow, there is a whole lot of "techno babble" laced, pompous
> opinions about a
> device that apparently no one has used! To read the opinions that are
> expressed in this thread one could draw the conclusion that this unit is a
> piece of junk. Further, that the Minolta people are just a
> mendacious bunch
> and have just entered the commercial world of photography.

Well, I don't know about all that...but some of their technical statements
were not really accurate, their example of 14 bits vs 16 bits wasn't using
real images...so there is good reason to be skeptical of their
marketing...not necessarily of the scanner.  The scanner MAY be very good, I
don't believe anyone said otherwise.

> > > > What would you do with those tones?
> > >
> > > I would go crazy with the tones!  i would love them and feed them and
> > > keep them forever and ever!
> > 
> > Unless you're scanning for another species, they are completely 
> useless, and
> > you will never see them in a final image that contains all the range of
> > tones from the image.
> 
> Are you saying that todays scanners capture all the tones in any given 
> negative or chrome, as long as their density is not out of the scanners 
> range?

All that you and I can see.
 
> Because if you are I don't agree. Film is analog, and while it might 
> not be practical to call it infinite, it still has an awful lot of 
> tones.
> 
> You could use a scanner like that and see them in a print if you 
> expanded a small section of tones to use the whole gamut.

I suggest you do some research on the capabilities of the human eye...

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> > But if that is all it can capture, then why not spread that out?
> 
> WHY spread it out?  Why have the scanner do something you may not want it to
> do, or do it not optimally?  For 8 bit data, this is done...but you have to
> set the setpoints...or you lose data that you may or may not have wanted.

There is nothing not optimal about it, it doesn't hurt the data in any 
way.

> > If you
> > want half your histogram empty you can always compress it with levels
> > later
> 
> I don't want my histograms compressed.  I don't understand why you would
> either.  What I want is to set the setpoints, and then expand the data to
> fill the histogram.  It can be done automatically, or manually. 

YOUR histograms start out compressed (with a raw scan)
Im not talking about setting setpoints and expanding your image. Im 
talking about expanding the entire range the scanner is capable of.
If, for an unknown reason, you don't want the entire range used and you 
want your whites to be gray, you can compress the range later (which is 
why I said that, not because I want to)

> 
> > and you'll end up with the same thing. Why is the whitest a
> > scanner can capture NEVER white in raw scan mode? same with black?
> 
> Because it's in the middle of the space.

yes, but why do it that way? All it does is confuse beginners.
 
> > Also, there is technology out there that will artificially smooth the
> > histogram, which I could see as useful if combined with something like
> > that. In 16bits, the difference is probably not noticeable, but still
> > the option would be nice. (I don't need a speech on whether or not you
> > would ever use something like that)
> 
> I don't see how that's useful.  What is it useful for?  How is that going to
> make your output any better?

It doesn't in 16bits, (but it does in 8) unless you need to really 
expand the tones to where you would normally get fingers of death (a 
major expansion in 16bits)  but this is neither there nor here.

-mikeH

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> 
> > >> My argument was for a scanner capable of capturing more tones in the
> > >> same density range rather than more tones because of a larger density
> > >> range.
> >
> > Isn't that the case if you have a film with a DR which is small
> > enough that
> > it can be captured by a 10-bit scanner, but you scan it with a 14-bit
> > scanner? This is a common occurrence with color negative films, no?
> >
> > Todd
> 
> Color negative film has a higher dynamic range, and therefore will occupy a
> wider range of values...you get more tones, but it's not from intermediate
> tones, but from wider range of tones on the end(s).
> 
> I like short questions like this ;-)

except you didn't answer is question,   hehe

The answer is no.

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> > Wow, there is a whole lot of "techno babble" laced, pompous
> > opinions about a
> > device that apparently no one has used! To read the opinions that are
> > expressed in this thread one could draw the conclusion that this unit is a
> > piece of junk. Further, that the Minolta people are just a
> > mendacious bunch
> > and have just entered the commercial world of photography.
> 
> Well, I don't know about all that...but some of their technical statements
> were not really accurate, their example of 14 bits vs 16 bits wasn't using
> real images...so there is good reason to be skeptical of their
> marketing...not necessarily of the scanner.  The scanner MAY be very good, I
> don't believe anyone said otherwise.


yes, I too have no experience with Minolta scanners and am saying 
nothing good or bad about them in this thread.

-mikeH

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:

> > You could use a scanner like that and see them in a print if you 
> > expanded a small section of tones to use the whole gamut.
> 
> I suggest you do some research on the capabilities of the human eye...

What does the human eye have to do with it if you are expanding a small 
tonal region to use a larger gamut that the human eye CAN see?

-mh

on 9/26/01 3:45 PM, Austin Franklin wrote:

> 
>>>> My argument was for a scanner capable of capturing more tones in the
>>>> same density range rather than more tones because of a larger density
>>>> range.
>> 
>> Isn't that the case if you have a film with a DR which is small
>> enough that
>> it can be captured by a 10-bit scanner, but you scan it with a 14-bit
>> scanner? This is a common occurrence with color negative films, no?
>> 
>> Todd
> 
> Color negative film has a higher dynamic range, and therefore will occupy a
> wider range of values...you get more tones, but it's not from intermediate
> tones, but from wider range of tones on the end(s).
> 
> I like short questions like this ;-)

Ya me too. :-)

I thought due to it's low density dye clouds color neg film was of low
density range, thus low Dynamic Range, thus an easy scan.

Don't tell me there's more I'm missing! ;-)

T

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> 
wrote:
> on 9/26/01 3:45 PM, Austin Franklin wrote:
> 
> > 
> >>>> My argument was for a scanner capable of capturing more tones in the
> >>>> same density range rather than more tones because of a larger density
> >>>> range.
> >> 
> >> Isn't that the case if you have a film with a DR which is small
> >> enough that
> >> it can be captured by a 10-bit scanner, but you scan it with a 14-bit
> >> scanner? This is a common occurrence with color negative films, no?
> >> 
> >> Todd
> > 
> > Color negative film has a higher dynamic range, and therefore will occupy a
> > wider range of values...you get more tones, but it's not from intermediate
> > tones, but from wider range of tones on the end(s).
> > 
> > I like short questions like this ;-)
> 
> Ya me too. :-)
> 
> I thought due to it's low density dye clouds color neg film was of low
> density range, thus low Dynamic Range, thus an easy scan.
> 
> Don't tell me there's more I'm missing! ;-)
> 
> T

yes, what was Austin talking about,  color neg has a higher density 
range than what?

Todd, did you get what I was saying about 10 vs 14 bit in the other 
posts?

-mikeH

> > > But if that is all it can capture, then why not spread that out?
> >
> > WHY spread it out?  Why have the scanner do something you may
> not want it to
> > do, or do it not optimally?  For 8 bit data, this is done...but
> you have to
> > set the setpoints...or you lose data that you may or may not
> have wanted.
>
> There is nothing not optimal about it

Yes there is, it's an operation, and you're asking the scanner to decide
what valid image data is.  That's non-optimal.

> it doesn't hurt the data in any
> way.

WRONG.  How do you know that the scanner can just so happen to pick out the
EXACT edges of the image data.  It absolutely CAN lose data.

> > > If you
> > > want half your histogram empty you can always compress it with levels
> > > later
> >
> > I don't want my histograms compressed.  I don't understand why you would
> > either.  What I want is to set the setpoints, and then expand
> the data to
> > fill the histogram.  It can be done automatically, or manually.
>
> YOUR histograms start out compressed (with a raw scan)

But you said you could compress them if you wanted to. I was answering that.
That is entirely different than the raw compressed histogram.

> Im not talking about setting setpoints and expanding your image. Im
> talking about expanding the entire range the scanner is capable of.
> If, for an unknown reason, you don't want the entire range used and you
> want your whites to be gray, you can compress the range later (which is
> why I said that, not because I want to)

How do you decide the setpoints?

> > > and you'll end up with the same thing. Why is the whitest a
> > > scanner can capture NEVER white in raw scan mode? same with black?
> >
> > Because it's in the middle of the space.
>
> yes, but why do it that way? All it does is confuse beginners.

Cripes.  Beginners shouldn't be using raw data.  There is a certain level of
understanding one has to have to understand how to do this right.  You're
saying we should dumb down the imaging software simply for beginners?
Please.

> I thought due to it's low density dye clouds color neg film was of low
> density range, thus low Dynamic Range, thus an easy scan.
> 
> Don't tell me there's more I'm missing! ;-)

It has a higher density range than B&W negatives.

> > > You could use a scanner like that and see them in a print if you
> > > expanded a small section of tones to use the whole gamut.
> >
> > I suggest you do some research on the capabilities of the human eye...
>
> What does the human eye have to do with it if you are expanding a small
> tonal region to use a larger gamut that the human eye CAN see?

This is getting futile.  Yes you COULD do this, but for most everyone it is
entirely useless.  No one but you seems to have any desire to want to do it.
Most people scan their entire range of their image and print it, or put it
on the web.  The intermediate density values you so seek will do NOTHING for
everyone else, they can not be seen.

> > > >> My argument was for a scanner capable of capturing more
> tones in the
> > > >> same density range rather than more tones because of a
> larger density
> > > >> range.
> > >
> > > Isn't that the case if you have a film with a DR which is small
> > > enough that
> > > it can be captured by a 10-bit scanner, but you scan it with a 14-bit
> > > scanner? This is a common occurrence with color negative films, no?
> > >
> > > Todd
> >
> > Color negative film has a higher dynamic range, and therefore
> will occupy a
> > wider range of values...you get more tones, but it's not from
> intermediate
> > tones, but from wider range of tones on the end(s).
> >
> > I like short questions like this ;-)
>
> except you didn't answer is question,   hehe

Sure I did.  I gave an explanation for an answer.  I've tried the "yes/no"
answers with you two, and you always come back and ask "why", so I guess I
can't win no matter what I answer.

> I ask because if they were't, according to you, that would allow us to
> get a smooth, longer histogram out of the same d-range negative.

For raw data, yes...but of what use, I still don't know.

> > > The dynamic range of sound does not relate to the intensity (volume)
> >
> > Actually, it does.  It's typically measured just below
> clipping.  Dynamic
> > range is very simple.  It is the largest signal over the smallest
> > discernable signal.
>
> That doesn't mean they are the same.

Yes it does.  That's like saying two apples are a different "two" than two
oranges!

> > > Who says they have to be integers?
> >
> > See above, and that's the way they are designed.  What
> advantage would you
> > get by not using integer density ratio values?
>
> So that we could scan a negative of 3.2 d-range into a 12 bit space
> (something you can't do with scanner capable of 4.0, 12 bits)

But a dynamic range of 3.2 DOES fit in a 12 bit space.  I don't understand
your issue here.  12 bits can hold an integer density ratio value dynamic
range of 3.6.

> > > > > then
> > > > > a normal negative's range would have to fit into a much
> smaller space
> > > > > than 12 bits.
> > > >
> > > > For that particular scanner, IF that scanner was designed to
> > > operate that
> > > > way, that could be true.  Perhaps the scanner could expand the
> > > data to fit
> > > > the entire 12 bits.
> > > >
> > >
> > > Wouldn't this be something we would want?
> >
> > No, not if YOU wanted to manually set the setpoints.
>
> But it wouldn't be clipping,

How do you know.  If you haven't defined the setpoints, then you MAY be
clipping.

> so I would always like it to fill more of
> the histogram and get more tonality.

Again, to what avail?

> > > > > Which would mean that, with that negative, that scanner
> > > > > would actually capture less information than a 3.3
> d-range, 12 bit,
> > > > > scanner.  Does this make sense?
> > > >
> > > > Only if the scanner was designed to operate that way.
> > >
> > > I am thinking that this would be true with the scanners on the market
> > > now, yes?
> >
> > No.
>
> why not?

I don't see the original point I was responding to, and I'm getting to worn
out to really do any work to find out...just suffice to say I stand by my
original answer ;-)

> ideally, to get a smooth, full, 16bit histogram from a negative with
> less dynamic range than 4.8 or whatever it would take using current
> methodologies.

What advantage would this have?  You couldn't make tonal moves, without
losing data.  That's the WHOLE POINT of having headroom!

Also, what good would those tones do?  You can't print them, even if you
could, you could not see them!

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
> >
> > There is nothing not optimal about it
> 
> Yes there is, it's an operation, and you're asking the scanner to decide
> what valid image data is.  That's non-optimal.
> 
> > it doesn't hurt the data in any
> > way.
> 
> WRONG.  How do you know that the scanner can just so happen to pick out the
> EXACT edges of the image data.  It absolutely CAN lose data.

okay, you're alot further off than I thought you were. You need to read 
more carefully or something. I was talking about expanding the entire 
range the scanner is capable of capturing. It has nothing to do with 
the image itself, chances are very good you will still end up needing 
to set the set points and expand (unless you don't want to for some 
reason)
 so every time, for every scan, it would expand the same range.

> > > > If you
> > > > want half your histogram empty you can always compress it with levels
> > > > later
> > >
> > > I don't want my histograms compressed.  I don't understand why you would
> > > either.  What I want is to set the setpoints, and then expand
> > the data to
> > > fill the histogram.  It can be done automatically, or manually.
> >
> > YOUR histograms start out compressed (with a raw scan)
> 
> But you said you could compress them if you wanted to. I was answering that.
> That is entirely different than the raw compressed histogram.

I was saying you could make the data that way if you wanted to.

> > Im not talking about setting setpoints and expanding your image. Im
> > talking about expanding the entire range the scanner is capable of.
> > If, for an unknown reason, you don't want the entire range used and you
> > want your whites to be gray, you can compress the range later (which is
> > why I said that, not because I want to)
> 
> How do you decide the setpoints?

The same way you always did.

> 
> > > > and you'll end up with the same thing. Why is the whitest a
> > > > scanner can capture NEVER white in raw scan mode? same with black?
> > >
> > > Because it's in the middle of the space.
> >
> > yes, but why do it that way? All it does is confuse beginners.
> 
> Cripes.  Beginners shouldn't be using raw data.  There is a certain level of
> understanding one has to have to understand how to do this right.  You're
> saying we should dumb down the imaging software simply for beginners?
> Please.

nothing is getting dumbed down at all. I am surprised more scanners 
don't do it automatically because it makes the scanner look better.

-mikeH

> > What does the human eye have to do with it if you are expanding a small
> > tonal region to use a larger gamut that the human eye CAN see?
> 
> This is getting futile.  Yes you COULD do this, but for most everyone it is
> entirely useless.  No one but you seems to have any desire to want to do it.
> Most people scan their entire range of their image and print it, or put it
> on the web.  The intermediate density values you so seek will do NOTHING for
> everyone else, they can not be seen.

That isn't true, Todd just mentioned a case of thinking that a 14bit 
scanner did this when in fact it doesn't but he would like it too (I 
assume). I think most people would at this point, because nobody needs 
to scan a chrome with a range of 4.8

-mh

on 9/26/01 4:07 PM, Austin Franklin at darkroom@... wrote:

> It has a higher density range than B&W negatives.

not true, Austin

-- 
John Brownlow

http://www.pinkheadedbug.com

> Todd, did you get what I was saying about 10 vs 14 bit in the other
> posts?


Mike,

Honestly, I'm on the edge. I feel a little more info and I'll get this
securely, a little more confusion and I'll loose it completely. Would you
run through it again, so I'm 100% clear?

Todd

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> 
> > > > >> My argument was for a scanner capable of capturing more
> > tones in the
> > > > >> same density range rather than more tones because of a
> > larger density
> > > > >> range.
> > > >
> > > > Isn't that the case if you have a film with a DR which is small
> > > > enough that
> > > > it can be captured by a 10-bit scanner, but you scan it with a 14-bit
> > > > scanner? This is a common occurrence with color negative films, no?
> > > >
> > > > Todd
> > >
> > > Color negative film has a higher dynamic range, and therefore
> > will occupy a
> > > wider range of values...you get more tones, but it's not from
> > intermediate
> > > tones, but from wider range of tones on the end(s).
> > >
> > > I like short questions like this ;-)
> >
> > except you didn't answer is question,   hehe
> 
> Sure I did.  I gave an explanation for an answer.  I've tried the "yes/no"
> answers with you two, and you always come back and ask "why", so I guess I
> can't win no matter what I answer.

okay, you forced me to get nit-picky and state why you didn't answer 
the question.

He stated a "case if you have a film with a DR which is small enough 
that it can be captured by a 10-bit scanner, but you scan it with a 14-
bit scanner?"

you answered "Color negative film has a higher dynamic range" which I 
guess was in reference to BW film, which has nothing to do with the 
question.

sorry for being so persnickety but you tried to blame us.

-mikeH

on 9/26/01 4:07 PM, Austin Franklin wrote:

> 
>> I thought due to it's low density dye clouds color neg film was of low
>> density range, thus low Dynamic Range, thus an easy scan.
>> 
>> Don't tell me there's more I'm missing! ;-)
> 
> It has a higher density range than B&W negatives.
> 

Really? Absolutely? I thought silver particles made for a higher density
than dye clouds. I don't know about ideal conditions, but from my experience
in the darkroom, I could always overexpose and/or overdevelop BW film, in a
way that would give me a greater density over film base than I did with
color neg films. Or so I thought. I've got some bullet proof BW negs where I
can barely see through the highlights (dense areas) on a lightbox. I could
never do that with color neg.

Todd

> Really? Absolutely? I thought silver particles made for a higher density
> than dye clouds.

Were you using a point source enlarger for B&W?  If so, you might have been
getting a "Collier effect".  I believe the Nikon scanners that use LEDs may
have this same issue...

Jason,

You are right about the number of pixels to measure but I was 
thinking about drawing the on screen representation with 65,000 
individual bars in the bar graph as opposed to 256. Still might be 
trival in terms of the actual computing power required I have to 
admit.

Martin



--- In DigitalBlackandWhiteThePrint@y..., "Jason DeFontes" 
<jason@d...> wrote:
> It wouldn't take any longer to calculate a 16 bit histogram. To 
calculate
> the distribution of pixels values in an image you have to count 
every pixel.
> The number of pixels to count is the same whether you're dividing 
the
> distribution into 256 buckets or 64K.
> 
> -Jason
> 

(snip)

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> 
wrote:
>  
> > Todd, did you get what I was saying about 10 vs 14 bit in the other
> > posts?
> 
> 
> Mike,
> 
> Honestly, I'm on the edge. I feel a little more info and I'll get this
> securely, a little more confusion and I'll loose it completely. Would you
> run through it again, so I'm 100% clear?
> 
> Todd

okay, I have a simple way to describe it.

Your image on a 10 bit scanner has a range from A to B, but the scanner 
can capture from A to C (ABD).  On a 14bit scanner, it would still be A 
to b, but the scanners range would be increased to ABCD. All of this 
would be on a section of the 16bit range which would be ABCDE. 

This is why a 14bit scanner does not capture more information than a 
10bit scanner as long as the negative is within it's drange 
capabilities.

Again, I am not sure if this is true, this is just what Austin was 
saying "because of how scanners are designed"

-mikeH

on 9/26/01 5:00 PM, Martin Wesley at mwesley250@... wrote:

> You are right about the number of pixels to measure but I was
> thinking about drawing the on screen representation with 65,000
> individual bars in the bar graph as opposed to 256. Still might be
> trival in terms of the actual computing power required I have to
> admit.

LOL

where do you buy your 65,000 pixel-wide monitors, Martin??

mine only goes up to about 2000!

you must have a big office, too....

....at 96 dpi you have a 56-foot wide display.

-- 
John Brownlow

http://www.pinkheadedbug.com

> > It has a higher density range than B&W negatives.
>
> not true, Austin

Hum.  I've taken exposed/unexposed (then developed) film and measured it and
the color negative film I measured has a higher density range than the B&W
negative film I measured...according to my densitometer:

Supra 100 has a base of .28/.74/.91 and a max of 2.41/2.81/3.15.  Tri-X has
a base of .19 and a max of 2.16.

That's a B&W density range of 1.97, and a color of 2.13/2.07/2.24.

> > > There is nothing not optimal about it
> >
> > Yes there is, it's an operation, and you're asking the scanner to decide
> > what valid image data is.  That's non-optimal.
> >
> > > it doesn't hurt the data in any
> > > way.
> >
> > WRONG.  How do you know that the scanner can just so happen to
> pick out the
> > EXACT edges of the image data.  It absolutely CAN lose data.
>
> okay, you're alot further off than I thought you were. You need to read
> more carefully or something.

I did not see any distinction that you were talking about taking the entire
raw data, as opposed to just the image data.  Obviously, if you are talking
about just raw data, then no data is lost.

> I was talking about expanding the entire
> range the scanner is capable of capturing. It has nothing to do with
> the image itself,

Then that is nothing but high bit justifying the data.  Some scanners
ALREADY DO THAT with their raw data.  Viewscan does that!  (I specifically
asked Ed, and he concurred)

I wouldn't really call that "expanding", like you do when you apply your
setpoints...that's really expanding...but I guess it could be called that.
Expansion, to me, is a more of an algorithmic process.  I did mentioned a
dozen times about setpoints...and setpoints have nothing to do with the raw
data.  Too bad you didn't catch that earlier on, and could have clarified
your point.

> chances are very good you will still end up needing
> to set the set points and expand (unless you don't want to for some
> reason)

Chances?  Probably about 100000 to 1 you need to set the setpoints for a
scanned image!

> nothing is getting dumbed down at all. I am surprised more scanners
> don't do it automatically because it makes the scanner look better.

Probably because no one really cared.  It's a no brainer operation in PS,
and now that I know what you are talking about, as I said above, some
scanners already do that.  That's one reason why I didn't believe that was
what you meant...why you'd be asking for something that already existed!

on 9/26/01 4:41 PM, Austin Franklin wrote:

> 
>> Really? Absolutely? I thought silver particles made for a higher density
>> than dye clouds.
> 
> Were you using a point source enlarger for B&W?  If so, you might have been
> getting a "Collier effect".  I believe the Nikon scanners that use LEDs may
> have this same issue...

To my mind it should be the same issue whether the determination is being
made with a densitometer, condenser, coldlight, point source, LED, or
eyeballs and a lightbox. I propose that you can get a greater density range
from both BW neg and color chromes, than you can from color neg.

I use all of condenser, coldlight, and diffusion enlargers.

Todd

> >>> Do you believe it is high bit justified, or just left low bit
> >> justified?  In
> >>> other words, does the scanner A/D give you a 12 bit value of
> >> 0101 1010 1010.
> >>> Does that end up in the 16 bit space as 0101 1010 1010 0000
> OR 0000 0101
> >>> 1010 1010?
> >>
> >> What difference does it make? I was answering his question of why the
> >> raw scan doesn't fill the whole 16bit space. Luckily, we don't have to
> >> worry about what our images look like written out in binary.
> >
> > It matters in how much space the values will occupy in the 16
> bit space when
> > you get them from the scanner.  If the values are low bit
> justified, they
> > will occupy a smaller span than if the values were high bit
> justified.  Do
> > you know the answer?
>
> I know I for one await *your* answer (Austin) with baited breath.
> If you can
> explain this clearly, and why the difference yields differing
> spans, we will
> have come a long way.

The answer is, it depends on the scanner and the software.  Viewscan DOES
high bit justify the data.  It really doesn't matter either way (except for
someone like Mike who insists it's useful for him), because all the data is
still there, in either case.  You still need to apply setpoints in both
cases, and that will distribute the data pretty much exactly the same too.

I believe the answer is, it doesn't matter as far as data integrity goes,
but if you happen to "like" it one way or the other, then it seems that it
matters ;-)

> >> Really? Absolutely? I thought silver particles made for a
> higher density
> >> than dye clouds.
> >
> > Were you using a point source enlarger for B&W?  If so, you
> might have been
> > getting a "Collier effect".  I believe the Nikon scanners that
> use LEDs may
> > have this same issue...
>
> To my mind it should be the same issue whether the determination is being
> made with a densitometer, condenser, coldlight, point source, LED, or
> eyeballs and a lightbox. I propose that you can get a greater
> density range
> from both BW neg and color chromes, than you can from color neg.

Clearly color chromes, no doubt there, but my measurements of color negative
film vs B&W negative film show that color negative film has a higher (not by
much, but it is higher) dynamic range when measured with a densitometer
(which uses a diffuse light source mind you).

> Your image on a 10 bit scanner has a range from A to B, but the scanner
> can capture from A to C (ABD).  On a 14bit scanner, it would still be A
> to b, but the scanners range would be increased to ABCD. All of this
> would be on a section of the 16bit range which would be ABCDE.
> 
> This is why a 14bit scanner does not capture more information than a
> 10bit scanner as long as the negative is within it's drange
> capabilities.
> 
> Again, I am not sure if this is true, this is just what Austin was
> saying "because of how scanners are designed"
> 
> -mikeH

Thanks Mike, that states the case very clearly.

The big thing I'm waiting for from Austin is his answer to below. I think it
will unify a lot of this for me:

>>> Do you believe it is high bit justified, or just left low bit
>> justified?  In
>>> other words, does the scanner A/D give you a 12 bit value of
>> 0101 1010 1010.
>>> Does that end up in the 16 bit space as 0101 1010 1010 0000 OR 0000 0101
>>> 1010 1010?
>> 
>> What difference does it make? I was answering his question of why the
>> raw scan doesn't fill the whole 16bit space. Luckily, we don't have to
>> worry about what our images look like written out in binary.
> 
> It matters in how much space the values will occupy in the 16 bit space when
> you get them from the scanner.  If the values are low bit justified, they
> will occupy a smaller span than if the values were high bit justified.  Do
> you know the answer?

I know I for one await *your* answer (Austin) with baited breath. If you can
explain this clearly, and why the difference yields differing spans, we will
have come a long way.

T

--- In DigitalBlackandWhiteThePrint@y..., Johnny Deadman <john@p...> 
wrote:
> on 9/26/01 5:00 PM, Martin Wesley at mwesley250@e... wrote:
> 
> > You are right about the number of pixels to measure but I was
> > thinking about drawing the on screen representation with 65,000
> > individual bars in the bar graph as opposed to 256. Still might be
> > trival in terms of the actual computing power required I have to
> > admit.
> 
> LOL
> 
> where do you buy your 65,000 pixel-wide monitors, Martin??

John,

Imax of course. ;-)
> 
> mine only goes up to about 2000!

If I set mine that high I can't read the text.
> 
> you must have a big office, too....

I wish!
> 
> ....at 96 dpi you have a 56-foot wide display.

How about a 360 panorama? A 20x20' room should hold it on flat panels 
and you can put a swivle chair in the center! That would be wild with 
some of your shots!

Okay. I give up. You could have a 16-bit histogram utility that would 
run quickly and display itself on our 96 dpi monitors with full 
screen and zoom functions that would allow you to examine it in 
detail. How come no one has written such a thing as a plugin for 
Photoshop? I'd buy a copy.

Martin

> 
> -- 
> John Brownlow
> 
> http://www.pinkheadedbug.com

on 9/26/01 5:37 PM, Austin Franklin wrote:

>>>>> Do you believe it is high bit justified, or just left low bit
>>>> justified?  In
>>>>> other words, does the scanner A/D give you a 12 bit value of
>>>> 0101 1010 1010.
>>>>> Does that end up in the 16 bit space as 0101 1010 1010 0000
>> OR 0000 0101
>>>>> 1010 1010?
>>>> 
>>>> What difference does it make? I was answering his question of why the
>>>> raw scan doesn't fill the whole 16bit space. Luckily, we don't have to
>>>> worry about what our images look like written out in binary.
>>> 
>>> It matters in how much space the values will occupy in the 16
>> bit space when
>>> you get them from the scanner.  If the values are low bit
>> justified, they
>>> will occupy a smaller span than if the values were high bit
>> justified.  Do
>>> you know the answer?
>> 
>> I know I for one await *your* answer (Austin) with baited breath.
>> If you can
>> explain this clearly, and why the difference yields differing
>> spans, we will
>> have come a long way.
> 
> The answer is, it depends on the scanner and the software.  Viewscan DOES
> high bit justify the data.  It really doesn't matter either way (except for
> someone like Mike who insists it's useful for him), because all the data is
> still there, in either case.  You still need to apply setpoints in both
> cases, and that will distribute the data pretty much exactly the same too.
> 
> I believe the answer is, it doesn't matter as far as data integrity goes,
> but if you happen to "like" it one way or the other, then it seems that it
> matters ;-)

I give up! You dragged this out, and tested Mike, as though this carried
great import. He answered it doesn't matter early on.

I'm still hoping you will explain in a simple coherent way, how the scanner
assigns values to the input data, how that process is affected by the
scanners bit depth, and how that shows up in the histogram. I understand
that is all of what we've been discussing, but it's been addressed in little
disparate snippets. It needs to be tied together. If you don't have the
energy for that I understand. But until that happens there may be no
conclusion. I'm taking a rest...

Todd

> He stated a "case if you have a film with a DR which is small enough
> that it can be captured by a 10-bit scanner, but you scan it with a 14-
> bit scanner?"
>
> you answered "Color negative film has a higher dynamic range" which I
> guess was in reference to BW film, which has nothing to do with the
> question.

I believe the second part of my statement "you get more tones, but it's not
from intermediate tones, but from wider range of tones on the end(s)"
answered the question, whether or not you believe the first statement is
relevant.

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <
darkroom@i...> wrote:
> > He stated a "case if you have a film with a DR which is small enough
> > that it can be captured by a 10-bit scanner, but you scan it with a 14-
> > bit scanner?"
> >
> > you answered "Color negative film has a higher dynamic range" which I
> > guess was in reference to BW film, which has nothing to do with the
> > question.
> 
> I believe the second part of my statement "you get more tones, but it's not
> from intermediate tones, but from wider range of tones on the end(s)"
> answered the question, whether or not you believe the first statement is
> relevant.

you don't get more tones if the film you are scanning is capable of 
being scanned on the 10bit scanner like in the case in question.

-mh

> I give up! You dragged this out, and tested Mike, as though this carried
> great import. He answered it doesn't matter early on.

It matters as far as the question that was being asked, and that was what
causes the bunching up in the histogram.

> I'm still hoping you will explain in a simple coherent way, how
> the scanner
> assigns values to the input data, how that process is affected by the
> scanners bit depth, and how that shows up in the histogram.

I believe I can do that pretty easily.  BUT unfortunately, I have to relate
it to actual hardware...

CCD give you a range of voltage out of it.  That voltage range, no matter
what it is, has noise in it.  That noise level will determine just how much
signal to noise you can get from the CCD/analog "front end" (circuitry
between the CCD and the A/D).  A CCD that can "look further into the dark
regions" will have a lower noise level, and therefore a higher signal to
noise ratio.

Now we have to match the CCD to the A/D, in two ways, one voltage, which we
don't care about, it's done in the "front end", and second, the A/Ds ability
to discern different values all way down to the noise level of the CCD/front
end.  That's where the number of bits is important.  We need to have enough
bits to represent from the minimum signal level out of the CCD/front end to
the highest signal level out of the CCD/front end, and all discernable
levels in-between that are above noise.

The A/D measures voltage (in this case).  Say the CCD/front end has an
output range of +-3V, and the A/D input range is also +- 3V.  Say the noise
is .0003 volts.  This is determined by experimentation with the CCD/analog
front end, the noise can be easily measured in a laboratory with the correct
equipment.

That means the number of different meaningful values the CCD can give us is
6 volts divided by .0003 volts or 20,000 different values.  The A/D has to
have the resources to handle 20,000 different values.  We would need 15 bits
(32,768) to be able to hold 20,000 different values, since our range does
not fit in 14 bits (16,384).

The A/D measures the input voltages from the CCD/front end.  -3V would give
an A/D output of 0, to +3 would give an A/D output of full scale, and for 15
bits, that would be 32,767 decimal.  That is 32,768 different values.

So, 0 represents as close to no light as the CCD can measure...the CCD is
putting out no voltage...and 32,767 represents the highest amount of light
you are calibrated to measure.  I could go into more detail about gain and
calibration, but I believe that's another discussion.

The end voltage, and the intermediate voltages out of the CCD/front end are
obviously also converted in to values between 0 and 32,767, and that is what
is the raw output out of the A/D.  Those are the values that are assigned to
the pixels.

Also, the reason more bit depth gives better dark detail is simple.  Note
the value of -3 out of the CCD gives us a value of 0 out of the A/D.  Well,
that means the scanner sees no light.  A voltage of .0003V out of the CCD
would give us an A/D output of 1.  Remember, that this value of .0003 is the
noise level of the CCD...and that it is simply because of the noise level
that we require so many bits.  In order to see something between 0 and 1, we
have to lower the noise level, say to .00015V.  That would give us 6V
divided by .00015V number of values, or 40,000...which would require 16 bits
to represent 40,000 different values.

This should explain why bit depth limits dynamic range in a scanner (and the
dark detail, not the light detail), and how the scanner "assigns" values to
the data.  Let me know if you get this, any of this or none of this... Then
we can move past it.

on 9/26/01 5:27 PM, Austin Franklin at darkroom@... wrote:

> Supra 100 has a base of .28/.74/.91 and a max of 2.41/2.81/3.15.  Tri-X has
> a base of .19 and a max of 2.16.
> 
> That's a B&W density range of 1.97, and a color of 2.13/2.07/2.24.

something is very squiffy here, then, because it is possible to 'block up'
highlights in BW neg to the extent that my sprintscan 4000 can't get through
them, whereas I simply can't do that using any color neg, including Supra
100. Moreover, placing the negs side by side on a light table, the color neg
subjectively lets more light through.

I'm not saying you didn't read what you read on the densitometer, only that
it's contrary not only to received wisdom (yeah, right) but also to my
personal experience.

-- 
John Brownlow

http://www.pinkheadedbug.com

on 9/26/01 5:50 PM, Martin Wesley at mwesley250@... wrote:

> Okay. I give up. You could have a 16-bit histogram utility that would
> run quickly and display itself on our 96 dpi monitors with full
> screen and zoom functions that would allow you to examine it in
> detail. How come no one has written such a thing as a plugin for
> Photoshop? I'd buy a copy.

ah, now that is a GOOD question!

time to download the Photoshop Plugin SDK!

-- 
John Brownlow

http://www.pinkheadedbug.com

Tri-X is probably one of the lighter b&w films. maybe...


--- In DigitalBlackandWhiteThePrint@y..., Johnny Deadman <john@p...> 
wrote:

> on 9/26/01 5:27 PM, Austin Franklin at darkroom@i... wrote:
> 
> > Supra 100 has a base of .28/.74/.91 and a max of 2.41/2.81/3.15.  Tri-X has
> > a base of .19 and a max of 2.16.
> > 
> > That's a B&W density range of 1.97, and a color of 2.13/2.07/2.24.
> 
> something is very squiffy here, then, because it is possible to 'block up'
> highlights in BW neg to the extent that my sprintscan 4000 can't get through
> them, whereas I simply can't do that using any color neg, including Supra
> 100. Moreover, placing the negs side by side on a light table, the color neg
> subjectively lets more light through.
> 
> I'm not saying you didn't read what you read on the densitometer, only that
> it's contrary not only to received wisdom (yeah, right) but also to my
> personal experience.
> 
> -- 
> John Brownlow
> 
> http://www.pinkheadedbug.com

> on 9/26/01 5:27 PM, Austin Franklin at darkroom@... wrote:
>
> > Supra 100 has a base of .28/.74/.91 and a max of
> 2.41/2.81/3.15.  Tri-X has
> > a base of .19 and a max of 2.16.
> >
> > That's a B&W density range of 1.97, and a color of 2.13/2.07/2.24.
>
> something is very squiffy here, then, because it is possible to 'block up'
> highlights in BW neg to the extent that my sprintscan 4000 can't
> get through
> them, whereas I simply can't do that using any color neg, including Supra
> 100. Moreover, placing the negs side by side on a light table,
> the color neg
> subjectively lets more light through.
>
> I'm not saying you didn't read what you read on the densitometer,
> only that
> it's contrary not only to received wisdom (yeah, right) but also to my
> personal experience.

Send me any film you want to send me.  You know I have a pretty decent
densitometer, and I know how to use it (when I read the cal strips, they are
spot on)...I mean, put film in...press button and hold until it displays a
value...oh yeah, turn it on first ;-)


BTW, swuiffy?

on 9/26/01 8:14 PM, Austin Franklin at darkroom@... wrote:

> BTW, swuiffy?

as in 'I had six pints of beer  on an empty stomach and felt a bit squiffy'

-- 
John Brownlow

http://www.pinkheadedbug.com

--- In DigitalBlackandWhiteThePrint@y..., Johnny Deadman <john@p...> 
wrote:
> on 9/26/01 5:50 PM, Martin Wesley at mwesley250@e... wrote:
> 
> > Okay. I give up. You could have a 16-bit histogram utility that 
would
> > run quickly and display itself on our 96 dpi monitors with full
> > screen and zoom functions that would allow you to examine it in
> > detail. How come no one has written such a thing as a plugin for
> > Photoshop? I'd buy a copy.
> 
> ah, now that is a GOOD question!
> 
> time to download the Photoshop Plugin SDK!

Does that mean you are going to write the Plugin!?!?! :-)

Martin

Peter,

I don't think that the scanner has actually hit the stores yet. I 
would imagine that it is probably a very fine scanner and once it is 
in users' hands I hope we get some first hand user reviews.

The current discussion, in spite of the huge number of posts, has 
nothing to do with the actual performance of the Minolta DiMage Scan 
Multi PRO. The subject should have been changed way back there 
somewhere. It got started in reaction to the Minolta's marketing 
department's claims that are very misleading but do not mean there is 
anything wrong with the scanner.

Having a 16-bit A/D converter may not give the benefits they claim 
but it isn't going to hurt its performance either. The high level of 
detail mentioned in the review is probably a result of the 4800 dpi 
resolution on 35mm scans which beats any other scanner in this price 
range and/or better optics.

It took me a while to find the review on the site you mention and the 
exact page is:

http://www.imaging-resource.com/SCAN/DSMP/DSMA.HTM

The 6x7 scan time seemed to be very long! Over an hour. I believe 
that both the Nikon and the Polaroid are in the 5 to 10 minute range 
for the same film size at higher resolution (4000 over 3200).

I will really be glad to see this scanner arrive on the shelves and 
continue to stimulate higher quality at lower prices.

Martin


--- In DigitalBlackandWhiteThePrint@y..., "Peter" <peter139@h...> 
wrote:
> Wow, there is a whole lot of "techno babble" laced, pompous 
opinions about a
> device that apparently no one has used! To read the opinions that 
are
> expressed in this thread one could draw the conclusion that this 
unit is a
> piece of junk. Further, that the Minolta people are just a 
mendacious bunch
> and have just entered the commercial world of photography.
> 
> It is surprising that on this list of over 500 members who are 
involved in
> digital photography that no member has used this scanner and/or has 
seen a
> product of the machine. I have read the very recent and 
comprehensive review
> of this scanner at www.imaging-resource.com An excerpt from that 
review
> states:"...First and foremost, the Dimage Scan Multi Pro delivers an
> extraordinary level of detail, in this respect eclipsing all desktop
> scanners we've recently tested (September, 2001)...This is a 
scanner that
> takes a back seat to no one in image quality although it (sic) we 
found its
> scan times to be a little slow, at least on a Mac platform".
> 
> I wonder which marvelous scanner is being used by those on this 
list that is
> better than this Minolta model.
> 
> I do not now own or have a every owned or used a film scanner, have 
no bias
> about a Minolta or any other film scanner. I would like to read 
users'
> opinions about film scanners that would be useful in helping one 
make a
> prudent buying decision for a scanner in this category. I am not 
really

> interested in best quality for the price--only quality.
> 
> Peter Palmer

A 'good' histogram is not the holy grail - a good image is, even if the
histogram looks lousy.  Ask Dan Margulis about histograms - you'll get an
earful.

Just search for the word "histogram" at
http://www.ledet.com/margulis/ACT_postings/ACT-8-bit-16-bit.html

Maris

----- Original Message -----
From: "Martin Wesley" <mwesley250@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Wednesday, September 26, 2001 11:30 PM
Subject: [Digital BW] 16-bit histogram was Re: Bit depth, was Minolta DiMAGE
Scan Multi PRO


| --- In DigitalBlackandWhiteThePrint@y..., Johnny Deadman <john@p...>
| wrote:
| > on 9/26/01 5:50 PM, Martin Wesley at mwesley250@e... wrote:
| >
| > > Okay. I give up. You could have a 16-bit histogram utility that
| would
| > > run quickly and display itself on our 96 dpi monitors with full
| > > screen and zoom functions that would allow you to examine it in
| > > detail. How come no one has written such a thing as a plugin for
| > > Photoshop? I'd buy a copy.
| >
| > ah, now that is a GOOD question!
| >
| > time to download the Photoshop Plugin SDK!
|
| Does that mean you are going to write the Plugin!?!?! :-)
|
| Martin
|
|
|
|
| Please visit the Group Homepage to check the Files, Bookmarks, Polls and
other resources as they are often being updated. The page is at:
|
| http://groups.yahoo.com/group/DigitalBlackandWhiteThePrint
|
| Please follow these basic guidelines:
| - Include your full name with your message.
| - Include the address of your website, if you have one.
| - As threads develop, trim off excess portions of earlier messages to keep
them short.
| - As the topic of a thread changes remember to change the subject header.
| - Good manners are required at all time. No personal attacks or "flames."
| - Complete your Yahoo profile.
| - Before posting a question, search the message archives and the various
resources on the homepage.
|
|
|
|
| Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
|
|
|
|

Maris,

I wasn't looking to get a perfect histogram; I just want a better way 
to see what the data is doing. I have run the exercise of 
manipulating an 8-bit version of a 16-bit file to the point the 
histogram is terrible, then applied the same changes to the original 
16-bit files and then printed both. They were identical.

However, the histogram tool in Photoshop is not as useful as it could 
be. There is a transition area where the histogram looks terrible and 
the print is fine, but if you push the image past that point it may 
still look okay on screen but posterize when you print it. So if the 
histogram is good you will not get a posterized print but if the 
histogram is bad you MAY get a posterized print. The 8-bit histogram 
in Photoshop is not an absolute guide to print quality but it is an 
indication that you may be pushing the limits. I am just hoping for 
some better tools to see what is actually happening to the data on 
screen.

Martin

--- In DigitalBlackandWhiteThePrint@y..., "Maris V. Lidaka, Sr." 
<mlidaka@a...> wrote:
> A 'good' histogram is not the holy grail - a good image is, even if 
the
> histogram looks lousy.  Ask Dan Margulis about histograms - you'll 
get an
> earful.
> 
> Just search for the word "histogram" at
> http://www.ledet.com/margulis/ACT_postings/ACT-8-bit-16-bit.html
> 
> Maris
> 
(snip)

Austin,

You're doing a great job, I can sort of follow. BTW, this is a lot of work,
thanks! I guess I wont know if I've got this completely until we move
forward. I'll just ask a couple of questions, but only answer them if you
think they are relevant to building upon. I really don't want to sidetrack
the conversation too much.

Furthermore if you'd be answering any of these questions in the next part
anyway feel free to move on and do so in flow.
 
> CCD give you a range of voltage out of it.  That voltage range, no matter
> what it is, has noise in it.  That noise level will determine just how much
> signal to noise you can get from the CCD/analog "front end" (circuitry
> between the CCD and the A/D).  A CCD that can "look further into the dark
> regions" will have a lower noise level, and therefore a higher signal to
> noise ratio.
> 
> Now we have to match the CCD to the A/D, in two ways, one voltage, which we
> don't care about, it's done in the "front end", and second, the A/Ds ability
> to discern different values all way down to the noise level of the CCD/front
> end.  That's where the number of bits is important.  We need to have enough
> bits to represent from the minimum signal level out of the CCD/front end to
> the highest signal level out of the CCD/front end, and all discernable
> levels in-between that are above noise.

When you speak of noise, this is noise that is a by product of the scanners
circuitry, like hum, which I suppose3 has a certain predictability to it, or
noise like extra data bits that don't hold statistically meaningful data
bits. I guess I mean values which are too closely spaced to be
distinguishable as significantly different from one another. Would this be
non-integer ratio values? I'm a bit over my head here, but Dan Margulis
explained that when the scanner gets into the highest density regions it
doesn't just hit a wall and call everything that dense and denser black (in
the case of a chrome), it tend to sort of guess a value, and there is a
randomness to it. I think this is the noise we generally associate with
"noisy shadows" of a scan. But with negative materials this occurs in the
highlights of the IMAGE, though it's still considered shadow in this
context, correct? In the context of scanners, shadow is the film density
region, yes?
 
 
> The A/D measures the input voltages from the CCD/front end.  -3V would give
> an A/D output of 0, to +3 would give an A/D output of full scale, and for 15
> bits, that would be 32,767 decimal.  That is 32,768 different values.
 
> So, 0 represents as close to no light as the CCD can measure...the CCD is
> putting out no voltage...and 32,767 represents the highest amount of light
> you are calibrated to measure.  I could go into more detail about gain and
> calibration, but I believe that's another discussion.
> 
> The end voltage, and the intermediate voltages out of the CCD/front end are
> obviously also converted in to values between 0 and 32,767, and that is what
> is the raw output out of the A/D.  Those are the values that are assigned to
> the pixels.

Okay, to confirm, whatever tone the scanner measures to be darkest (or in
the case of the random noise I spoke of, assigns to be darkest) is assigned
the tonal value of zero, and each next whole integer value is assigned in
order up the scale? It is the A/D converters function to assign tonal values
to the voltages received by the CCD?
 
> Also, the reason more bit depth gives better dark detail is simple.  Note
> the value of -3 out of the CCD gives us a value of 0 out of the A/D.  Well,
> that means the scanner sees no light.  A voltage of .0003V out of the CCD
> would give us an A/D output of 1.  Remember, that this value of .0003 is the
> noise level of the CCD...and that it is simply because of the noise level
> that we require so many bits.  In order to see something between 0 and 1, we
> have to lower the noise level, say to .00015V.  That would give us 6V
> divided by .00015V number of values, or 40,000...which would require 16 bits
> to represent 40,000 different values.

So, the lower the noise, the more tones the front end can distinguish, and
the higher the bit depth (BD) of the A/D required, to keep up, so to speak?
With more noise you can get away with a lower BD A/D cause anything more is
wasted. Okay, so this is where the manufacturers claims become suspect
because they speak of the bit depth of their scanners relative to their A/Ds
without specifying the S/N ratio of the front end which is the primary
limiting factor?

In the instance where a manufacturer does put a high BD A/D in with a high
noise CCD, I get that you will still have a lot of shadow noise (which again
are tones which have bee spuriously assigned by the scanner, because it
can't truly distinguish them as discreet from one another, or from the noise
of the front end?). But when you get out of that threshold area, do you then
have more useable tones further along the scale than if you used the lower
BD A/D with that CCD?

> This should explain why bit depth limits dynamic range in a scanner (and the
> dark detail, not the light detail), and how the scanner "assigns" values to
> the data.  Let me know if you get this, any of this or none of this... Then
> we can move past it.

Nice job Austin. I think I'm getting it so far (roughly anyway). I look
forward to the next chapter. ;-)

Todd

> The 6x7 scan time seemed to be very long! Over an hour. I believe
> that both the Nikon and the Polaroid are in the 5 to 10 minute range
> for the same film size at higher resolution (4000 over 3200).

Hear that Austin? This baby's gonna give the unmentionable one a run for the
money!  ;-)

BTW, that scan time make me wonder. Does anyone know: is this a three pass
scanner?

Todd

on 9/27/01 1:10 AM, Maris V. Lidaka, Sr. wrote:

> A 'good' histogram is not the holy grail - a good image is, even if the
> histogram looks lousy.  Ask Dan Margulis about histograms - you'll get an
> earful.


Maris,

You may remember I had brought up some of these topics which we are
discussing around here now on Dan's list a couple of months ago. Below is
Dan's response to me. I think some of you might enjoy Dan's take on things,
I know I always do...

Todd

********

Todd writes,
 
>>I'm rather confused about the interaction/relationship of these concepts:
Dynamic Range, Bit Depth, and the Histogram.>>

Most people would say that these are three totally different concepts, but
in fact they are linked by a couple of common factors: 1) the effect of
random noise; 2) each one has managed to give birth to a myth that has
caused a lot of trouble to the color community.

What's random noise? Well, suppose you have two digital thermometers on
your wall. One of them tells you that it is currently 73 degrees. The other
one has more LEDs, and tells you that it is currently 72.86473 degrees.

The second one *sounds* more impressive, but in reality no thermometers are
that accurate. The last four digits for sure, and probably the last five
digits, are meaningless, empty numbers, of no validity at all. And yet they
are there.

This example relates to your three terms as follows.

*Dynamic Range* means the ability to discern detail at extremes of
lightness, darkness, or color. Positive film, for example, holds detail so
subtle in the deepest shadows that no scanner or digital cameras can see
it. Drum scanners do slightly better at picking up this detail than even
the most expensive CCD devices, so we say that the drum scanners have more
dynamic range, though less dynamic range than there is in the film.

The myth is that when the camera or scanner encounters something that's
outside of its dynamic range it hits a brick wall and just clips. IOW,
assume a digital photograph, or a scan from film, of a black cat at night.
If the scanning device really can't resolve the darkest area of the cat
because of inadequate dynamic range, some people suppose that what will
show up there is pure black. Not so. The scanner won't fail altogether, it
will *think* it sees something there and will try its damndest to show it
to you. Unfortunately, what it will show you is the last four digits of the
thermometer--just random pixels, meaningless noise, not black, but not a
cat either.

*Bit Depth* is a measure of how many distinct shades might theoretically
appear in a single channel. Each bit that's added doubles the number of
potential shades. The norm, 8-bit depth, has 256 possible shades, 9-bit
512, and 10-bit 1,024. When Photoshop encounters a file with more than
8-bit depth, it converts it to 16-bit, which has 65,536 possible shades.

The myth is that expanding a file to 16-bit somehow makes it more accurate.
Assuming for the sake of argument that your scanner really can record 1,024
accurate values per channel, going to 16-bit just packs it with the last
four digits of the thermometer: useless data, random numbers, mere noise,
of no statistical validity, of no benefit to the image. Furthermore, the
more I've studied it, the more I doubt that any current scanning device is
capable of getting even 500 accurate shades per channel, let alone 65,000.

The *Histogram* is an invention of the evil one for the express purpose of
retarding progress in the graphic arts. More people have been deluded by it
than by any other feature of Photoshop.

The myth is that a smoother histogram equates to a better-looking image.
Since the histogram doesn't reveal anything about the *significant* areas
of an image as opposed to the background, it's of extremely limited utility
in evaluating image quality. Nevertheless, if you have to guess at which of
two versions of an image will look better based solely on a histogram,
you'll be dollars ahead in the long run if you bet on the one that's less
smooth. The reason, again, is noise. The more random the image, the more it
resembles the last four digits of the thermometer, the smoother the
histogram will be. In the case of the image of the black cat discussed
above, the histogram for the shadows will definitely look better in the CCD
scan that is nothing but noise as compared to the drum scanner that
captures a certain amount of detail.

Dan Margulis

on 9/27/01 12:30 AM, Martin Wesley at mwesley250@... wrote:

>> ah, now that is a GOOD question!
>> 
>> time to download the Photoshop Plugin SDK!
> 
> Does that mean you are going to write the Plugin!?!?! :-)

no, but I might tinker

what would be nice would be a live histogram within PS, not a plugin I
think.
-- 
John Brownlow

http://www.pinkheadedbug.com

And how many angels CAN dance on the head of a pin???

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

> what would be nice would be a live histogram within PS, not a plugin I
> think.

YES!

> A 'good' histogram is not the holy grail - a good image is, even if the
> histogram looks lousy.  Ask Dan Margulis about histograms - you'll get an
> earful.

Well, Dan is not the holy grail either ;-)

It depends on what you mean by "good".  Smooth means NOTHING, but without
gaps means something.  Gaps in a histogram can show up as posterizing in
your image.

> but if you push the image past that point it may
> still look okay on screen but posterize when you print it.

With NO gaps in the histogram?  Do you mean the image may look OK on screen,
or the histogram may look OK on screen?  What's the "it" you refer to?

> So if the
> histogram is good you will not get a posterized print but if the
> histogram is bad you MAY get a posterized print.

Absolutely true.

> When you speak of noise, this is noise that is a by product of
> the scanners
> circuitry, like hum, which I suppose has a certain
> predictability to it, or
> noise like extra data bits that don't hold statistically meaningful data
> bits.

They are kind of both the same thing.  Typically, a system is designed such
that the data you get from the A/D won't contain noise, except in the lowest
bit(s).  The system should be designed above the noise.  All the bits, but
the LSB (least significant bit) should be valid in most cases, at least as
far as system noise goes...noise in the material to be scanned is a
different story.

> I guess I mean values which are too closely spaced to be
> distinguishable as significantly different from one another. Would this be
> non-integer ratio values?

There can be no non-integer ratio values in this type of system.  Since
everything is relative, as in, is a ratio...based on what the CCD/AD
measures as "1"...which is the noise floor, and since you can only measure
in increments of the noise, there are no intermediate values.  If you halve
the noise, you change the baseline ratio value (what was 1 is now 2, and
what would have been 1/2 if you could have measured it, is not 1), so you
still get no intermediate values.

I believe this (the ratio thing) is a very important concept to understand
by the way.

> I'm a bit over my head here, but Dan Margulis
> explained that when the scanner gets into the highest density regions it
> doesn't just hit a wall and call everything that dense and denser
> black (in
> the case of a chrome), it tend to sort of guess a value, and there is a
> randomness to it. I think this is the noise we generally associate with
> "noisy shadows" of a scan.

Yes, the lower bit(s) will be random, but that's what noise is.  Anytime the
low bits are "into the noise level" they will be random...  You can design a
system such that no bits are in the noise level, and the LSB will have a +-
1/2 value error...and will be subject to a small amount of noise...but I
disagree with Dan on this, it is very design dependant, and is not a general
rule.

> But with negative materials this occurs in the
> highlights of the IMAGE, though it's still considered shadow in this
> context, correct?

Yes, correct.  That is why all this "shadow detail" stuff isn't important to
negatives...only chromes.

> In the context of scanners, shadow is the film density
> region, yes?

Yes.

> Okay, to confirm, whatever tone the scanner measures to be darkest (or in
> the case of the random noise I spoke of, assigns to be darkest)
> is assigned
> the tonal value of zero, and each next whole integer value is assigned in
> order up the scale?

It depends on calibration...but suffice to say, 0 means the scanner can't
read anything...and 1 is really the baseline value the scanner starts
"reading" at.  Whatever the scanner determines has a value of 1, the value
of 2 is going to be twice as bright as 1.

> It is the A/D converters function to assign
> tonal values
> to the voltages received by the CCD?

YES!

> So, the lower the noise, the more tones the front end can distinguish,

in the dark region....

> and
> the higher the bit depth (BD) of the A/D required, to keep up, so
> to speak?

YES.

> With more noise you can get away with a lower BD A/D cause
> anything more is
> wasted.

YES.

> Okay, so this is where the manufacturers claims become suspect
> because they speak of the bit depth of their scanners relative to
> their A/Ds
> without specifying the S/N ratio of the front end which is the primary
> limiting factor?

YES ;-)

> In the instance where a manufacturer does put a high BD A/D in with a high
> noise CCD, I get that you will still have a lot of shadow noise
> (which again
> are tones which have been spuriously assigned by the scanner, because it
> can't truly distinguish them as discreet from one another, or
> from the noise
> of the front end?). But when you get out of that threshold area,
> do you then
> have more useable tones further along the scale than if you used the lower
> BD A/D with that CCD?

That's takes a bit of an explanation.  If you have a 20 bit A/D...and a CCD
whose noise really only give you 10 bits of good signal...you will get noise
in all the lower bits, throughout the entire scale...but that noise that is
between values won't really mean anything, but the noise at the end of the
scale will be the shadow noise.  So, no, you don't get more usable tones.

> Nice job Austin. I think I'm getting it so far (roughly anyway). I look
> forward to the next chapter. ;-)

Thanks.  I think I got the above right.  Let me know if I didn't understand
something you asked.

> > The 6x7 scan time seemed to be very long! Over an hour. I believe
> > that both the Nikon and the Polaroid are in the 5 to 10 minute range
> > for the same film size at higher resolution (4000 over 3200).
> 
> Hear that Austin? This baby's gonna give the unmentionable one a 
> run for the
> money!  ;-)

Is that for the new Minolta?  I didn't see the original message...

.                       .
.

http://groups.yahoo.com/group/ScanHi-End
.


.

> Let me know if I didn't understand
> something you asked.

No, you got me great, thanks! But there are a couple of points I'm still
squiffy on. ;-)  

> It depends on calibration...but suffice to say, 0 means the scanner can't
> read anything...and 1 is really the baseline value the scanner starts
> "reading" at.  Whatever the scanner determines has a value of 1, the value
> of 2 is going to be twice as bright as 1.

Okay, this whole ratio thing: when you talk about each next value being
assigned is the next value that is read as being twice as bright as the one
before it, I think of f-stops. How can there be thousands of f-stops of
brightness in the film. Wait, I think I get it. It's a similar logarithm,
but we must be talking different units of light. The amount of light, the
size of the bucket of light which makes the first unit we call f-stop, must
be monumentally larger than the first unit of light we call  -.00015 volts?
Something like that?

>> In the instance where a manufacturer does put a high BD A/D in with a high
>> noise CCD, I get that you will still have a lot of shadow noise
>> (which again
>> are tones which have been spuriously assigned by the scanner, because it
>> can't truly distinguish them as discreet from one another, or
>> from the noise
>> of the front end?). But when you get out of that threshold area,
>> do you then
>> have more useable tones further along the scale than if you used the lower
>> BD A/D with that CCD?
> 
> That's takes a bit of an explanation.  If you have a 20 bit A/D...and a CCD
> whose noise really only give you 10 bits of good signal...you will get noise
> in all the lower bits, throughout the entire scale...but that noise that is
> between values won't really mean anything, but the noise at the end of the
> scale will be the shadow noise.  So, no, you don't get more usable tones.

If DR is the height of the staircase, and bit depth is the number of steps
to it, I would think in the above scenario that the bottom few steps
(shadow) would contain a lot of noise, but once you got past them you'd have
more steps (discrete tones) throughout the rest of the spectrum. For
instance, if an 8-bit scanner gives you 256 tones of which say the first 6
may contain noise, you have 250 discreet clean tones further up the scale.
If you have a 10-bit scanner which gives you 1024 tones, and the first 6 (or
would it be the first 24?) contain noise, won't that give you 1018 (or 1000)
discreet clean tones further up the scale? Isn't this what you were talking
about when you suggested that higher bit scans should span more of the
histogram than lowbit scans of the same material? I'm still confused about
some of those seeming contradictions, which I explained in my "from scratch"
question. Know what I'm talking about?

Getting back to dynamic range, I see how bit depth can limit DR in that it
is tied in with noise, but what else determines dynamic range? As a for
instance, if Margulis is correct, drum scanners will typically have better
DR than CCDs, even though they might both be of the same bit depth.
Furthermore, even on CCD units, what the unit's DR tests out to be may be
very different than what it's spec sheet might suggest, even when they do
list it's S/N ratio; which, granted, is probably an optimistic estimation of
it's true S/N. But my point is, I would imagine two scanners from different
manufacturers could use the same CCD and the same A/D, and yield different
DR. Is it all related to noise suppression?

Another thing I need clarification on is low-bit vs high-bit justification.

Todd

> Okay, this whole ratio thing: when you talk about each next value being
> assigned is the next value that is read as being twice as bright
> as the one
> before it,

Not quite right.  The value of 2 is twice as bright as the value of 1, and
the value of 3 is three times a bright as 1 etc.  100 is twice as bright as
50.  But notice that it takes more values in-between to get 2x the further
up the scale you go.

> I think of f-stops. How can there be thousands of f-stops of
> brightness in the film.

There are intermediate f-stops in film.  One f-stop is only 2x as
bright/darker than the next successive one.  It's the area of a circle (the
aperture).  Twice the area means twice the light, 1/2 the area, means 1/2
the light.

f1 for a 50mm lense has an aperture width of 50mm, which is an area of
pi*r**2 (pi r squared), or 3.14 times 25**2 or 1,963 square mm.  f1.4 for a
50mm lense has a aperture width of 50 divided by 1.4 or 35mm.  The area of a
circle with a radius of 17.5 is 962.1....or, half of the area of the f1
aperture, and therefore lets in 1/2 as much light.  And...f2 has an area of
490 sq mm, and f2.8 has an area of 250 sq mm etc.

Again, it's a ratio thing...

> If DR is the height of the staircase, and bit depth is the number of steps
> to it,

That works for me...

> I would think in the above scenario that the bottom few steps
> (shadow) would contain a lot of noise, but once you got past them
> you'd have
> more steps (discrete tones) throughout the rest of the spectrum.

The noise is less significant the higher up you go.  It's quite simple.  As
I said, two is twice 1, obviously...and that is only one value
away...but...10,476 is one more than 10,475...but the difference is far less
significant.

> For
> instance, if an 8-bit scanner gives you 256 tones of which say the first 6
> may contain noise, you have 250 discreet clean tones further up the scale.
> If you have a 10-bit scanner which gives you 1024 tones, and the
> first 6 (or
> would it be the first 24?) contain noise, won't that give you
> 1018 (or 1000)
> discreet clean tones further up the scale?

Well, not quite...I'm actually trying to figure out a way of detailing this
exact scenario right now.  I'd rather hold off answering this until I work
it all the way through.

> Isn't this what you
> were talking
> about when you suggested that higher bit scans should span more of the
> histogram than lowbit scans of the same material?

That's only true if the data isn't high bit justified.  If the data is high
bit justified, then it will occupy the same span.

> Getting back to dynamic range, I see how bit depth can limit DR in that it
> is tied in with noise, but what else determines dynamic range?

NOTHING.  The pure definition of dynamic range is largest signal divided by
noise, period.  There are some other issues depending on what you are
talking about, but that's just a multiplication by some number...but it's a
constant and really doesn't effect the true definition.

> As a for
> instance, if Margulis is correct, drum scanners will typically have better
> DR than CCDs, even though they might both be of the same bit depth.

I don't know what you are referring to that Margulis said, but drum scanners
give cleaner data, which in turn does mean they have a better dynamic range.
They give cleaner data for a very simple reason.  They sample one pixel at a
time...and there is no cross talk between sensors.

> Furthermore, even on CCD units, what the unit's DR tests out to be may be
> very different than what it's spec sheet might suggest, even when they do
> list it's S/N ratio; which, granted, is probably an optimistic
> estimation of
> it's true S/N. But my point is, I would imagine two scanners from
> different
> manufacturers could use the same CCD and the same A/D, and yield different
> DR. Is it all related to noise suppression?

Pretty much, and design.

> Another thing I need clarification on is low-bit vs high-bit
> justification.

Phew...an easy one ;-)

I assume you know something about the binary system?  You know 8 bits is a
byte, and two bytes is (typically considered) a word (which is 16 bits)?  A
bit can either be 0 or 1, and each bit is a power of two...

1 = 1
10 = 2
100 = 4
1000 = 8

Therefore, 1010 is ten etc.  Anyway, say we have a 12 bit value from the A/D
of 1010_1010_1010 (the "_" are just nibble separators...a nibble is 4 bits).
When we put that value into a 16 bit number (16 bits is 4 nibbles
0000_0000_0000_0000) if we:

left justified, the number 1010_1010_1010 becomes 1010_1010_1010_0000 and
the decimal equivalent is 43,680.  If we right justify it, it is
0000_1010_1010_1010 and the decimal equivalent is 2,730.

As you can see, the left (high bit) justification gives a much larger number
than the low bit justification.  If you high bit justify, you basically
spread the numbers out, and they will occupy a wider range in the histogram.
If you just leave them right justified, then the will occupy a very small
range, but be contiguous values (if they were in the first place that is).

Is that kind of what you were looking for?

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" 
<darkroom@i...> wrote:
> 
> > but if you push the image past that point it may
> > still look okay on screen but posterize when you print it.
> 
> With NO gaps in the histogram?  Do you mean the image may look OK 
on screen,
> or the histogram may look OK on screen?  What's the "it" you refer 
to?

Austin,

Sorry, I was referring to the situation where the histogram has gaps, 
the onscreen image still looks good but when you print the image it 
posterizes. 

Martin

(snip)

> > > but if you push the image past that point it may
> > > still look okay on screen but posterize when you print it.
> >
> > With NO gaps in the histogram?  Do you mean the image may look OK
> on screen,
> > or the histogram may look OK on screen?  What's the "it" you refer
> to?
>
> Austin,
>
> Sorry, I was referring to the situation where the histogram has gaps,
> the onscreen image still looks good but when you print the image it
> posterizes.
>
> Martin

Yeah, I'd really like to see better monitors...higher resolution and better
tonality handling.  Something can look great on the screen, but because of
the very limited dynamic range of the screen...you don't see the "problems"
that show up on printing.  It could also be a calibration (gamma) issue?

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" 
<darkroom@i...> wrote:
> 
> > > The 6x7 scan time seemed to be very long! Over an hour. I 
believe
> > > that both the Nikon and the Polaroid are in the 5 to 10 minute 
range
> > > for the same film size at higher resolution (4000 over 3200).
> > 
> > Hear that Austin? This baby's gonna give the unmentionable one a 
> > run for the
> > money!  ;-)
> 
> Is that for the new Minolta?  I didn't see the original message...

Austin,

There is a review of the Minolta which includes sample scans, 
comparison Nikon 8000 scans and scan times at:

http://www.imaging-resource.com/SCAN/DSMP/DSMA.HTM

Martin

> There is a review of the Minolta which includes sample scans, 

Thanks.  Are the sample scans real or "simulated" ;-)

>> Another thing I need clarification on is low-bit vs high-bit
>> justification.
 
> As you can see, the left (high bit) justification gives a much larger number
> than the low bit justification.  If you high bit justify, you basically
> spread the numbers out, and they will occupy a wider range in the histogram.
> If you just leave them right justified, then the will occupy a very small
> range, but be contiguous values (if they were in the first place that is).
> 
> Is that kind of what you were looking for?

Austin

I have to admit, with my math impairment I'm not rock solid on the mechanics
of this, but that's okay, I just need to understand it well enough to
visualize the net result. I'm not quite there yet. But this is one of the
areas of this conversation I'd really like to understand, at least
superficially. Maybe if you speak a little to pros and cons of one over
another?

PS, This is a nice free short course! Are you okay with this? You aren't
obliged.

Todd

Yeah, I agree. If you represent the histogram as bar graph with a 1 pixel
line for each value then the graph would be many many screens wide.

That's not the only way to represent the information though. What if,
instead of the height of a line, you used a gray scale value to represent
the number of pixels at a given position (white for none, black for max
count). Then you could represent your histogram as an image, giving one
pixel of the "histogram image" to each of your 64K values. You could display
all that data in a 256x256 pixel square, something you could easily see
onscreen. Any white pixels in the "histogram image" would be the "gaps" in
your histogram. I think that would give you a manageable way of presenting
the data in a format that you could still interpret and get some value from.

-Jason

-----Original Message-----
From: Martin Wesley [mailto:mwesley250@...]
Sent: Wednesday, September 26, 2001 5:00 PM
To: DigitalBlackandWhiteThePrint@yahoogroups.com
Subject: [Digital BW] Re: Bit depth, was Minolta DiMAGE Scan Multi PRO


Jason,

You are right about the number of pixels to measure but I was
thinking about drawing the on screen representation with 65,000
individual bars in the bar graph as opposed to 256. Still might be
trival in terms of the actual computing power required I have to
admit.

Martin

> >> Another thing I need clarification on is low-bit vs high-bit
> >> justification.

> I'm not quite there yet. But this is one of the
> areas of this conversation I'd really like to understand, at least
> superficially. Maybe if you speak a little to pros and cons of one over
> another?

Hum.  Pro's and con's.  I don't know that there are any, per se, it's just a
way of storing the values.  Let's see if I can come up with some ;-)

You can't really make tonal adjustments on the low bit justified
data...because there are no gaps between the data...what you would do with
low bit justified data is set the setpoints, and then spread it out evenly
over the entire 16 bit range.  You could do the same with high bit justified
data...but with high bit justified data, it's already spread out so before
doing setpoints, you could do "some" level of tonal moves...not that you'd
want to without setting the setpoints first.

Low bit justified data would occupy a VERY small span of an 8 bit
histogram...where high bit justified data would occupy a region, say it was
12 bit data, then when high bit justifying the 12 bit data, the region would
be 16 times wider (4 bits is 16 times larger)...with 15 gaps in between
every valid data value.

Did that help?

Well it's brought out that I was under a false impression about raw data and
histograms, especially in light of the fact there was a justification
option.

I was always of the assumption that the raw data was invariably contiguous,
and therefore, the more it filled a histogram, the more tones you had to
work with. So I assumed that the larger it's span across the histo the
larger it's DR, ergo, the better the scan. Now I learn there is more than
one way to represent the data, and while it may look different it will
function essentially the same. IOW, one is no better than the other from a
quality standpoint, is that right?

If I adjust the setpoints of low bit justified data, to make it's histogram
look like that of the same scan which was high bit justified, would the gaps
appear in the same places as the high bit justified data, would the two
files be the same at that point?

I assume the Leaf is low bit justified, right? Are most?

Martin had sent me two raw files from the same image scanned on two
different scanners. I don't remember if both scanners have the same bit
depth though; lets assume they do. Before manipulations one's histogram
seemed much narrower than the other, so I naturally assumed the scan with
the wider histogram was the preferable scan. However, I casually expanded
each one to look decent, not even trying to make them look exactly alike,
and when I checked their histos after the adjustments I was surprised at how
alike they looked. Should I now assume that one scanner probably just low
bit justified the data, while the other high bit justified it's data?

Was this the conclusion of the discussion you were having with mike
yesterday, where, like you, I thought he was suggesting that scanners do
something of an auto levels on the data, but he was referring to something
else. Was it that he meant he thought most scanners should high bit justify
their data because it makes for a more full looking 8-bit histogram, which
would better impress novices like myself?

Thanks,
Todd

>>>> Another thing I need clarification on is low-bit vs high-bit
>>>> justification.
> 
>> I'm not quite there yet. But this is one of the
>> areas of this conversation I'd really like to understand, at least
>> superficially. Maybe if you speak a little to pros and cons of one over
>> another?
> 
> Hum.  Pro's and con's.  I don't know that there are any, per se, it's just a
> way of storing the values.  Let's see if I can come up with some ;-)
> 
> You can't really make tonal adjustments on the low bit justified
> data...because there are no gaps between the data...what you would do with
> low bit justified data is set the setpoints, and then spread it out evenly
> over the entire 16 bit range.  You could do the same with high bit justified
> data...but with high bit justified data, it's already spread out so before
> doing setpoints, you could do "some" level of tonal moves...not that you'd
> want to without setting the setpoints first.
> 
> Low bit justified data would occupy a VERY small span of an 8 bit
> histogram...where high bit justified data would occupy a region, say it was
> 12 bit data, then when high bit justifying the 12 bit data, the region would
> be 16 times wider (4 bits is 16 times larger)...with 15 gaps in between
> every valid data value.
> 
> Did that help?

> I was always of the assumption that the raw data was invariably
> contiguous,
> and therefore, the more it filled a histogram, the more tones you had to
> work with. So I assumed that the larger it's span across the histo the
> larger it's DR, ergo, the better the scan. Now I learn there is more than
> one way to represent the data, and while it may look different it will
> function essentially the same. IOW, one is no better than the other from a
> quality standpoint, is that right?

There is no difference in "quality" of data whether it's high bit or low bit
justified, it's the same data.

> If I adjust the setpoints of low bit justified data, to make it's
> histogram
> look like that of the same scan which was high bit justified,
> would the gaps
> appear in the same places as the high bit justified data, would the two
> files be the same at that point?

Technically, you could make them identical...but it's impractical to be able
to because you visually could not pick the exact points I doubt.

> I assume the Leaf is low bit justified, right? Are most?

No, I believe the Leaf is high bit justified.  I'm looking through the code
to see...but from looking at the 16 bit data on the Mac, it appears to be
high bit justified...  A B&W 16 bit scan occupied the range from 0 to
64...and if it was low bit justified, that would be a HUGE dynamic
range...if I had a 16 bit histogram with zoom etc., I would be able to tell
;-)

> Martin had sent me two raw files from the same image scanned on two
> different scanners. I don't remember if both scanners have the same bit
> depth though; lets assume they do. Before manipulations one's histogram
> seemed much narrower than the other, so I naturally assumed the scan with
> the wider histogram was the preferable scan. However, I casually expanded
> each one to look decent, not even trying to make them look exactly alike,
> and when I checked their histos after the adjustments I was
> surprised at how
> alike they looked. Should I now assume that one scanner probably just low
> bit justified the data, while the other high bit justified it's data?

That could very well be the cause.  Was one 4x narrower than the other, or
something like that?

> Was this the conclusion of the discussion you were having with mike
> yesterday, where, like you, I thought he was suggesting that scanners do
> something of an auto levels on the data, but he was referring to something
> else.

Yes.  He apparently did not mean that the setpoints (auto levels) were being
set...

> Was it that he meant he thought most scanners should high
> bit justify
> their data because it makes for a more full looking 8-bit histogram, which
> would better impress novices like myself?

Yes, apparently so ;-)

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> 
wrote:
(snip)

> 
> Martin had sent me two raw files from the same image scanned on two
> different scanners. I don't remember if both scanners have the same 
bit
> depth though; lets assume they do. Before manipulations one's 
histogram
> seemed much narrower than the other, so I naturally assumed the 
scan with
> the wider histogram was the preferable scan. However, I casually 
expanded
> each one to look decent, not even trying to make them look exactly 
alike,
> and when I checked their histos after the adjustments I was 
surprised at how
> alike they looked. Should I now assume that one scanner probably 
just low
> bit justified the data, while the other high bit justified it's 
data?
>

Todd, Austin,

The two scanners had the same bit depth, 14-bit. One was a Linoscan 
1400 flatbed running under Vuescan that gave a 16-bit file with an 
extremely compressed histogram. The second was a Polaroid SprintScan 
120 running under Polacolor Insight which gave a 16-bit file whose 
histogram was about 3 times wider for the same image.

My question is that how do we know we are getting a raw scan? We have 
to interface to the scanner with a piece of software on the computer 
and the firmware in the scanner itself. I know vuescan states that if 
it cannot access the 12 or 14 bit mode of the scanner it takes 8-bit 
data and places it in a 16-bit space but does not indicate whether it 
is doing this or not. I seem to recall that some 12 and 14-bit 
scanners scan at the bit depth but only output 8-bit.

Is there anyway to tell what bit depth was actually written to the 16-
bit "raw" scan file?

Martin


(snip)

Or, to make things simple to program...
Two 256pixel wide windows: Top window shows 8 bit histogram, as you move
mouse over this, or perhaps click on a cursor-key, or whatever, the bottom
histogram could show you the 256 level wide detail of a particular 'hi-8-bit
value'.

Does that make sense?

Not quite a zooming / panning / all singing histo, but should be relatively
simple and quick to implement and run. At least... for those programs that
even bother to allocate a whole 256 pixels of screen real-estate to what
they must perceive as a boring histogram ;)

Nij

> -----Original Message-----
> From: Jason DeFontes [mailto:jason@...]
> Sent: 27 September 2001 20:23
> To: DigitalBlackandWhiteThePrint@yahoogroups.com
> Subject: RE: [Digital BW] Re: Bit depth, was Minolta DiMAGE Scan Multi
> PRO
>
>
> Yeah, I agree. If you represent the histogram as bar graph with a 1 pixel
> line for each value then the graph would be many many screens wide.
>
> That's not the only way to represent the information though. What if,
> instead of the height of a line, you used a gray scale value to represent
> the number of pixels at a given position (white for none, black for max
> count). Then you could represent your histogram as an image, giving one
> pixel of the "histogram image" to each of your 64K values. You
> could display
> all that data in a 256x256 pixel square, something you could easily see
> onscreen. Any white pixels in the "histogram image" would be the "gaps" in
> your histogram. I think that would give you a manageable way of presenting
> the data in a format that you could still interpret and get some
> value from.
>
> -Jason
>
>

Nij,

An excellent idea and another example of what could be done with the 
histogram in Photoshop that seems like a rather trivial piece of 
programming. Has the histogram always been like this? At what version 
level did it appear and has it evolved at all?

Martin

--- In DigitalBlackandWhiteThePrint@y..., "Nij" <nigel@m...> wrote:
> Or, to make things simple to program...
> Two 256pixel wide windows: Top window shows 8 bit histogram, as you 
move
> mouse over this, or perhaps click on a cursor-key, or whatever, the 
bottom
> histogram could show you the 256 level wide detail of a 
particular 'hi-8-bit
> value'.
> 
> Does that make sense?
> 
> Not quite a zooming / panning / all singing histo, but should be 
relatively
> simple and quick to implement and run. At least... for those 
programs that
> even bother to allocate a whole 256 pixels of screen real-estate to 
what
> they must perceive as a boring histogram ;)
> 
> Nij
> 
> 
> 
> > -----Original Message-----
> > From: Jason DeFontes [mailto:jason@d...]
> > Sent: 27 September 2001 20:23
> > To: DigitalBlackandWhiteThePrint@y...
> > Subject: RE: [Digital BW] Re: Bit depth, was Minolta DiMAGE Scan 
Multi
> > PRO
> >
> >
> > Yeah, I agree. If you represent the histogram as bar graph with a 
1 pixel
> > line for each value then the graph would be many many screens 
wide.
> >
> > That's not the only way to represent the information though. What 
if,
> > instead of the height of a line, you used a gray scale value to 
represent
> > the number of pixels at a given position (white for none, black 
for max
> > count). Then you could represent your histogram as an image, 
giving one
> > pixel of the "histogram image" to each of your 64K values. You
> > could display
> > all that data in a 256x256 pixel square, something you could 
easily see
> > onscreen. Any white pixels in the "histogram image" would be 
the "gaps" in
> > your histogram. I think that would give you a manageable way of 
presenting

> > the data in a format that you could still interpret and get some
> > value from.
> >
> > -Jason
> >
> >

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> 
> Was this the conclusion of the discussion you were having with mike
> yesterday, where, like you, I thought he was suggesting that scanners do
> something of an auto levels on the data, but he was referring to something
> else. Was it that he meant he thought most scanners should high bit justify
> their data because it makes for a more full looking 8-bit histogram, which
> would better impress novices like myself?
> 
> Thanks,
> Todd

	I wasn't really saying most should, I was just wondering why they 
didn't since they are incapable of capturing anything out of their 
range anyway. It is kinda like having an oven that only goes to 500 
degrees but the temperature gauge goes to 2000.

 	I would actually prefer it if they didn't so that I can see just 
how much tonal information I am working with (which is really the only 
way to know without a high bit histogram, yes?)

-mikeH

Thanks Martin ;)

I don't have the history on Photoshop, let alone PS Histograms. I know that
as a programmer a couple of years ago, I wouldn't have had the sensibilities
that I now have as a photographer and part-time scanner operator.

However, a little thought suggests a few basic things:
Like:
Why did Nikon make their NikonScan histogram resizeable - but not resizeable
up to 256 pixels across <doh>
And:
I suspect that a bit of programming effort goes into ensuring that 'the
graph' fits onto the available space. However, it would be nice if there was
an 'actual data' mode... most values in this case would clip (especially in
8 bit mode) - but it would be fantastic for seeing where there were actual
'shadow' / highlight data. IOW- the scale of many histograms forces this
data into being indistinguishable from the X axis. This isn't a big deal -
but would enable the user to visually decide what is 'noise' data and what
is real texture data. The user could then set end-points by inspection,
where the computer can physically count the pixels to clip 0.05% of pixels,
or whatever.

This last suggestion may be what I sometimes see as 'auto clipping'
selection on a histogram... but I suspect this is not the case as it just
alters the curves SLIGHTLY, mostly. Thought experiments suggest that even
with a small picture, showing real data would clip the majority of values on
the graph.

All this has me thinking - are there other ways to draw our data, and would
it be useful? e.g. for colour images - could you draw a 3d graph of where
the data in your image is in the colour space? Think it might be a nightmare
to come up with that, but if you could... ??? Maybe we shouldn't go there!

Nij

> -----Original Message-----
> From: Martin Wesley [mailto:mwesley250@...]
>
> Nij,
>
> An excellent idea and another example of what could be done with the
> histogram in Photoshop that seems like a rather trivial piece of
> programming. Has the histogram always been like this? At what version
> level did it appear and has it evolved at all?
>
> Martin

> I suspect that a bit of programming effort goes into ensuring that 'the
> graph' fits onto the available space. However, it would be nice
> if there was
> an 'actual data' mode... most values in this case would clip
> (especially in
> 8 bit mode) - but it would be fantastic for seeing where there were actual
> 'shadow' / highlight data. IOW- the scale of many histograms forces this
> data into being indistinguishable from the X axis. This isn't a big deal -
> but would enable the user to visually decide what is 'noise' data and what
> is real texture data. The user could then set end-points by inspection,
> where the computer can physically count the pixels to clip 0.05%
> of pixels,
> or whatever.

Something I think might be useful to me is for me to be able to identify
what on the histogram corresponds to what on the image...like when you mouse
over the image, the histogram highlights that value...and vice versa...

--- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley" <
mwesley250@e...> wrote:
> Nij,
> 
> An excellent idea and another example of what could be done with the 
> histogram in Photoshop that seems like a rather trivial piece of 
> programming. Has the histogram always been like this? At what version 
> level did it appear and has it evolved at all?
> 
> Martin

I started using photoshop with version 1.0 and as far as I can remember 
it had a similar histogram. I think the extra stats like count, mean, 
standard dev etc... and the ability to "mouse over" were added later. 
The histogram itself may have been only available in the levels box. 
Maybe I'll hook up my old computer and see.  Back when I was using 
photoshop 1.0 the histogram didn't mean much (with the super small, 
indexed color work I was doing at the time. I think the video card was 
only 8bit)

-mikeH

> I wasn't really saying most should, I was just wondering why they
> didn't since they are incapable of capturing anything out of their
> range anyway. It is kinda like having an oven that only goes to 500
> degrees but the temperature gauge goes to 2000.

I understand what you're saying...but if you could only buy 2000 degree
temperature gauges, by standard, then your example would be closer to being
the same in my opinion.  Temperature can't be scaled to fit the thermometer.
It's the computer that defines some multiple of 8 bits for storage, so
that's really your only choice!  There were 12 bit machines some years ago,
and now if you could only get Adobe to write a 12 bit PS for you ;-)

As you said in another post, you don't lose any information between low bit
justification and high bit justification.  According to Ed, Viewscan high
bit justifies the raw scans it does, so it you want that, you can get that
from Viewscan...

I believe since there is no standard, and since both methods need to have
the setpoints set anyway in order to be really useful, and after "setpoint
expansion", the results are the same...no one really cared...there's no
really compelling reason to do it one way or the other as far as I can see.
If you want true raw data to be just that, raw...as in straight off the
A/D...that would mean low bit justified.

> 
> I started using photoshop with version 1.0 and as far as I can remember
> it had a similar histogram. I think the extra stats like count, mean,
> standard dev etc... and the ability to "mouse over" were added later.
> The histogram itself may have been only available in the levels box.
> Maybe I'll hook up my old computer and see.  Back when I was using
> photoshop 1.0 the histogram didn't mean much (with the super small,
> indexed color work I was doing at the time. I think the video card was
> only 8bit)
> 
> -mikeH
> 

One can see what each part of the histogram represents on the image, by
going on Image>Adjust>Threshold . Move the slider to the sides, and the b&w
image will show what's on where the slide is.
Hope this helps,
-- 
Rodolpho Pajuaba
www.pajuaba.com.br

>
> One can see what each part of the histogram represents on the image, by
> going on Image>Adjust>Threshold . Move the slider to the sides,
> and the b&w
> image will show what's on where the slide is.
> Hope this helps,
> --
> Rodolpho Pajuaba
> www.pajuaba.com.br

Nice tip, but what it does isn't what you may believe...it only thresholds
the data and distinguishes the parts of the image above and below that
point, not what IS that point.  The point also has no 'value' to it...which
would be nice to have.  It would be even nicer if it had a range you could
set ;-)

> The point also has no 'value' to it...which would be nice to have.

It does display the value, it was covered by another window...sorry.

>> Was this the conclusion of the discussion you were having with mike
>> yesterday, where, like you, I thought he was suggesting that scanners do
>> something of an auto levels on the data, but he was referring to something
>> else. Was it that he meant he thought most scanners should high bit justify
>> their data because it makes for a more full looking 8-bit histogram, which
>> would better impress novices like myself?
>> 
>> Thanks,
>> Todd
> 
> I wasn't really saying most should, I was just wondering why they
> didn't since they are incapable of capturing anything out of their
> range anyway. It is kinda like having an oven that only goes to 500
> degrees but the temperature gauge goes to 2000.
> 
> I would actually prefer it if they didn't so that I can see just
> how much tonal information I am working with (which is really the only
> way to know without a high bit histogram, yes?)
> 
> -mikeH

Mike, 

I hope my question didn't sound condescending-- It wasn't meant to be. I'm
purely playing catch-up with you guys. I never knew there was a
justification option, and now that I do it's thrown my notion of a raw
scan's histogram into chaos. I see your point, that from a scanner maker's
point of view highbit justification *could* unduly impress some of us.
Furthermore, I still don't get why we get the 2000 degree dial on the 500
degree oven; why a piece of film with a 3.7 DR will span only a portion of a
histogram, even IF highbit justified.

Anyway, I have great respect for your knowledge, make no mistake about that!

Todd

> I never knew there was a
> justification option, and now that I do it's thrown my notion of a raw
> scan's histogram into chaos.

It's still truly raw data either way...it's just how it's represented.

> why a piece of film with a 3.7 DR will span only a
> portion of a
> histogram, even IF highbit justified.

A piece of film with a 3.7 DR SHOULD span (most of) the entire histogram if
high bit justified, and the scanner has a maximum dynamic range of 3.7
(which would really be 3.6, or 12 bits...).

on 9/28/01 1:48 PM, Austin Franklin wrote:
 
>> I never knew there was a
>> justification option, and now that I do it's thrown my notion of a raw
>> scan's histogram into chaos.
> 
> It's still truly raw data either way...it's just how it's represented.
> 
>> why a piece of film with a 3.7 DR will span only a
>> portion of a
>> histogram, even IF highbit justified.
> 
> A piece of film with a 3.7 DR SHOULD span (most of) the entire histogram if
> high bit justified, and the scanner has a maximum dynamic range of 3.7
> (which would really be 3.6, or 12 bits...).

Our beloved unmentionables presumably scan at 14-bit, and reputedly capture
a DR of around 3.7, and you believe are highbit justified, yes? If I scan a
chrome and include in that scan portions which contain blown out highlights
(pure film base) and unexposed film base (frame edge) I should likely be
scanning film with a DR close to or exceeding 3.7, yes? But my data will
still span only perhaps 1/3 or 1/4 of of the histogram. What gives? It's
because it's 14 data in 16 bit space? How does that jive with the case that
the histo would be the same from a 16 bit scanner, or a 12 bit scanner. I
still don't get how the histograms should relate to each other when they are
made by different bit depth scanners.

If you could state what would occur in each of these scenarios it would be
marvelous.

1). Scan a tonally flat piece of film on a 12 bit, 14 bit and 16 bit
scanner. The DR of the film is low enough that all of these scanners can
capture the films full DR. How will their histograms compare? How will they
compare if all scanners low bit justify, and how will they compare if all
scanners high bit justify?

2). Same as above, but this piece of film has a higher DR, such that it
exceeds that of the 12 bit scanner, is exactly that of the 14 bit scanner,
and less than that of the 16 bit scanner. How do their histos look in each
of the justification instances?

I understand there probably are no 16 bit scanners, so you can either
discuss it theoretically, or just adjust all the scanners bit depths down a
notch or so.

Any other scenarios that would be useful to compare?

Ah,

3). Due to different noise levels three scanners of EQUAL bit depth have
different DR capability. A piece of film is scanned which has a DR which
exceeds one of the scanners, is exactly at that of one of the scanners, and
exceeds that of the third. Compare their histograms.

Did you eat your Wheaties today? Heck, I think I owe you a shepherd's pie
and a few pints for this. ;-)

Anyway, if you can condense this and still address the confusion that's okay
by me.

Thanks,
Todd

Sorry if I come so late to this thread, and take back the discussion to
histograms, but I've been away from the list for a while, and I'm very
interested in this topic. Having just bought a Canon FS4000, I started
working on the ultimate workflow from scan to print, and deciding whether to
work on 8 or 16 bits was obviously one of the issues involved. What I did,
on a few images, was to save the 16bit file, duplicate and convert to 8bit,
made ALL changes to the duplicate using layers and masks, and then apply
exactly the same transformations to the same areas on the 16 bit image,
starting from the bottom layer upwards (as I think Photosop works when
applying layers), and finally convert this image to 8 bits, too.
What did I get? A BIG difference in histograms (smooth here, combed there),
given that often the layers were 5 or more (although most of them masked to
a small part of the image), NO visual difference, even zooming in heavily.
Can someone with enough Photoshop knowledge explain this? I think this may
help to understand the relationship between an image and its histogram, and
why an histogram isn't the holy grail.
 
Alessandro Pardi

-----Original Message-----
From: Todd Flashner [mailto:tflash@...]
Sent: giovedì 27 settembre 2001 08.39
To: DigitalBlackandWhiteThePrint@yahoogroups.com
Subject: Re: [Digital BW] 16-bit histogram /Dan Margulis' take on some of
this


on 9/27/01 1:10 AM, Maris V. Lidaka, Sr. wrote:

> A 'good' histogram is not the holy grail - a good image is, even if the
> histogram looks lousy.  Ask Dan Margulis about histograms - you'll get an
> earful.


Maris,
 
 



[Non-text portions of this message have been removed]