Digital BW, The Print

after minor contrast adj in 16 bit scans (moving the end sliders to 
the edges of the histogram & the middle to fix the mid tones), I 
still have 'drop out' or combed histograms - any ideas, tips ?
thanks
Frank

--- In DigitalBlackandWhiteThePrint@y..., "frankg_photo" <frank@f...> wrote:
> after minor contrast adj in 16 bit scans (moving the end sliders to 
> the edges of the histogram & the middle to fix the mid tones), I 
> still have 'drop out' or combed histograms - any ideas, tips ?

Convert the file to 8 bits THEN look at the Histogram. You should see NO 
combs.

> --- In DigitalBlackandWhiteThePrint@y..., "frankg_photo"
> <frank@f...> wrote:
> > after minor contrast adj in 16 bit scans (moving the end sliders to
> > the edges of the histogram & the middle to fix the mid tones), I
> > still have 'drop out' or combed histograms - any ideas, tips ?
>
> Convert the file to 8 bits THEN look at the Histogram. You should see NO
> combs.

But the histogram IS an 8 bit histogram...  It should look the same,
providing no tonal adjustments are done, and I don't believe simply
converting from 16 bit to 8 bit should do that...it only "lops" off the
lower 8 bits.

Austin

Andrew,
I duplicated the 16 bit file and converted to 8bit - then compared 
the histograms - you are right there is less combing viewed in 88 
bit - but it's still there albeit not quite as bad as in 16

?
Frank
> > after minor contrast adj in 16 bit scans (moving the end sliders 
to 
> > the edges of the histogram & the middle to fix the mid tones), I 
> > still have 'drop out' or combed histograms - any ideas, tips ?
> 
> Convert the file to 8 bits THEN look at the Histogram. You should 
see NO 
> combs.

Can anyone explain why it would even be any different?  It should be the
exact same data...and as I said, the histogram is an 8 bit histogram, no
matter whether the file is, 8 bits or 16 bits.  When displaying a 16 bit
file, the low 8 bits are simply ignored...and when converting a 16 bit file
to 8 bits, simply the lower 8 bits are dropped...so they should be the same?

On the bottom of the histogram you are looking at the 16 bit file on, isn't
the scale 0-255?

Austin

> Andrew,
> I duplicated the 16 bit file and converted to 8bit - then compared
> the histograms - you are right there is less combing viewed in 88
> bit - but it's still there albeit not quite as bad as in 16
>
> ?
> Frank
> > > after minor contrast adj in 16 bit scans (moving the end sliders
> to
> > > the edges of the histogram & the middle to fix the mid tones), I
> > > still have 'drop out' or combed histograms - any ideas, tips ?
> >
> > Convert the file to 8 bits THEN look at the Histogram. You should
> see NO
> > combs.

yes, that is the scale.
> 
> On the bottom of the histogram you are looking at the 16 bit file 
on, isn't
> the scale 0-255?
> 
> Austin
> 
> 
> > Andrew,
> > I duplicated the 16 bit file and converted to 8bit - then compared
> > the histograms - you are right there is less combing viewed in 88
> > bit - but it's still there albeit not quite as bad as in 16
> >
> > ?
> > Frank
> > > > after minor contrast adj in 16 bit scans (moving the end 
sliders
> > to
> > > > the edges of the histogram & the middle to fix the mid 
tones), I
> > > > still have 'drop out' or combed histograms - any ideas, tips ?
> > >
> > > Convert the file to 8 bits THEN look at the Histogram. You 
should
> > see NO
> > > combs.

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


> Can anyone explain why it would even be any different?  It should be the
> exact same data...and as I said, the histogram is an 8 bit histogram, no
> matter whether the file is, 8 bits or 16 bits.  When displaying a 16 bit
> file, the low 8 bits are simply ignored...and when converting a 16 bit
file
> to 8 bits, simply the lower 8 bits are dropped...so they should be the
same?

Austin,

I am still trying to get a better grasp on what is happening with the data
during scanning and mode changes. So see if I am correct in the following.

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. If you did a strong levels or other adjustment on this 16-bit file
wouldn't the spacing change so that in some portions of the 16-bit range
data points are brought closer together, even overlapping giving the
"spikes" seen in histograms, and in others portions of the 16-bit range they
are spread farther apart than intervals of 16. To see a gap in the 16-bit
file, 65,535 levels, with an 8-bit histogram tool it would have to be 256
16-bit levels wide, which sounds like a lot, but I guess you could push the
data that far.

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?

Of course there is the question of whether the Histogram function in
PhotoShop reads 16-bit and 8-bit files the same way.

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.

In the end though a lot of this may not matter for practical purposes since
you can often get good prints from 8-bit files with rather nasty looking
histograms. Degradation in the histogram of a 16-bit file may be even more
irrelevant.

I suspect that Frank has run into something Tyler Boley and I have
encountered with SilverFast software. There are certain workpaths that will
produce a 16-bit file with a nice looking histogram after scanning but that
immediately look degraded after the first adjustment.

Martin Wesley

>
> On the bottom of the histogram you are looking at the 16 bit file on,
isn't

> the scale 0-255?
>
> Austin
>
>
> > Andrew,
> > I duplicated the 16 bit file and converted to 8bit - then compared
> > the histograms - you are right there is less combing viewed in 88
> > bit - but it's still there albeit not quite as bad as in 16
> >
> > ?
> > Frank
> > > > after minor contrast adj in 16 bit scans (moving the end sliders
> > to
> > > > the edges of the histogram & the middle to fix the mid tones), I
> > > > still have 'drop out' or combed histograms - any ideas, tips ?
> > >
> > > Convert the file to 8 bits THEN look at the Histogram. You should
> > see NO
> > > combs.
>

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

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...but remember one little thing,
16 bits in PS, is really only 15 bits...

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

> If you did a strong levels or other adjustment on this 16-bit file
> wouldn't the spacing change so that in some portions of the 16-bit range
> data points are brought closer together

Correct.

> ...even overlapping

That would have to be a VERY drastic tonal move to do that in 16 bit
space...

> giving the
> "spikes" seen in histograms

Yes, that sounds right.

> ...and in others portions of the 16-bit
> range they
> are spread farther apart than intervals of 16. To see a gap in the 16-bit
> file, 65,535 levels, with an 8-bit histogram tool it would have to be 256
> 16-bit levels wide, which sounds like a lot, but I guess you
> could push the
> data that far.

Yes, you could...but that would be one HELL of a move...

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


> Of course there is the question of whether the Histogram function in
> PhotoShop reads 16-bit and 8-bit files the same way.

Of course.

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

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

Regards,

Austin

