Digital BW, The Print

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