Digital BW, The Print

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


(snip earlier)

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

Austin,

I see, it is not coming from a 12-bit space but rather is a stream of data
with values that will fall between 0 and 2^12-1.
>
> > 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.

Okay understood. I guess my misunderstand comes from the fact that the
histograms I see of raw scabs, while narrow, are often considerably larger
the 6% of the 16-bit range I would have expected. However since the
histograms are 8-bit I guess we cannot take them literally.

So we have 2500 adjacent levels in 16-bit space. Obivously then if you do
any gamma, curves or similar adjustment without first adjusting the end
points outward you will lose or damage the data. pixels will be moved from
one level to another level and added to the pixels already at that level
resulting in spikes and gaps in the data reducing the number of total
levels.

If you spread or remap the end points on your data set first, you create
room to move the pixels from one level to another without adding them to a
level that already contains pixels or at least reduce the certainty to a
possibility. With our example of 2500 adjecent level from 1000 to 3500 in
16-bit space let's say we move the 3500 value to 65,000 and the 1000 value
to 10. We still only have pixels assigned to 2500 discrete levels but those
levels are now scattered across a range of 64,000 possible levels and while
moving them around during adjustments the chances of their interferring with
eachother is small. Am I tracking this correctly so far?
>
> > 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.?
>
(snip)
> >
> > 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!

Believe it or not Silverfast is designed to do just that if you check a
certain option box.
>
> > 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.

Well this makes a lot more sense. If you know what is going on the problem
is easy to avoid.
>
(snip)
>
> > 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 ;-)

Sorry about that. No experience in working with binary. Forgot 16-bit space
is not 2^16 but 0 to (2^16)-1.
>
(snip)
>
> > 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.

Well if there are any programers lurking out there who would like to take
this on I will buy a copy!

Thanks for helping me sort this out.

Martin