Has anyone taken the output of a 16 bit scan saved in 16 bit tiff and 
then read into a software package like Mathematica or Matlab so that you 
could actually see what was going on?

If not I may give that a whirl.

Truman

Martin Wesley wrote:

> ----- Original Message -----
> From: "Austin Franklin" <darkroom@...>
> To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Sent: Friday, October 11, 2002 10:15 AM
> Subject: RE: [Digital BW] Re: 'combed' histograms in 16 bit ?
>
>
> > Can anyone explain why it would even be any different?  It should be the
> > exact same data...and as I said, the histogram is an 8 bit histogram, no
> > matter whether the file is, 8 bits or 16 bits.  When displaying a 16 bit
> > file, the low 8 bits are simply ignored...and when converting a 16 bit
> file
> > to 8 bits, simply the lower 8 bits are dropped...so they should be the
> same?
>
> Austin,
>
> I am still trying to get a better grasp on what is happening with the data
> during scanning and mode changes. So see if I am correct in the following.
>
> 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. If you did a strong levels or other adjustment on this 16-bit file
> wouldn't the spacing change so that in some portions of the 16-bit range
> data points are brought closer together, even overlapping giving the
> "spikes" seen in histograms, and in others portions of the 16-bit 
> range they
> are spread farther apart than intervals of 16. To see a gap in the 16-bit
> file, 65,535 levels, with an 8-bit histogram tool it would have to be 256
> 16-bit levels wide, which sounds like a lot, but I guess you could 
> push the
> data that far.
>
> 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?
>
> Of course there is the question of whether the Histogram function in
> PhotoShop reads 16-bit and 8-bit files the same way.
>
> 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.
>
> In the end though a lot of this may not matter for practical purposes 
> since
> you can often get good prints from 8-bit files with rather nasty looking
> histograms. Degradation in the histogram of a 16-bit file may be even more
> irrelevant.
>
> I suspect that Frank has run into something Tyler Boley and I have
> encountered with SilverFast software. There are certain workpaths that 
> will
> produce a 16-bit file with a nice looking histogram after scanning but 
> that
> immediately look degraded after the first adjustment.
>
> Martin Wesley
>
> >
> > On the bottom of the histogram you are looking at the 16 bit file on,
> isn't
> > the scale 0-255?
> >
> > Austin
> >
> >
> > > Andrew,
> > > I duplicated the 16 bit file and converted to 8bit - then compared
> > > the histograms - you are right there is less combing viewed in 88
> > > bit - but it's still there albeit not quite as bad as in 16
> > >
> > > ?
> > > Frank
> > > > > after minor contrast adj in 16 bit scans (moving the end sliders
> > > to
> > > > > the edges of the histogram & the middle to fix the mid tones), I
> > > > > still have 'drop out' or combed histograms - any ideas, tips ?
> > > >
> > > > Convert the file to 8 bits THEN look at the Histogram. You should
> > > see NO
> > > > combs.
> >
>
>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT
> <http://rd.yahoo.com/M=212804.2460941.3878106.2225242/D=egroupweb/S=1705019182:HM/A=810327/R=0/*http://geocities.yahoo.com/ps/info?.refer=blrecs> 
>
> <http://rd.yahoo.com/M=212804.2460941.3878106.2225242/D=egroupweb/S=1705019182:HM/A=810327/R=1/*http://geocities.yahoo.com/ps/info?.refer=blrecs> 
>
>
>
> 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
>
> If you wish to receive no emails or just a daily digest, or you wish 
> to unsubscribe, please edit your Membership preferences by visiting 
> this same page.
>
> 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 
> &amp;amp;quot;flames.&amp;amp;quot;
> - 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 the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.




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

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

> But the histogram IS an 8 bit histogram...  It should look the same,
> providing no tonal adjustments are done, and I don't believe simply
> converting from 16 bit to 8 bit should do that...it only "lops" off the
> lower 8 bits.

Photoshop shows all histograms as "8 bit." If it had to show you a level for 
every possible step in 16 bit (64000 odd levels), the display would have to be 
the size of a small bus! So when you view a Histogram in high bit (what 
Photoshop calls 16bit), you're not seeing what is really going on in that 
Histogram. But you still have all the data in that file to manipulate. Once you 
convert to 8 bits per color (on a copy), now you are seeing the "real" 
distribution of the 256 levels of data. So the combs should be long gone. 

Bottom line is that when you have a high bit file and you manipulate it, you 
can use the Histogram provided but the preview showing the data or combing 
isn't accurate. You still have many, many steps that end up producing the best 
256 levels once you convert down to 8 bits and you should see a nice, 
smooth histogram.

> > But the histogram IS an 8 bit histogram...  It should look the same,
> > providing no tonal adjustments are done, and I don't believe simply
> > converting from 16 bit to 8 bit should do that...it only "lops" off the
> > lower 8 bits.
>
> Photoshop shows all histograms as "8 bit."

Exactly what I was pointing out.

> So when you view a Histogram in high bit (what
> Photoshop calls 16bit), you're not seeing what is really going on in that
> Histogram.

Why not?  You SHOULD be seeing only the top 8 significant bits of the image
file.  What else would it do?

> But you still have all the data in that file to
> manipulate. Once you
> convert to 8 bits per color (on a copy), now you are seeing the "real"
> distribution of the 256 levels of data. So the combs should be long gone.

I don't understand how that follows.  Unless either the 16 bit histogram
does not simply use the top 8 bits, or the conversion from 16 to 8 bits
somehow does some "processing", and not simply uses the top 8 bits, then
they should be the same.

> Bottom line is that when you have a high bit file and you
> manipulate it, you
> can use the Histogram provided but the preview showing the data
> or combing
> isn't accurate.

Why?  Specifically.

I think either you or I have a gross misunderstanding how the process works.
Perhaps you ought to outline exactly what you believe the histogram uses for
data, as well as how you think the 16 to 8 bit conversion process is done.
I have outlined how I believe they work.

Austin

once you convert down to 8 bits and you should see a nice, 
> smooth histogram.

But I dont, and I'd like to understand why I dont have a nice smooth 
histogram ? As I said in the originaal post there has been "moinimal" 
editing and therefore data loss ? Any ideas how I might preserve the 
image and achieve the "smooth" histogram?
frank

--- In DigitalBlackandWhiteThePrint@y..., "frankg_photo" <frank@f...>
wrote:
> once you convert down to 8 bits and you should see a nice, 
> > smooth histogram.
> 
> But I dont, and I'd like to understand why I dont have a nice smooth 
> histogram ?

In Photoshop-
Edit/ Preferences/ Image Cache-
uncheck "use cache for histograms"

Tyler

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

----- Original Message -----

