Digital BW, The Print

--- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley"
<mwesley250@e...> wrote:
> Would you have the time to run us through your workflow camera to 
> print?

OK Martin, here goes. As concise as possible, if it's too concise
just ask questions-
Any Dan Culbertson method mentioned can be found on his pages in the
bookmark section for this list.

A custom CMYK ink setup is required, though I learned this from Dan
I'm not sure how much is on his site about it. Basically 
a photospectrometer is used to measure the exact color, and dot gain,
of each of the inks and combinations, then entered 
in Photoshop. One is required for each paper you want to use, the
differences can be surprising, or not.

5x7, TMY with normal zone system approach, TriX for extreme
compactions
120, XP2 exposed for shadows, C41 lab processing

Agfa T2500 scanner, grayscale, 16 bit 1250 dpi for 5x7, 16 bit 2500
dpi for 120

8 bit dupe, all tonal editing done as masked adjustment layers. After
proofs look good, each mask and adjustment is loaded 
to the 16 bit file. Sharpen (very little) with Deep Bit Filters, even
though PS6 will sharpen 16 bit files, I think DBF does a little 
better job. Spot with the rubber stamp tool, resize (don't resample)
to print size, save as "printer".

The following is all built into an action-
Convert to CMYK using Dan's high bit method. There are several steps
but you wind up with a 16 bit per channel CMYK file 
with all the original grayscale info in each of the 4 channels.
Apply separation curves, developing the curves is a huge separate
topic.
With the custom CMYK ink setup, Photoshop previews on the monitor
exactly what all this will look like.
Convert to 8 bit

Then print-
3000 printer, PressReady RIP, Piezography inks, Wells River paper for
now.

Recently I've been using Dan's Profiler Pro RGB preview method
developing RGB workflows for other purposes with the RGB 
driver, it works extraordinarily well. For my personal work, the
above still gives me the best results for what I'm after.
There are a lot of aspects I've glossed over, but that's the guts of
it.
Tyler

Tyler,

Thanks for laying out your process for us. I always wanted to move up 
from 4x5 to 5x7 but the cost of moving up to an enlarger that size 
made it more than a bit pricey. However, digital really changes the 
equation and working in 5x7 or even 8x10 gives you a real advantage 
when it comes to scanning. (Agfa T2500 is now down to $3200 at Sparco 
by the way for those who are interested.)

The digital end of your workflow is highly customized and I can only 
imagine the amount of work you had to put into it. This is 
essentially what we all need to do. That is calibrating the entire 
process from start to finish for each of the sets of materials we 
use. Given an established film exposure and development process. (I 
am inclined to leave mine as it is in case I want to take a neg back 
into the darkroom.)

The difficulty seems to be in the amount of expertise and equipment 
required to close the feedback loop from monitor to print in a series 
of iterations to bring it all to a workable point.

I have a couple of questions. When you are adjusting in 8-bit how do 
you do your proofing? You mention loading all of the layer and 
adjustment information from the 8-bit work file back to the 16-bit 
file, how is this done?

Thanks,
Martin Wesley

 

--- In DigitalBlackandWhiteThePrint@y..., "Tyler Boley" <tyler@t...> 
wrote:
> --- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley"
> <mwesley250@e...> wrote:
> > Would you have the time to run us through your workflow camera to 
> > print?
> 
> OK Martin, here goes. As concise as possible, if it's too concise
> just ask questions-
> Any Dan Culbertson method mentioned can be found on his pages in the
> bookmark section for this list.
> 
> A custom CMYK ink setup is required, though I learned this from Dan
> I'm not sure how much is on his site about it. Basically 
> a photospectrometer is used to measure the exact color, and dot 
gain,
> of each of the inks and combinations, then entered 
> in Photoshop. One is required for each paper you want to use, the
> differences can be surprising, or not.
> 
> 5x7, TMY with normal zone system approach, TriX for extreme
> compactions
> 120, XP2 exposed for shadows, C41 lab processing
> 
> Agfa T2500 scanner, grayscale, 16 bit 1250 dpi for 5x7, 16 bit 2500
> dpi for 120
> 
> 8 bit dupe, all tonal editing done as masked adjustment layers. 
After
> proofs look good, each mask and adjustment is loaded 
> to the 16 bit file. Sharpen (very little) with Deep Bit Filters, 
even
> though PS6 will sharpen 16 bit files, I think DBF does a little 
> better job. Spot with the rubber stamp tool, resize (don't resample)
> to print size, save as "printer".
> 
> The following is all built into an action-
> Convert to CMYK using Dan's high bit method. There are several steps
> but you wind up with a 16 bit per channel CMYK file 
> with all the original grayscale info in each of the 4 channels.
> Apply separation curves, developing the curves is a huge separate
> topic.
> With the custom CMYK ink setup, Photoshop previews on the monitor
> exactly what all this will look like.
> Convert to 8 bit
> 
> Then print-
> 3000 printer, PressReady RIP, Piezography inks, Wells River paper 
for

> now.
> 
> Recently I've been using Dan's Profiler Pro RGB preview method
> developing RGB workflows for other purposes with the RGB 
> driver, it works extraordinarily well. For my personal work, the
> above still gives me the best results for what I'm after.
> There are a lot of aspects I've glossed over, but that's the guts of
> it.
> Tyler

--- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley"
<mwesley250@e...> wrote:
>.....Given an established film exposure and development process. (I 
> am inclined to leave mine as it is in case I want to take a neg
back 
> into the darkroom.)

I haven't changed mine for scanning Martin, my negs are pretty dense.
I understand people are altering their exposure/
developement to optimize for scanning, but I'm hesitant to go that
route, and I'm dead tired of calibrationg! It seems to 
work fine this way, sometimes I scan difficult negs as tranperancies,
which can really help.
> 
> The difficulty seems to be in the amount of expertise and equipment 
> required to close the feedback loop from monitor to print in a
series 
> of iterations to bring it all to a workable point.

It really didn't take that long to learn, most of it is on Dan's
pages. The equipment is another problem, it's hard to justify the 
cost of a photospecrometer, but since I was beta testing profiling
software and inks, I went ahead with it. I was trying to 
develope curves all kinds of ways, by eye, or with a scanner. That
was ok up to a point. I sent Dan a case of Absolute in 
exchange for some ink/paper setup measurements and everything I was
battling fell into place, that convinced me I had to 
have one. It can be done without one, but it takes a lot more time
and some problems are just never found, I'd rather make 
prints. I didn't hear from him for several months, so maybe that was
a bad bad thing...
What takes more time and learning, and is far more interesting, is
the nature of ink on paper and how to find problems and 
create something beautiful. It's an ongoing process, just like
traditional printing.
> 
> I have a couple of questions. When you are adjusting in 8-bit how
do 
> you do your proofing?

I just save where I am, flatten the file and size it to what I want
to see as a test, save it as a temp/test, run it through the 
grayscale-CMYK-seps action, and print. Sometimes I use a cheaper
paper like EAM because it takes the ink similarly, but I 
still wind up needing to see one on the real paper because it feels
so different, even if it's the same tonaly.

> You mention loading all of the layer and 
> adjustment information from the 8-bit work file back to the 16-bit 
> file, how is this done?
> 
I think Bruce Fraser has an article about it somewhere. You have your
8 bit file with adjustment layers, and your 16 bit file 
open at the same time. In the 8 bit, open the adjustment layer and
save the curve (level, whatever it is) to the desktop, 
leave that layer selected. Switch to your 16 bit file and go to "load
selection", you will have the option of loading the layer 
mask from the 8 bit file layer, do it. Open curves and load the one
on your desktop that was saved. Now do that with each 
adjustment layer. Note that only edits available in 16 bit can be
done this way, but those are all I generally need.
After you've done this a few times, it goes real quick.
Tyler

--- In DigitalBlackandWhiteThePrint@y..., "Tyler Boley" <tyler@t...> 
wrote:
> --- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley"
> <mwesley250@e...> wrote:
> >.....Given an established film exposure and development process. 
(I 
> > am inclined to leave mine as it is in case I want to take a neg
> back 
> > into the darkroom.)
> 
> I haven't changed mine for scanning Martin, my negs are pretty 
dense.
> I understand people are altering their exposure/
> developement to optimize for scanning, but I'm hesitant to go that
> route, and I'm dead tired of calibrationg! It seems to 
> work fine this way, sometimes I scan difficult negs as 
tranperancies,
> which can really help.

At least that is one place I have stopped experimenting. (I think.)

> > 
> > The difficulty seems to be in the amount of expertise and 
equipment 
> > required to close the feedback loop from monitor to print in a
> series 
> > of iterations to bring it all to a workable point.
> 
> It really didn't take that long to learn, most of it is on Dan's
> pages. The equipment is another problem, it's hard to justify the 
> cost of a photospecrometer, but since I was beta testing profiling
> software and inks, I went ahead with it. I was trying to 
> develope curves all kinds of ways, by eye, or with a scanner. That
> was ok up to a point. I sent Dan a case of Absolute in 
> exchange for some ink/paper setup measurements and everything I was
> battling fell into place, that convinced me I had to 
> have one. It can be done without one, but it takes a lot more time
> and some problems are just never found, I'd rather make 
> prints. I didn't hear from him for several months, so maybe that was
> a bad bad thing...
> What takes more time and learning, and is far more interesting, is
> the nature of ink on paper and how to find problems and 
> create something beautiful. It's an ongoing process, just like
> traditional printing.

What do you recommend for an instrument to do this? I have seen the 
Spectrocam at InkJetMall for $1,400 and the X-RiteColor Digital 
Swatchbook also about $1,400. Is there a lower price point to get 
into this?

I suspect there is a sense that since we are doing B&W, things like 
color calibration are not so important. The deeper I get into this 
the more that seems untrue. In fact it may be even more important as 
subtle shifts may be more visible than they are in color printing.

I assume that this type of measurement and adjustment is also valid 
for printing through the Epson driver as well as through the RIP?

> > 
> > I have a couple of questions. When you are adjusting in 8-bit how
> do 
> > you do your proofing?
> 
> I just save where I am, flatten the file and size it to what I want
> to see as a test, save it as a temp/test, run it through the 
> grayscale-CMYK-seps action, and print. Sometimes I use a cheaper
> paper like EAM because it takes the ink similarly, but I 
> still wind up needing to see one on the real paper because it feels
> so different, even if it's the same tonaly.
> 
> > You mention loading all of the layer and 
> > adjustment information from the 8-bit work file back to the 16-
bit 
> > file, how is this done?
> > 
> I think Bruce Fraser has an article about it somewhere. You have 
your
> 8 bit file with adjustment layers, and your 16 bit file 
> open at the same time. In the 8 bit, open the adjustment layer and
> save the curve (level, whatever it is) to the desktop, 
> leave that layer selected. Switch to your 16 bit file and go 
to "load
> selection", you will have the option of loading the layer 
> mask from the 8 bit file layer, do it. Open curves and load the one
> on your desktop that was saved. Now do that with each 
> adjustment layer. Note that only edits available in 16 bit can be
> done this way, but those are all I generally need.
> After you've done this a few times, it goes real quick.

I think it is past time for me to get a copy of Real World Photoshop 
(Blatner and Fraser). In playing with this I notice that the 
histogram is filled and smoother in comparing the adjusted 16-bit 
file to the 8-bit.

This is really the work around that allows you to "stay" in 16-bit 
Grayscale to do all you your level adjustments.

Since you are printing with the Piezo inks can you give us a 
comparison of the results using your system verses just printing 
through the Piezo driver?

I believe in your last post you said you drop down to 8-bit just 
before printing. Is this required to work with the RIP or is this 
just to reduce file size at this point?

This is all very enlightening stuff. Thank you!

Martin

snip 
> A custom CMYK ink setup is required, though I learned this from Dan
> I'm not sure how much is on his site about it. Basically
> a photospectrometer is used to measure the exact color, and dot gain,
> of each of the inks and combinations, then entered
> in Photoshop. One is required for each paper you want to use, the
> differences can be surprising, or not.

Wrote that up once -- but Real World Photoshop (Blatner and Fraser) does a
better job.  Color ink, gray ink makes no difference - same instructions for
all.   My instructions are at
http://www.geocities.com/campfiredan/infoshare/Misc_Quad_info/Set_ink_colors
.html   Provided that the fates (and Geocities) allow you can sometimes get
to that link.  Probably have to cut and paste the URL into the address line
since it is so long the email will chop it into two.  Note I haven't updated
this for Photoshop 6 but it works pretty much the same as PS 5.

> Convert to CMYK using Dan's high bit method. There are several steps
> but you wind up with a 16 bit per channel CMYK file
> with all the original grayscale info in each of the 4 channels.

That High Bit one is at
http://www.geocities.com/campfiredan/infoshare/HiBitQuad/

Dan Culbertson

Dan, 

next time you need to refer to these, just point to our Bookmarks section, 
under "Printing-related instructions". Check it out, seems to work instantly!
Of course, if you decide to revise your end of the link, please drop me a line.

Thanks

Antonis

--- In DigitalBlackandWhiteThePrint@y..., Dan Culbertson <danculb@b...> 
wrote:
..
Wrote that up once -- but Real World Photoshop (Blatner and Fraser) does a
> better job.  Color ink, gray ink makes no difference - same instructions for
> all.   My instructions are at
> 
http://www.geocities.com/campfiredan/infoshare/Misc_Quad_info/Set_ink_col
ors
> .html
....

> That High Bit one is at
> http://www.geocities.com/campfiredan/infoshare/HiBitQuad/
> 
> Dan Culbertson

--- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley" <
mwesley250@e...> wrote:
> What do you recommend for an instrument to do this? I have seen the 
> Spectrocam at InkJetMall for $1,400 and the X-RiteColor Digital 
> Swatchbook also about $1,400. Is there a lower price point to get 
> into this?

I believe there is one called the ColorMouse that is much cheaper,
and 
you may be able to find a better price on the others by shopping 
around. Dan can tell you more about the Swatchbook. But all you'll be 
able to do with them is measure inks for CMYK custom setups for a
CMYK 
workflow like I use. It's really not a workflow I recommend for many, 
you'll need a RIP, there aren't many good ones, or affordable ones. 
For the printer/paper/ink combo I use it's great for the look I'm 
after. But for most an RGB workflow or Piezography will be better.
If you want to use a photospectrometer to nail Dan's RGB workflow, 
you'll also need Profiler Pro, another investment. There have been no 
reports that any other software can tough it out and actually build a 
profile from non color inks.
You could build a CMYK ink setup as above, but using the RGB driver, 
work in CMYK, then do Dan's CMYK/Multichannel/RGB conversion to
print, 
but you'll have some black ink things to solve by eye. For everything 
up until K kicks in, it would work well.
> 
> I assume that this type of measurement and adjustment is also valid 
> for printing through the Epson driver as well as through the RIP?
> 
See above, PS6 and Profiler Pro will actually allow you to see a real 
preview of your actual inks on the monitor using Dan's method.
Notice how often Dan is mentioned? I'm not sure it's possible to
print 
quads and not be a Dannite, even unwittingly. If I knew whether the 
chicken or the egg came first, I could even suggest the Cone driver
is 
Dannite.

> I think it is past time for me to get a copy of Real World
Photoshop 
> (Blatner and Fraser). In playing with this I notice that the 
> histogram is filled and smoother in comparing the adjusted 16-bit 
> file to the 8-bit.

Convert your 8 bit to RGB, run the sep curves and look how bad it is 
then!
Now do the same with the 16 bit staying in 16 bit all the way and 
you'll see quite an improvement. Does it print better?

> I believe in your last post you said you drop down to 8-bit just 
> before printing.

PressReady won't accept 16 bit files, since all the damage has been 
done at that point, dropping down doesn't really hurt. Even though
the 
Epson driver lets you hit the print command out of PS6 in 16 bit, I'm 
sure it's dropping it down on the fly, rather than making real use of 
all those bits.
I was hoping no one was actually paying attention enough to ask me
why 
I don't use the Cone driver! I was doing this workflow before it came 
out with different inks and it was hard to let go of direct control
of 
the inks. I can tweak a few things a little more to my liking, the 
black and overall hue of my prints are subtly different than with the 
Cone driver.The tonal transitions and dithering with his driver and 
profiles are so great, it was very hard to aproach that level of 
quality, and I'd never suggest I bettered it.
Tyler

> Convert your 8 bit to RGB, run the sep curves and look how bad it is
> then!
> Now do the same with the 16 bit staying in 16 bit all the way and
> you'll see quite an improvement. Does it print better?

Does it?

Todd

--- In DigitalBlackandWhiteThePrint@y..., "Tyler Boley" <tyler@t...> 
wrote:

(snip)
> 
> I believe there is one called the ColorMouse that is much cheaper,
> and 
> you may be able to find a better price on the others by shopping 
> around. Dan can tell you more about the Swatchbook. But all you'll 
be 
> able to do with them is measure inks for CMYK custom setups for a
> CMYK 
> workflow like I use. It's really not a workflow I recommend for 
many, 
> you'll need a RIP, there aren't many good ones, or affordable ones. 
> For the printer/paper/ink combo I use it's great for the look I'm 
> after. But for most an RGB workflow or Piezography will be better.
> If you want to use a photospectrometer to nail Dan's RGB workflow, 
> you'll also need Profiler Pro, another investment. There have been 
no 
> reports that any other software can tough it out and actually build 
a 
> profile from non color inks.
> You could build a CMYK ink setup as above, but using the RGB 
driver, 
> work in CMYK, then do Dan's CMYK/Multichannel/RGB conversion to
> print, 
> but you'll have some black ink things to solve by eye. For 
everything 
> up until K kicks in, it would work well.
> > 
> > I assume that this type of measurement and adjustment is also 
valid 
> > for printing through the Epson driver as well as through the RIP?
> > 
> See above, PS6 and Profiler Pro will actually allow you to see a 
real 
> preview of your actual inks on the monitor using Dan's method.
> Notice how often Dan is mentioned? I'm not sure it's possible to
> print 
> quads and not be a Dannite, even unwittingly. If I knew whether the 
> chicken or the egg came first, I could even suggest the Cone driver
> is 
> Dannite.

I need to go over Dan's material again but I am very interested in 
closing the monitor to printer loop with greater accuracy than my 
eyes, so this may be the way to go. I can also see the payback in 
working with many different papers using the MIS VM inks where you 
are changing tone as well as. I would love to get a profile for the 
Elcipse papers for example which did not come close to any of the 
Piezo curves. I don't know that I want to have to wait for someone 
else to do all the work.

> 
> > I think it is past time for me to get a copy of Real World
> Photoshop 
> > (Blatner and Fraser). In playing with this I notice that the 
> > histogram is filled and smoother in comparing the adjusted 16-bit 
> > file to the 8-bit.
> 
> Convert your 8 bit to RGB, run the sep curves and look how bad it 
is 
> then!
> Now do the same with the 16 bit staying in 16 bit all the way and 
> you'll see quite an improvement. Does it print better?

I need to start from scratch on this process and compare. My other 
thought is to work entirely in 8-bit RGB. I develop my film in pyro 
so I have different data sets on each channel from a raw scan. A side 
by side comparision seems in order.
> 
> > I believe in your last post you said you drop down to 8-bit just 
> > before printing.
> 
> PressReady won't accept 16 bit files, since all the damage has been 
> done at that point, dropping down doesn't really hurt. Even though
> the 
> Epson driver lets you hit the print command out of PS6 in 16 bit, 
I'm 
> sure it's dropping it down on the fly, rather than making real use 
of 
> all those bits.
> I was hoping no one was actually paying attention enough to ask me
> why 
> I don't use the Cone driver! I was doing this workflow before it 
came 
> out with different inks and it was hard to let go of direct control
> of 
> the inks. I can tweak a few things a little more to my liking, the 
> black and overall hue of my prints are subtly different than with 
the 
> Cone driver.The tonal transitions and dithering with his driver and 
> profiles are so great, it was very hard to aproach that level of 
> quality, and I'd never suggest I bettered it.

I have found it a good idea to stay with a workflow (computer, 
camera, enlarger,..) that is going well for you unless something 
offers a really big jump in quality. In making the switch I always 
seem to lose ground until I figure out the quirks of the new process.

Thanks again for all the info!

Martin

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...>
wrote:
> 
> 
> > Convert your 8 bit to RGB, run the sep curves and look how bad it
is
> > then!
> > Now do the same with the 16 bit staying in 16 bit all the way and
> > you'll see quite an improvement. Does it print better?
> 
> Does it?
> 
> Todd

Todd,
dude,
I happen to know you could answer that as well as anyone using RGB
workflow.
....Well?
....Does it?
Tyler

>>> Convert your 8 bit to RGB, run the sep curves and look how bad it
> is
>>> then!
>>> Now do the same with the 16 bit staying in 16 bit all the way and
>>> you'll see quite an improvement. Does it print better?
>> 
>> Does it?
>> 
>> Todd
> 
> Todd,
> dude,
> I happen to know you could answer that as well as anyone using RGB
> workflow.
> ....Well?
> ....Does it?
> Tyler
> 

Well, I haven't done enough side-by-side comparisons to say with certainty.
And of course I don't think there is a certainty. There is a percentage of
occurrence. On the few occasions where I thought I saw a difference, on the
monitor, I've gone back at other times and not seen it. It's possible I was
looking at them at a poor monitor magnification, IE, 67%.

I have been able to make 8bit images fall apart, but only by starting with
REALLY lousy files, and torturing them. I don't think it's happened in
*normal* use yet. I'm rather certain that two opposing sides of the debate
could make compelling arguments to "prove" their case, but it still would
not finalize anything because to fulfill on the 16-bit advantage requires a
higher equipment cost, and a more labored workflow, but it may never fail
you, while an 8-bit workflow may be more economical, and more efficient, and
only fail you once in your lifetime - so who's right?

So, I like collecting anecdotal evidence from others. It's very easy to see
the degradation in histograms, but whether dropped tones translates to a
difference in print, where the eye can only distinguish 80-100 tones at once
(or so I've heard), is really the million dollar question.

I'm sure in some circumstances it happens, but I suspect it's rather rare.
When PS *fully* supports 16-bit files, the whole debate will be a no
brainer, but until then I wonder if we need to drive a tank for safety, when
a nice little convertible will get us there so much more swiftly, and
usually safely.

So, while we've discussed this before, and I know you've said there have
been occasions where you've seen a difference, I don't recall if you were
judging a monitor representation, or print, and if you found it repeatable.
It's not a big deal, we know each others work flow, and we both proceed
cautiously, but in slightly different ways. And you know I do think it's
possible we feel things in an image we can't measure or define, but I don't
know if you've seen the difference in print, and if the circumstances were
normal to your workflow, or something rare or a contrived. In the same way I
believe we can feel things we can't define, I also wonder if the logic of a
16-bit workflow, and the measurability of improved performance, as evidenced
by the histogram, don't convince us we see a difference because we suspect
we should.

Again, not a big deal, it's just a subject I haven't tired of bantering
about yet.

Todd

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> wrote:

I'm sorry, I didn't realize I was in a debate, on a side, had a case to prove, or was bantering. It's simply an idea that may or 
may not be useful, and if anyone is trying it perhaps their results will tell us something. Since I knew you had been trying it 
with a workflow different than mine, and certainly more commonly used here than mine, your observations would be 
helpful, and they are.
Thanks,
Tyler

> 
> Well, I haven't done enough side-by-side comparisons to say with certainty.
> And of course I don't think there is a certainty. There is a percentage of
> occurrence. On the few occasions where I thought I saw a difference, on the
> monitor, I've gone back at other times and not seen it. It's possible I was
> looking at them at a poor monitor magnification, IE, 67%.
> 
> I have been able to make 8bit images fall apart, but only by starting with
> REALLY lousy files, and torturing them. I don't think it's happened in
> *normal* use yet. I'm rather certain that two opposing sides of the debate
> could make compelling arguments to "prove" their case, but it still would
> not finalize anything because to fulfill on the 16-bit advantage requires a
> higher equipment cost, and a more labored workflow, but it may never fail
> you, while an 8-bit workflow may be more economical, and more efficient, and
> only fail you once in your lifetime - so who's right?
> 
> So, I like collecting anecdotal evidence from others. It's very easy to see
> the degradation in histograms, but whether dropped tones translates to a
> difference in print, where the eye can only distinguish 80-100 tones at once
> (or so I've heard), is really the million dollar question.
> 
> I'm sure in some circumstances it happens, but I suspect it's rather rare.
> When PS *fully* supports 16-bit files, the whole debate will be a no
> brainer, but until then I wonder if we need to drive a tank for safety, when
> a nice little convertible will get us there so much more swiftly, and
> usually safely.
> 
> So, while we've discussed this before, and I know you've said there have
> been occasions where you've seen a difference, I don't recall if you were
> judging a monitor representation, or print, and if you found it repeatable.
> It's not a big deal, we know each others work flow, and we both proceed
> cautiously, but in slightly different ways. And you know I do think it's
> possible we feel things in an image we can't measure or define, but I don't
> know if you've seen the difference in print, and if the circumstances were
> normal to your workflow, or something rare or a contrived. In the same way I
> believe we can feel things we can't define, I also wonder if the logic of a
> 16-bit workflow, and the measurability of improved performance, as evidenced
> by the histogram, don't convince us we see a difference because we suspect
> we should.
> 
> Again, not a big deal, it's just a subject I haven't tired of bantering
> about yet.
> 
> Todd

Well, you've certainly done a nice job of plucking all the negative words
out of what I said to make it look like I'm up to no good. All I was asking
was if you saw a difference in print, then explained why I was asking. No
problem, I'll stop asking.

Todd

> I'm sorry, I didn't realize I was in a debate, on a side, had a case to prove,
> or was bantering. It's simply an idea that may or
> may not be useful, and if anyone is trying it perhaps their results will tell
> us something. Since I knew you had been trying it
> with a workflow different than mine, and certainly more commonly used here
> than mine, your observations would be
> helpful, and they are.
> Thanks,
> Tyler
>> 
>> Well, I haven't done enough side-by-side comparisons to say with certainty.
>> And of course I don't think there is a certainty. There is a percentage of
>> occurrence. On the few occasions where I thought I saw a difference, on the
>> monitor, I've gone back at other times and not seen it. It's possible I was
>> looking at them at a poor monitor magnification, IE, 67%.
>> 
>> I have been able to make 8bit images fall apart, but only by starting with
>> REALLY lousy files, and torturing them. I don't think it's happened in
>> *normal* use yet. I'm rather certain that two opposing sides of the debate
>> could make compelling arguments to "prove" their case, but it still would
>> not finalize anything because to fulfill on the 16-bit advantage requires a
>> higher equipment cost, and a more labored workflow, but it may never fail
>> you, while an 8-bit workflow may be more economical, and more efficient, and
>> only fail you once in your lifetime - so who's right?
>> 
>> So, I like collecting anecdotal evidence from others. It's very easy to see
>> the degradation in histograms, but whether dropped tones translates to a
>> difference in print, where the eye can only distinguish 80-100 tones at once
>> (or so I've heard), is really the million dollar question.
>> 
>> I'm sure in some circumstances it happens, but I suspect it's rather rare.
>> When PS *fully* supports 16-bit files, the whole debate will be a no
>> brainer, but until then I wonder if we need to drive a tank for safety, when
>> a nice little convertible will get us there so much more swiftly, and
>> usually safely.
>> 
>> So, while we've discussed this before, and I know you've said there have
>> been occasions where you've seen a difference, I don't recall if you were
>> judging a monitor representation, or print, and if you found it repeatable.
>> It's not a big deal, we know each others work flow, and we both proceed
>> cautiously, but in slightly different ways. And you know I do think it's
>> possible we feel things in an image we can't measure or define, but I don't
>> know if you've seen the difference in print, and if the circumstances were
>> normal to your workflow, or something rare or a contrived. In the same way I
>> believe we can feel things we can't define, I also wonder if the logic of a
>> 16-bit workflow, and the measurability of improved performance, as evidenced
>> by the histogram, don't convince us we see a difference because we suspect
>> we should.
>> 
>> Again, not a big deal, it's just a subject I haven't tired of bantering
>> about yet.
>> 
>> Todd

Because of my poor communication skills, I've given you precisely the opposite impression I intended. I'm really sorry, and 
I certainly hope no one stops asking questions.
I certainly do see a difference in prints, but it seems image dependent, and occasional, and subtle. I don't recall seeing a 
difference on the monitor.
Sorry Todd, and sorry list for my participation in this kind of exchange.
Tyler

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> wrote:

> Well, you've certainly done a nice job of plucking all the negative words
> out of what I said to make it look like I'm up to no good. All I was asking
> was if you saw a difference in print, then explained why I was asking. No
> problem, I'll stop asking.
> 
> Todd
> 
> > I'm sorry, I didn't realize I was in a debate, on a side, had a case to prove,
> > or was bantering. It's simply an idea that may or
> > may not be useful, and if anyone is trying it perhaps their results will tell
> > us something. Since I knew you had been trying it
> > with a workflow different than mine, and certainly more commonly used here
> > than mine, your observations would be
> > helpful, and they are.
> > Thanks,
> > Tyler

No apologies necessary, my mistake!

I see how my wording made it seem I was polarizing *us* onto opposite sides
of a debate, but I was really trying to define "the debate" as I've seen it
elsewhere. I don't mean to banter (actually I though that meant to chat
until I looked up the word just now) or draw sides with you at all, I assure
you. I just mean to pick your brain.

Thanks for the clarification of what you see. That matches my experience
too.

Please forgive,
Todd

> Because of my poor communication skills, I've given you precisely the opposite
> impression I intended. I'm really sorry, and
> I certainly hope no one stops asking questions.
> I certainly do see a difference in prints, but it seems image dependent, and
> occasional, and subtle. I don't recall seeing a
> difference on the monitor.
> Sorry Todd, and sorry list for my participation in this kind of exchange.
> Tyler
> 
> --- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> wrote:
>> Well, you've certainly done a nice job of plucking all the negative words
>> out of what I said to make it look like I'm up to no good. All I was asking
>> was if you saw a difference in print, then explained why I was asking. No
>> problem, I'll stop asking.
>> 
>> Todd
>> 
>>> I'm sorry, I didn't realize I was in a debate, on a side, had a case to
>>> prove,
>>> or was bantering. It's simply an idea that may or
>>> may not be useful, and if anyone is trying it perhaps their results will
>>> tell
>>> us something. Since I knew you had been trying it
>>> with a workflow different than mine, and certainly more commonly used here
>>> than mine, your observations would be
>>> helpful, and they are.
>>> Thanks,
>>> Tyler
> 
> 
> 
> 
> 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
> 
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> 
>