Digital BW, The Print

----- Original Message -----
From: "Austin Franklin" <darkroom@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Friday, October 11, 2002 12:26 PM
Subject: RE: [Digital BW] Re: 'combed' histograms in 16 bit ?


> Hi Martin,
>
> > As an example lets say the scan originally came from a 12-bit scanner
and
> > the 12-bit data was mapped accurately into 16-bit space (each
> > 12-bit value X
> > 16) so that in 16-bit space there are pixels at intervals of 16 levels
or
> > tones.
>
> Well, actually that gets me to another point, thanks, but I'll answer this
> one first.
>
> 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.

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

Or is the highest value mapped to 56,000 and the lowest to 56,000 - 2500 =
53,500? 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.

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.?
>
> Why I say this, is when I look at my HDR files from my Leaf using the
> histogram in PS, they do exactly as I say.  What I then have to do, is set
> the setpoints FIRST, which expands the tonal range (disperses it) over the
> entire 16 bit range.  Then I apply the tonal curves.
>
> It's the setpoints that are critical....and only after that is done, is
the
> data expanded over the entire 16 bit range

Agreed, or less if the final output will not contain full black or full
white.

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

(snip earlier)
>
> > Assuming you had a "perfect", full range, 12-bit scan there would be
4096
> > tones in the original 16-bit scan but after manipulation it might
> > be reduced
> > to a lower number. It is still going to be much more than 256, so when
you
> > do a mode change to 8-bit wouldn't be likely that in mapping and
throwing
> > out tones that the gaps get totally or partially filled in so that the
> > histogram of the 8-bit version of the file looks smoother?
>
> No.  Mapping to 8 bits should only be a matter of lopping off lower bits.
> What PS MAY do is round up or down...sigh.  That would cause the histogram
> to change.

I am trying to understand what you mean by "lopping off the lower bits." 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. 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.

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

(snip)
>
> > What I would love to see on the Histogram display, which does not
> > seem like
> > it would be difficult, is first the bit depth of the file being
> > analyzed and
> > a display of the number of discrete tones or levels in the file. This
last
> > would be a great help in determining the amount of data loss caused by
any
> > adjustment or action.
>
> Agreed.

How difficult would this be for a programmer to create as a plug-in for
Photoshop?
>
> 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.

Martin