From: "thedigitaldog" <andrew@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Friday, October 11, 2002 2:18 PM
Subject: [Digital BW] Re: 'combed' histograms in 16 bit ?


> --- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin"
<darkroom@i...>
> wrote:
>
> > But the histogram IS an 8 bit histogram...  It should look the same,
> > providing no tonal adjustments are done, and I don't believe simply
> > converting from 16 bit to 8 bit should do that...it only "lops" off the
> > lower 8 bits.
>
> Photoshop shows all histograms as "8 bit." If it had to show you a level
for
> every possible step in 16 bit (64000 odd levels), the display would have
to be
> the size of a small bus! So when you view a Histogram in high bit (what
> Photoshop calls 16bit), you're not seeing what is really going on in that
> Histogram. But you still have all the data in that file to manipulate.
Once you
> convert to 8 bits per color (on a copy), now you are seeing the "real"
> distribution of the 256 levels of data. So the combs should be long gone.
>
> Bottom line is that when you have a high bit file and you manipulate it,
you
> can use the Histogram provided but the preview showing the data or combing
> isn't accurate. You still have many, many steps that end up producing the
best
> 256 levels once you convert down to 8 bits and you should see a nice,
> smooth histogram.

Andrew,

You are right but what about all the people who work entirely in 16-bit
mode? Or like myself stay in 16-bit as long as possible before going to
8-bit? On a couple of negs I have been forced to stay in 16-bit to get the
tonality I want. Adobe is really missing the need for full functionality in
16-bit for critical B&W work. 8-bit color is fine because you really have
24-bits of data to push around. 8-bit is cutting it much to close for
comfort.

Martin Wesley

Martin Wesley wrote:
> 8-bit color is fine because you really have
> 24-bits of data to push around.

All other facts and misinformation aside, here is a bit of information 
which should give you pause:  8 bits per channel of RGB data gives you 
(only) 9 bits of lightness (black & white) information.

-Jon Dubovsky ( entropy@... )

> > once you convert down to 8 bits and you should see a nice, 
> > > smooth histogram.
> > 
> > But I dont, and I'd like to understand why I dont have a nice 
smooth 
> > histogram ?
> 
> In Photoshop-
> Edit/ Preferences/ Image Cache-
> uncheck "use cache for histograms"
> 
It is Un-checked ?

Jumping in the middle of this not having really read much of the
start...

What about the source image. Was it truly 16 bits per channel? Most
scanners output 12 to 14 bits. Digital cameras output 10 to 12 bits.
They fit them into 16 bit words but the lower bits are all zeroes. If
you start with something like a 10 bit image (even though you are
working in a "16 bit" space), and do some adjustments, especially gamma
related, you are bound to see these bands.

g

--- In DigitalBlackandWhiteThePrint@y..., "frankg_photo" <frank@f...> 
wrote:

> > In Photoshop-
> > Edit/ Preferences/ Image Cache-
> > uncheck "use cache for histograms"
> > 
> It is Un-checked ?

Is that a question or a statement with a "what now"?
If it's already unchecked, well, it was worth a shot.
If adjustments are putting tonal holes in 16 bit PS files my suspicion 
is that there isn't as much information in the file in the first place 
as the histogram would imply, since it's only showing you eight bits of 
it.
And Photoshop has know way of letting you know that.
Tyler

----- Original Message -----

From: "Jon Dubovsky" <entropy@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Friday, October 11, 2002 9:49 PM
Subject: Re: [Digital BW] Re: 'combed' histograms in 16 bit ?


>
> Martin Wesley wrote:
> > 8-bit color is fine because you really have
> > 24-bits of data to push around.
>
> All other facts and misinformation aside, here is a bit of information
> which should give you pause:  8 bits per channel of RGB data gives you
> (only) 9 bits of lightness (black & white) information.
>
Jon,

I'm not sure I follow you. I meant 8-bit color for color printing is fine,
not 8-bit color for B&W printing. Although this might be an advantage to
using CMYK inks but the other problems seem to off set any advantage that
extra bit might give.

Martin Wesley

Hi Gus,

> What about the source image. Was it truly 16 bits per channel? Most
> scanners output 12 to 14 bits. Digital cameras output 10 to 12 bits.
> They fit them into 16 bit words but the lower bits are all zeroes.

If they are raw images, that, in my experience, would not be the case...and
to get that bit depth, I believe you have to use raw data, at least from the
scanners/cameras I've used.  As I said in another post, the data is low bit
justified, not high bit justified.

> If
> you start with something like a 10 bit image (even though you are
> working in a "16 bit" space), and do some adjustments, especially gamma
> related, you are bound to see these bands.

If the data is as I say, low bit justified, then you must set the setpoints
first to spread the data out over the 16 bit range, as setting the setpoints
will basically high bit justify the remaining data between your
setpoints...then you can to tonal adjustments.  If you do tonal adjustments
to low bit justified data, you WILL drop data values, because the data will
either combine or leave gaps.

Austin

> Martin Wesley wrote:
> > 8-bit color is fine because you really have
> > 24-bits of data to push around.
> 
> All other facts and misinformation aside, here is a bit of information 
> which should give you pause:  8 bits per channel of RGB data gives you 
> (only) 9 bits of lightness (black & white) information.
> 
> -Jon Dubovsky ( entropy@... )

Jon,

Please explain the basis for this claim.

Regards,

Austin

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

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <darkroom@i...> 
wrote:
 
> Why not?  You SHOULD be seeing only the top 8 significant bits of the 
image file.  What else would it do?

You are seeing 65000 levels represented as 256. As I said, if Photoshop 
could draw a black line in the Histogram for every level, you'd need a display 
that is about 30 feet long! With the current Histogram, you are viewing 256 
steps (they may be black, they may be white) but one level is drawn in that 
small GUI. So when you work with high bit files, the Histogram isn't "accurate" 
because thousands of levels are being represented as one level. 
 
> I don't understand how that follows.  Unless either the 16 bit histogram
> does not simply use the top 8 bits, or the conversion from 16 to 8 bits
> somehow does some "processing", and not simply uses the top 8 bits, then
> they should be the same.

All the additional data is there, you are just not seeing it. 

High bit files are like a stair case. An 8 bit file and a 16 bit file can be the same 
"length". But the 8 bit file has 256 steps to get from black to white while the 16 
bit stair case has 64500 (plus or minus). 

> Why?  Specifically.

You have more steps of data so as you move the levels, curves whatever, and 
then you drop down to 8 bits, Photoshop uses the BEST steps to compress 
the data down to 8 bits pre color. It uses the 645000 steps to end up with the 
best 256.

> > Why not?  You SHOULD be seeing only the top 8 significant bits of the
> image file.  What else would it do?
>
> You are seeing 65000 levels represented as 256.

