Digital BW, The Print

Hi Martin,

> > What you say, isn't what happens, at least with my experience.  For raw
> > data, the 12 bit values simply occupy a "portion" of the 16 bit "space".
> > The other part is, your scan isn't going to occupy the entire
> 12 bit space
> > anyway, only a portion of that...
>
> Austin,
>
> I agree. In real life you are not going to perfectly fill the 12-bit range
> and from experience with raw scans they appear very narrow once they have
> been mapped to 16-bit space.

Exactly.

> So as an example let's say that a raw scan of a particular negative from a
> 12-bit scanner produces 2500 levels with the highest falling on
> say 3500 and
> the lowest on 1000. I assume that in 12-bit space these 2500
> levels are all
> adjacent without any levels that have no pixels (assuming it is a
> continuous
> tone negative.)

Exactly correct again, except that there is no such thing as 12 bit space,
12 bit space IS 16 bit space.

> Now when this is mapped to 16-bit space let if
> each level is
> multiplied by 16 then the highest value would be on 56,000 and
> the lowest on
> 16,000 giving a spread of 40,000 in 16-bit space.

Nope...it is simply the exact same values, except there are four more high
bits, the data is exactly the same.

> Or is the highest value mapped to 56,000 and the lowest to 56,000 - 2500 =
> 53,500?

No...again, the data values are EXACTLY the same, 1000-3500, all contiguous.

> This second case seems unlikely from the raw scans I have
> seen from
> 12-bit scanners. 2500 adjacent levels in 16-bit space would be extremely
> narrow when you looked at a histogram.

Yes, it is very narrow.

> So, if the first case is correct, in 16-bit space are there then 15 levels
> with not pixels at those values between each of the mapped
> values? In other
> words is the highest level in my example now 56,000 and the next lowest
> value 55,984, then 55,968, etc.?

No.

> ...but remember one little thing,
> > 16 bits in PS, is really only 15 bits...
>
> Does this explain the fact that the histogram shown in Levels differs from
> the histogram you see with Image>Histogram?

I honestly don't know.

> > So, now that that's out of the way...my "other" point that you queued me
> on,
> > was what is the disposition of the 16 bit file that the
> original post was
> > talking about...was it a file that was "setpointed", because if
> it wasn't,
> > it has to be before really doing anything else...
>
> I suspect it may have been a victim of a phenomenon in Silverfast
> where you
> can specify a gamma setting to be applied to the raw scan on the fly which
> then of course it is not really a raw scan.

You should not apply ANY tonal curve adjustment to raw data until you
setpoint it, for obvious reasons!

> When you open this
> "raw", gamma
> adjusted file directly in PS it initially has a good histogram but after
> applying Levels the histogram looks mildly combed. No full gaps
> but it gets
> rather spiky. Doing a raw scan in Silverfast and not applying the gamma
> setting seems to avoid this issue.

That is exactly what I would suspect would happen if you apply tonal changes
to un-setpointed data.

> I am trying to understand what you mean by "lopping off the lower
> bits."

16 bit 1001_1011_1000_0101 converted to 8 bit -> 1001_1011

> So
> in my example the highest value was 56,000 or 01101101011000000 and in
> converting it to 8-bit PS drops the last 8 digits of the binary number
> giving 011011010 or 218.

Sounds right, but I won't check your arithmetic ;-)

 The lowest value in the example, 16,000 or
> 00011111010000000, becomes 000111110 or 62? (excuse the leading zeros as
> place holders.)
>
> If this is correct then the next lowest value in 16-bit space (mapped from
> 12-bit) would be 55,984 or 01101101010110000 and it is mapped to 218 also.
> All 16-bit values from 55,553 though 56,000 would be mapped to
> 218 in 8-bit
> space.

Sounds right.

> In the end though it may depend upon how the programmer decided to set up
> the software. You could write the program to map the levels above
> 56,000 to
> 218 or use 56,000 as a center point of the range of values to map
> to 218 or
> whatever really.

That's why I said in another post that they may do rounding...though I feel
it is entirely unnecessary.

> How difficult would this be for a programmer to create as a plug-in for
> Photoshop?

Not very, there are thousands of them available, and a plug-in SDK (Software
Development Kit) is available free from Adobe.

> > I'm not sure we answered any questions, but all I can think of,
> is the 16
> to
> > 8 conversion is not a simple lopping off of bits...
> >
> Well I think I am getting a better idea of what is going on and I
> appreciate
> the explanations.

I think I am  as well!

Regards,

Austin