Yes, and just how do you think it does that?  It chops off the lower 8 bits
of the data values then counts the number of pixels that have each value and
displays them.  How on earth else does it do it if not that way?  Any other
way is useless, except if it does some rounding, instead of simply chopping
off the low 8 bits.

> As I said, if Photoshop
> could draw a black line in the Histogram for every level, you'd
> need a display
> that is about 30 feet long!

Only if every leaves was individually represented, and it is not.

> With the current Histogram, you are
> viewing 256
> steps (they may be black, they may be white) but one level is
> drawn in that
> small GUI. So when you work with high bit files, the Histogram
> isn't "accurate"
> because thousands of levels are being represented as one level.

So what?  The conversion from 16 bit to 8 bit should be done the EXACT same
way as it calculates the 16 bit file to display an 8 bit histogram.

> > I don't understand how that follows.  Unless either the 16 bit histogram
> > does not simply use the top 8 bits, or the conversion from 16 to 8 bits
> > somehow does some "processing", and not simply uses the top 8 bits, then
> > they should be the same.
>
> All the additional data is there, you are just not seeing it.

What additional data?  If you convert the 16 bit file to 8 bits, there is no
"additional data".  The histogram doesn't simply take 256 points from 256
values in the 16 bit file, it does something with the data so ALL the levels
are represented, though 256 levels are combined for each level displayed.

> High bit files are like a stair case.

Huh?  They are no different than 8 bit files, just more tones.

> An 8 bit file and a 16 bit
> file can be the same
> "length". But the 8 bit file has 256 steps to get from black to
> white while the 16
> bit stair case has 64500 (plus or minus).

Yes, I understand that, I design digital imaging equipment for a living and
have been doing so for 25 years.  You simply aren't understanding what it is
I'm saying.

> > Why?  Specifically.
>
> You have more steps of data so as you move the levels, curves
> whatever, and
> then you drop down to 8 bits, Photoshop uses the BEST steps to compress
> the data down to 8 bits pre color. It uses the 645000 steps to
> end up with the
> best 256.

If I understand what you are trying to say, it's completely wrong.  How 16
bits is converted to 8 bits, is one of two ways, and both are equally as
valid.  Either the lower 8 bits (or 7 bits in PS case, as it only stores
high bit data as 15 bits) are simply "dropped" for example
1011_0010_1101_0100 becomes 1011_0010.  The other way to do it is round
up/down based on the lower N bits.  If they are greater than 1/2 the cut-off
value then you merely use the upper bits, if they are lower, then you remove
the lower bits, and subtract 1 from the upper bits you have left.

In no way is there any "uses the BEST steps to compress the data down".  If
it in fact does, that's foolish and meaningless.  How does IT know what 256
values you want?

Austin

----- Original Message -----

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


(snip)
>
> If the data is as I say, low bit justified, then you must set the
setpoints
> first to spread the data out over the 16 bit range, as setting the
setpoints
> will basically high bit justify the remaining data between your
> setpoints...then you can to tonal adjustments.  If you do tonal
adjustments
> to low bit justified data, you WILL drop data values, because the data
will
> either combine or leave gaps.
>
Austin,

Can you define or explain low and high bit justificaton? Maybe an example of
each.

Thanks,
Martin

--- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley" <
mwesley250@e...> wrote:

> You are right but what about all the people who work entirely in 16-bit
> mode? Or like myself stay in 16-bit as long as possible before going to
> 8-bit? On a couple of negs I have been forced to stay in 16-bit to get the
> tonality I want. Adobe is really missing the need for full functionality in
> 16-bit for critical B&W work. 

What functionality is missing? You have all the tools (levels, curves, Hue/Sat, 
resize, conversions, spotting etc) in high bit be it grayscale or color. 

Adjustment layers would be nice. More History support would be nice But you 
can still do all the work that high bit benifits in imaging, change your mind and 
go back without hosing the data unless you go insane with edits. I'd love to 
see high bit adjustment layers just for the ability to keep track of edits and 
change my mind. But that wouldn't produce better quality data once you dump 
the high bit down to 8 bits. 

And of printing direclty out of Photoshop, you don't have to dump to 8 bits 
(Photoshop does this on the fly as you print). With the exception of one or two 
very high end RGB output devices, I don't know of any that would even accept 
high bit files if you feed them this data. So high bit is good for doing editing so 
that you end up with the best 8 bits to output. 

I do want to see more high bit functionality but today, I can do all the 
necessary work that high bit provides advantags for (namely tonal and color 
corrections).

----- Original Message -----

From: "thedigitaldog" <andrew@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Saturday, October 12, 2002 11:11 AM
Subject: [Digital BW] Re: 'combed' histograms in 16 bit ?


> --- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley" <
> mwesley250@e...> wrote:
>
> > You are right but what about all the people who work entirely in 16-bit
> > mode? Or like myself stay in 16-bit as long as possible before going to
> > 8-bit? On a couple of negs I have been forced to stay in 16-bit to get
the
> > tonality I want. Adobe is really missing the need for full functionality
in
> > 16-bit for critical B&W work.
>
> What functionality is missing? You have all the tools (levels, curves,
Hue/Sat,
> resize, conversions, spotting etc) in high bit be it grayscale or color.

Andrew,

Layers and Channels. Without layers and alpha channel masking Photoshop is
seriously crippled in 16-bit mode in my opinon. The ability to maintain
multiple layers in a file and be able to tweak them to get the optimum print
is critical to the way I work. You are also missing a lot tools as well,
Sharpen, Blur and Smudge Tool, Dodge, Burn and Saturate Tool, Eraser,
Paintbrush, Magic Wand Tool, Color Range Select, etc.
>
> Adjustment layers would be nice. More History support would be nice But
you
> can still do all the work that high bit benifits in imaging, change your
mind and
> go back without hosing the data unless you go insane with edits.

You don't have the abiltiy to turn multiple layers on and off to compare one
adjustment path to another. Much harder to get to a good print.

> I'd love to
> see high bit adjustment layers just for the ability to keep track of edits
and
> change my mind. But that wouldn't produce better quality data once you
dump
> the high bit down to 8 bits.

If you had Layers and Channels in 16-bit there would be no reason to ever
drop to 8-bit. A lot of people are struggling through in 16-bit all the way
to the printer.
>
> And of printing direclty out of Photoshop, you don't have to dump to 8
bits
> (Photoshop does this on the fly as you print). With the exception of one
or two
> very high end RGB output devices, I don't know of any that would even
accept
> high bit files if you feed them this data. So high bit is good for doing
editing so
> that you end up with the best 8 bits to output.

If you are using other printer divers such as the Piezo plugin or printing a
high bit file with a RIP this may or may not be the case. Also dumping the
data to 8-bit as it goes to the printer is probably not a problem, unless
there are partitioning curves involved, but I would like to make every
adjustment in high bit before I drop down.
>
> I do want to see more high bit functionality but today, I can do all the
> necessary work that high bit provides advantags for (namely tonal and
color
> corrections).

You can make due but life would be simpler if you had the choice to stay in
high bit mode. This would be the biggest upgrade Adobe could make to PS. Of
course this would require some real programming work on the core of PS I
image and I have heard that PS is not one of their big money makers, so I am
not holding my breath. I wish Picture Window Pro had a decent user interface
and would move a lot of my work to there.

Martin Wesley

> Can you define or explain low and high bit justification? Maybe an
> example of
> each.

Absolutely, Martin.

Say your 12 bits is 1001_0110_1110.  If you want to convert it to 16 bits,
high justified, you simply add four bits to the "bottom" (Least Significant
Bit side, right side) and the result is 1001_0110_1110_0000.  That's high
bit justification.  Also, since you now added four bits, the 16 bit number
is 16x larger than the original 12 bit number.

Low bit justification is simply adding the four bits on the "top" (Most
Significant Bit side, left side) and it would be 0000_1001_0110_1110 and the
number would be exactly the same number as you started with, just in a 16
bit realm.

Regards,

Austin

--- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley" 

< Layers and Channels. Without layers and alpha channel masking 
Photoshop is seriously crippled in 16-bit mode in my opinon. 

Layers would be nice. But if you are past the point of doing corrections and it's 
time for creative stuff, then you *could* downsample to 8 bits and go at it. The 
benifits of high bit (doing those tonal and color corrections that would lose 
data) have been taken care of. But yes, give the choices, I'd love to composite 
in 16 bit. 

As for channels, you can still do a lot in 16 bit on an 8 bit copy. You can load 
any of the channels from the 8 bit file to the 16 bit file as long as both files 
have the identical pixel count. So I dupliate the 16 bit file, drop it down to 8 bit, 
make my channles and move the over to the 16 bit file. Again, if I could do this 
without the extra work, it would be nice. 

>You are also missing a lot tools as well,
> Sharpen, Blur and Smudge Tool, Dodge, Burn and Saturate Tool, Eraser,
> Paintbrush, Magic Wand Tool, Color Range Select, etc.

Well Gaussian Blue and USM are 16 bit filters. 

> You can make due but life would be simpler if you had the choice to stay in
> high bit mode. This would be the biggest upgrade Adobe could make to PS. 

Well keep telling them this and you might see it someday. I know I (and 
people I hang with like Jeff Schewe) keep telling them that. Nothing would 
make me happier to see far more high bit support in the next version. 
I'm not sure how many copies that would sell but there is a hard core group of 
PS users that have been asking for this for a long time.

I don't know the code in PS, so I can't comment.  Today I ran a small 
experiment. I scanned a B&W negative on my 2450 in 16 bit mode and saved 
it in 16 bit tiff. I then read the image into Matlab and did some 
analysis on the data. A histogram on the data and found that the active 
bins ran from about 2000 through 16,000. I am going to repeat this with 
a negative with deeper shadows to see if I can light up the lower bits. 
But in any case the difference between the high and low is 14,000 which 
is quite a respectable dynamic range.

My suspicions is PS is basically an 8 bit package with patches, mods and 
fixes to accommodate 16 bit data. It may or may not handle 16 bit data 
according to IEEE standards.

Truman

Until (or if) PS does get more 16-bit support, for Windows users, 
Picture Window Pro can do many of the 16-bit operations that 
Photoshop can't. Everything in PWP works in with either 8-bit 
or 16-bit files. Go to http://www.dl-c.com for a 30-day evaluation 
copy. PWP does not do layers, though they can be emulated with 
compositing. It makes a quite decent "pre-processor" for 16-bit 
images that require some of the things Photoshop does in 8-bit 
that PWP can't do and at least for the kinds of work I do handles 
most of what I need without ever going to Photoshop.

- David

= = = Original message = = =

--- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley" 

< Layers and Channels. Without layers and alpha channel masking 

Photoshop is seriously crippled in 16-bit mode in my opinon. 


Layers would be nice. But if you are past the point of doing 
corrections and it's 
time for creative stuff, then you *could* downsample to 8 bits 
and go at it. The 
benifits of high bit (doing those tonal and color corrections 
that would lose 
data) have been taken care of. But yes, give the choices, I'd 
love to composite 
in 16 bit. 

As for channels, you can still do a lot in 16 bit on an 8 bit 
copy. You can load 
any of the channels from the 8 bit file to the 16 bit file as 
long as both files 
have the identical pixel count. So I dupliate the 16 bit file, 
drop it down to 8 bit, 
make my channles and move the over to the 16 bit file. Again, 
if I could do this 
without the extra work, it would be nice. 

>You are also missing a lot tools as well,
> Sharpen, Blur and Smudge Tool, Dodge, Burn and Saturate Tool, 
Eraser,
> Paintbrush, Magic Wand Tool, Color Range Select, etc.

Well Gaussian Blue and USM are 16 bit filters. 

> You can make due but life would be simpler if you had the choice 
to stay in
> high bit mode. This would be the biggest upgrade Adobe could 
make to PS. 

Well keep telling them this and you might see it someday. I know 
I (and 
people I hang with like Jeff Schewe) keep telling them that. 
Nothing would 
make me happier to see far more high bit support in the next 
version. 
I'm not sure how many copies that would sell but there is a hard 
core group of 
PS users that have been asking for this for a long time. 


___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.

> I don't know the code in PS, so I can't comment.  Today I ran a small
> experiment. I scanned a B&W negative on my 2450 in 16 bit mode and saved
> it in 16 bit tiff. I then read the image into Matlab and did some
> analysis on the data. A histogram on the data and found that the active
> bins ran from about 2000 through 16,000. I am going to repeat this with
> a negative with deeper shadows to see if I can light up the lower bits.
> But in any case the difference between the high and low is 14,000 which
> is quite a respectable dynamic range.

Truman,

How did you set-up the scan?  Is this strictly raw data?  Are there any
setpoints and/or curves being applied to the data by the driver?  Are there
gaps in the data?  How did you determine what was valid image data?

There is physically no way a B&W negative can give you 14k different codes,
it just doesn't exist on the film...  Something's wrong...

Austin

----- Original Message -----

From: "Austin Franklin" <darkroom@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Saturday, October 12, 2002 1:35 PM
Subject: RE: [Digital BW] Re: 'combed' histograms in 16 bit ?


> > Can you define or explain low and high bit justification? Maybe an
> > example of
> > each.
>
> Absolutely, Martin.
>
> Say your 12 bits is 1001_0110_1110.  If you want to convert it to 16 bits,
> high justified, you simply add four bits to the "bottom" (Least
Significant
> Bit side, right side) and the result is 1001_0110_1110_0000.  That's high
> bit justification.  Also, since you now added four bits, the 16 bit number
> is 16x larger than the original 12 bit number.
>
> Low bit justification is simply adding the four bits on the "top" (Most
> Significant Bit side, left side) and it would be 0000_1001_0110_1110 and
the
> number would be exactly the same number as you started with, just in a 16
> bit realm.
>
Austin,

Nothing like an example. So right or high bit justification places the
12-bit number in the upper end of the 16-bit space and left or low bit
justification puts it in the bottom end of the range.

It would seem that for raw scanning you would always want to do right bit
justification since the values would not be adjacent in 16-bit space. Each
adjacent pair of 12-bit values winds up 4-bits apart. 1001_0110_1110 is
placed at 1001_0110_1110_0000 and 1001_0110_1111 is placed at
1001_0110_1111_0000.

With Left bit justification all the 12-bit values remain adjacent in 16-bit
space. 1001_0110_1110 is placed at 0000_1001_0110_1110 and 1001_0110_1111 is
placed at  0000_1001_0110_1111.

As an alternative couldn't the programmer who wrote the scanning software do
a combination of both? Place two bits on each end or one on one end and
three on the other? That actually would seem to me to be the logical choice
since the mapped data would then fall more in the middle of the 16-bit
space.

Maybe this is what is being done in Silverfast so that the values are not
adjacent but still close enough together to cause problems if you do a curve
type adjustment without spreading out the end points first. This would also
explain why the raw data occupies a wider portion of the histogram display
that you would expect if it was exactly adjacent.

Martin

----- Original Message -----

From: "thedigitaldog" <andrew@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Saturday, October 12, 2002 3:16 PM
Subject: [Digital BW] Re: 'combed' histograms in 16 bit ?


> --- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley"
>
(snip earlier)
>
> > You can make due but life would be simpler if you had the choice to stay
in
> > high bit mode. This would be the biggest upgrade Adobe could make to PS.
>
> Well keep telling them this and you might see it someday. I know I (and
> people I hang with like Jeff Schewe) keep telling them that. Nothing would
> make me happier to see far more high bit support in the next version.
> I'm not sure how many copies that would sell but there is a hard core
group of
> PS users that have been asking for this for a long time.
>
Andrew,

What is the best point of contact with Adobe for the individual to weigh in
with their "want list" for the next version of PS?

Thanks,
Martin

Hi Martin:

I don't know what is happenning but I am receiving
tons of e-mails from you. Chech out why this is
happening.

Thanks

Cristian Baitg
user in the B&W digital print


<tt>
----- Original Message -----<BR>

From: "thedigitaldog"
<andrew@...><BR>
To:
<DigitalBlackandWhiteThePrint@yahoogroups.com><BR>
Sent: Saturday, October 12, 2002 3:16 PM<BR>
Subject: [Digital BW] Re: 'combed' histograms in 16
bit ?<BR>
<BR>
<BR>
> --- In DigitalBlackandWhiteThePrint@y...,
"Martin Wesley"<BR>
><BR>
(snip earlier)<BR>
><BR>
> > You can make due but life would be simpler
if you had the choice to stay<BR>
in<BR>
> > high bit mode. This would be the biggest
upgrade Adobe could make to PS.<BR>
><BR>
> Well keep telling them this and you might see it
someday. I know I (and<BR>
> people I hang with like Jeff Schewe) keep telling
them that. Nothing would<BR>
> make me happier to see far more high bit support
in the next version.<BR>
> I'm not sure how many copies that would sell but
there is a hard core<BR>
group of<BR>
> PS users that have been asking for this for a
long time.<BR>
><BR>
Andrew,<BR>
<BR>
What is the best point of contact with Adobe for the
individual to weigh in<BR>
with their "want list" for the next version
of PS?<BR>
<BR>
Thanks,<BR>
Martin<BR>
<BR>
<BR>
</tt>

<br>

<!-- |**|begin egp html banner|**| -->

<table border=0 cellspacing=0 cellpadding=2>
<tr bgcolor=#FFFFCC>
<td align=center><font size="-1"
color=#003399><b>Yahoo! Groups Sponsor</b></font></td>
</tr>
<tr bgcolor=#FFFFFF>
<td align=center width=470><TABLE WIDTH=300 HEIGHT=250
border=0 cellpadding=0 cellspacing=0><tr><td
align=center><font face=arial
size=-2>ADVERTISEMENT</font><br>
<TR>
<TD>
<a
href="http://rd.yahoo.com/M=212804.2460941.3878106.2225242/D=egroupweb/S=1705019182:HM/A=810373/R=0/*http://geocities.yahoo.com/ps/info?.refer=blrecs"
target=_top><IMG
SRC="http://us.a1.yimg.com/us.yimg.com/a/ya/yahoo_geocities/lrec2b_1_01.jpg"
WIDTH=185 HEIGHT=250 BORDER=0></a></TR></TD>
<TD>
<a
href="http://rd.yahoo.com/M=212804.2460941.3878106.2225242/D=egroupweb/S=1705019182:HM/A=810373/R=1/*http://geocities.yahoo.com/ps/info?.refer=blrecs"
target=_top><IMG
SRC="http://us.a1.yimg.com/us.yimg.com/a/ya/yahoo_geocities/lrec2d_2_02.gif"
WIDTH=115 HEIGHT=250 BORDER=0></TD>
</TR></a>
</TABLE></td>
</tr>
<tr><td><img alt="" width=1 height=1
src="http://us.adserver.yahoo.com/l?M=212804.2460941.3878106.2225242/D=egroupmail/S=:HM/A=810373/rand=360967014"></td></tr>
</table>

<!-- |**|end egp html banner|**| -->


<br>
<tt>
Please visit the Group Homepage to check the Files,
Bookmarks, Polls and other resources as they are often
being updated. The page is at:<BR>
<BR>
<a
href="http://groups.yahoo.com/group/DigitalBlackandWhiteThePrint">http://groups.yahoo.com/group/DigitalBlackandWhiteThePrint</a><BR>
<BR>
If you wish to receive no emails or just a daily
digest, or you wish to unsubscribe, please edit your
Membership preferences by visiting this same page.<BR>
<BR>
Please follow these basic guidelines:<BR>
- Include your full name with your message.<BR>
- Include the address of your website, if you have
one.<BR>
- As threads develop, trim off excess portions of
earlier messages to keep them short.<BR>
- As the topic of a thread changes remember to change
the subject header.<BR>
- Good manners are required at all time. No personal
attacks or
&amp;amp;amp;quot;flames.&amp;amp;amp;quot;<BR>
- Complete your Yahoo profile.<BR>
- Before posting a question, search the message
archives and the various resources on the homepage.
<BR>
<BR>
<BR>
</tt>
<br>

<br>
<tt>Your use of Yahoo! Groups is subject to the <a
href="http://docs.yahoo.com/info/terms/">Yahoo! Terms
of Service</a>.</tt>
</br>

</body></html>
 

=====
Cristian Baitg Schreiweis
C/ Siracusa 13-15 1\ufffd3\ufffd
08012 Barcelona
E-mail: cristianbaitg@...

_______________________________________________________________
Yahoo! Messenger
Nueva versi\ufffdn: Webcam, voz, y mucho m\ufffds \ufffdGratis! 
Desc\ufffdrgalo ya desde http://messenger.yahoo.es

Martin,

Here's what Russel Williams had to say on this on the Epson-inkjet list not
so long ago:

"As for 16 bit layers, here's a revised version of an item I've posted in
the
past.

While we generally try to add 16 bit support over time, there is no crash
program (nor is one currently contemplated) to make all features work in 16
bit. The reason is not laziness. We have a fixed amount of money and time to
spend on improving Photoshop, and we have to choose how to spend it to
provide the most benefit to the most users -- and that includes attracting
new users.

That said, I realize that the number of 16 bit image sources is increasing,
and the 16 bit images from digital cameras tend to be smaller and thus more
manageable than the high resolution scans that were the previously most
common source. If your raw scan was 100-200MB, getting the big curves moves
done and then cutting the image size in half was an obvious win on its own
merits. If your digicam file is 10-20MB, cutting it in half is much less of
an issue.

The 16 bit features already in Photoshop provide most of the benefit to be
had from 16 bit mode -- once you make your large adjustments in 16 bit,
there is -- for most users most of the time -- very little reason to keep
the image in 16 bit (and keep in mind that the percentage of users who
*ever* work in 16 bit is still small to begin with). So full support for
everything in 16 bit would only help a very small number of users a small
percentage of the time. How many copies of Photoshop 6 would we have sold if
the only feature was "16 bit everything"?

Such support would be *extremely* expensive. There are hundreds of routines
that perform graphics operations in Photoshop -- thousands if you include
the plugins. Every one of them would have to be duplicated. Further, there
are already several versions of many of those routines -- Intel assembly,
PPC assembly, MMX accelerated, AltiVec accelerated, SSE accelerated. In
order for 16 bit operations to be *only* twice as slow as 8 bit operations,
many of those low level routines would have to be hand-optimized as well,
with separate versions written for different processors.

Finally, most of the people on the Photoshop team are not skilled in writing
and optimizing the low level graphics routines. Photoshop is a huge
application and the team has a wide diversity of skills. We no more have the
ability to put all our resources into 16-bitness for a single release than
we do to put them all on typography for a single release.

The question isn't "should we do 16 bit everything?", but "is it worth
giving up a long list of other more generally useful features over a long
period of time to do 16 bit everything?" Not surprisingly, the answer has
always turned out to be "no".

Russell Williams
not speaking for Adobe Systems"

----- Original Message -----
From: "Martin Wesley" <mwesley250@...>
>
> You can make due but life would be simpler if you had the choice to stay
in
> high bit mode. This would be the biggest upgrade Adobe could make to PS.
Of
> course this would require some real programming work on the core of PS I
> image and I have heard that PS is not one of their big money makers, so I
am
> not holding my breath. I wish Picture Window Pro had a decent user
interface
> and would move a lot of my work to there.

Austin,

I was more interesting in debugging the process yesterday. Yes it was 
valid tiff data - Mathlab has complet support tiff. It supports 8 and 16 
bit gray scale tiff and 24 and 48 bit color.  I did plot the image using 
the matlab graphic and it is an image. Mathlab is a common package used 
to develop image processing, change detection, automatic target 
recoginition software. 

Now I've going to work back. I did use the Silverfast driver so I  need 
to go back and check that out and make sure it was raw.  Probably also 
need to look at the Epson driver.

The edges of the bins were taken to be 0,15,31,47, etc. so that it would 
be a little easier to see what was happening. The bits were 16 values 
wide covering 0 to 2^16 -1.

When I get some time later today, I'm going to find a better negative 
and take another look.

Truman

Austin Franklin wrote:

>
>
> > I don't know the code in PS, so I can't comment.  Today I ran a small
> > experiment. I scanned a B&W negative on my 2450 in 16 bit mode and saved
> > it in 16 bit tiff. I then read the image into Matlab and did some
> > analysis on the data. A histogram on the data and found that the active
> > bins ran from about 2000 through 16,000. I am going to repeat this with
> > a negative with deeper shadows to see if I can light up the lower bits.
> > But in any case the difference between the high and low is 14,000 which
> > is quite a respectable dynamic range.
>
> Truman,
>
> How did you set-up the scan?  Is this strictly raw data?  Are there any
> setpoints and/or curves being applied to the data by the driver?  Are 
> there
> gaps in the data?  How did you determine what was valid image data?
>
> There is physically no way a B&W negative can give you 14k different 
> codes,
> it just doesn't exist on the film...  Something's wrong...
>
> Austin
>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT
> <http://rd.yahoo.com/M=212804.2460941.3878106.2225242/D=egroupweb/S=1705019182:HM/A=810373/R=0/*http://geocities.yahoo.com/ps/info?.refer=blrecs> 
>
> <http://rd.yahoo.com/M=212804.2460941.3878106.2225242/D=egroupweb/S=1705019182:HM/A=810373/R=1/*http://geocities.yahoo.com/ps/info?.refer=blrecs> 
>
>
>
> 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
>
> If you wish to receive no emails or just a daily digest, or you wish 
> to unsubscribe, please edit your Membership preferences by visiting 
> this same page.
>
> 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 
> &amp;amp;quot;flames.&amp;amp;quot;
> - 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 the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.




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

Hi Martin,

> Nothing like an example. So right or high bit justification places the
> 12-bit number in the upper end of the 16-bit space

I think you've confused your self a bit (no pun intended) with left and
right, and I possibly didn't help.

What you describe above would be LEFT bit or HIGH bit or MSB (Most
Significant Bit) justified...but the extra bits would be added on the RIGHT
side, after the LSB (Least Significant Bit).


1001_0110_1110

^            ^
|            |_ LSB, LOW, RIGHT side
|
|_ MSB, HIGH, LEFT side


The original binary number converted to 16 bits, MSB justified, LEFT
justified, HIGH bit justified ;-)


1001_0110_1110_0000

               ^
               |_ Extra 4 bits added on the RIGHT side


> and left or low bit
> justification puts it in the bottom end of the range.

That would be RIGHT bit justification...but the extra bits would be added on
the LEFT side.

The original 12 bit number converted to 16 bits, LSB justified, RIGHT
justified, LOW bit justified...

0000_1001_0110_1110

^
|_ Extra 4 bits added to the LEFT side


> It would seem that for raw scanning you would always want to do right

You mean LEFT bit justification...

> bit
> justification since the values would not be adjacent in 16-bit space.

It really doesn't matter, except remember, PS only actually uses 15
bits...so if you really had a full 16 bits, you are better off LOW bit
justified.

> Each
> adjacent pair of 12-bit values winds up 4-bits apart. 1001_0110_1110 is
> placed at 1001_0110_1110_0000 and 1001_0110_1111 is placed at
> 1001_0110_1111_0000.

Yes, except, again, it doesn't matter, except for possible PS issues.  You
need to set the setpoints and THEN expand the data over the entire 16 bit
range.  I believe the algorithm may work better if it works on contiguous
data (that's just a guess, I'd have to do some work to figure out why I say
that)...as in you set your setpoints on the contiguous data, then spread
them out over the 16 bit space.

>
> With Left bit justification all the 12-bit values remain adjacent

Again, you mean RIGHT, LSB, LOW bit justification...

> in 16-bit
> space. 1001_0110_1110 is placed at 0000_1001_0110_1110 and
> 1001_0110_1111 is
> placed at  0000_1001_0110_1111.
>
> As an alternative couldn't the programmer who wrote the scanning
> software do
> a combination of both? Place two bits on each end or one on one end and
> three on the other? That actually would seem to me to be the
> logical choice
> since the mapped data would then fall more in the middle of the 16-bit
> space.

Again, it really doesn't matter...as long as the relativity of the data is
maintained, and no data is lost.

> Maybe this is what is being done in Silverfast so that the values are not
> adjacent but still close enough together to cause problems if you
> do a curve
> type adjustment without spreading out the end points first. This
> would also
> explain why the raw data occupies a wider portion of the histogram display
> that you would expect if it was exactly adjacent.

Could be, and there should be gaps in the data.

Regards,

Austin

Bob,

Thanks for passing on that information. That ,coupled with Truman's earlier
remarks about PS basically being an 8-bit program with some 16-bit
functionality tacked on, rings true. Someone else mentioned to me once that
giving full 16-bit capability to PS would involve a total rewrite of the
program's core.

What is really disturbing is that Adobe's PS team seems to contain little
ability to make changes on the core level and can only add new bells and
whistles. Not that some of the things in PS7 aren't nice. The healing brush
is great, nice to have larger brush sizes and file handling but I see these
as pretty trivial. Seems like they can only do so much of this before the
upgrades become thinner and thinner.

The other major problem with PS is memory handling. It does not work well
with Window's memory management and does not efficiently handle memory with
very large files. I suspect this is also an issue that can only be resolved
at the core level of the software.

Unfortunately they have no serious competition but sooner or later I suspect
that age core software will have to be redone.

Martin Wesley

http://www.borderless-photos.de/guests.html



----- Original Message -----
From: "Bob Frost" <bobfrost@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Sunday, October 13, 2002 5:58 AM
Subject: Re: [Digital BW] Re: 'combed' histograms in 16 bit ?


> Martin,
>
> Here's what Russel Williams had to say on this on the Epson-inkjet list
not
> so long ago:
>
> "As for 16 bit layers, here's a revised version of an item I've posted in
> the
> past.
>
> While we generally try to add 16 bit support over time, there is no crash
> program (nor is one currently contemplated) to make all features work in
16
> bit. The reason is not laziness. We have a fixed amount of money and time
to
> spend on improving Photoshop, and we have to choose how to spend it to
> provide the most benefit to the most users -- and that includes attracting
> new users.
>
> That said, I realize that the number of 16 bit image sources is
increasing,
> and the 16 bit images from digital cameras tend to be smaller and thus
more
> manageable than the high resolution scans that were the previously most
> common source. If your raw scan was 100-200MB, getting the big curves
moves
> done and then cutting the image size in half was an obvious win on its own
> merits. If your digicam file is 10-20MB, cutting it in half is much less
of
> an issue.
>
> The 16 bit features already in Photoshop provide most of the benefit to be
> had from 16 bit mode -- once you make your large adjustments in 16 bit,
> there is -- for most users most of the time -- very little reason to keep
> the image in 16 bit (and keep in mind that the percentage of users who
> *ever* work in 16 bit is still small to begin with). So full support for
> everything in 16 bit would only help a very small number of users a small
> percentage of the time. How many copies of Photoshop 6 would we have sold
if
> the only feature was "16 bit everything"?
>
> Such support would be *extremely* expensive. There are hundreds of
routines
> that perform graphics operations in Photoshop -- thousands if you include
> the plugins. Every one of them would have to be duplicated. Further, there
> are already several versions of many of those routines -- Intel assembly,
> PPC assembly, MMX accelerated, AltiVec accelerated, SSE accelerated. In
> order for 16 bit operations to be *only* twice as slow as 8 bit
operations,
> many of those low level routines would have to be hand-optimized as well,
> with separate versions written for different processors.
>
> Finally, most of the people on the Photoshop team are not skilled in
writing
> and optimizing the low level graphics routines. Photoshop is a huge
> application and the team has a wide diversity of skills. We no more have
the
> ability to put all our resources into 16-bitness for a single release than
> we do to put them all on typography for a single release.
>
> The question isn't "should we do 16 bit everything?", but "is it worth
> giving up a long list of other more generally useful features over a long
> period of time to do 16 bit everything?" Not surprisingly, the answer has
> always turned out to be "no".
>
> Russell Williams
> not speaking for Adobe Systems"
>
> ----- Original Message -----
> From: "Martin Wesley" <mwesley250@...>
> >
> > You can make due but life would be simpler if you had the choice to stay
> in
> > high bit mode. This would be the biggest upgrade Adobe could make to PS.
> Of
> > course this would require some real programming work on the core of PS I
> > image and I have heard that PS is not one of their big money makers, so
I
> am
> > not holding my breath. I wish Picture Window Pro had a decent user
> interface
> > and would move a lot of my work to there.
>
>
>
> 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
>
> If you wish to receive no emails or just a daily digest, or you wish to
unsubscribe, please edit your Membership preferences by visiting this same
page.
>
> 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
&amp;amp;quot;flames.&amp;amp;quot;
> - 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/
>
>
>