Digital BW, The Print

Not sure why this happens but I have noticed that some grayscale images that
I convert to RGB end up with gaps in the shadow end of the luminosity
histogram immediately after conversion.  Gaps that were not there before
conversion.   My solution is to convert from grayscale to multichannel,
create two copies of the original grayscale channel, then convert from
multichannel to RGB.  If you are using any process that requires you to
convert your grayscale file to RGB and apply curves, you may want to try
this additional conversion step - especially if you have noticed any
posterization happening in the shadows.  Definitely shows up in a print of a
grayscale gradient converted to RGB with any significant curve manipulation.

-- Dan Culbertson
so many years, so little time...

Dan,

it would make sense that a gs-to-RGB would stretch and twist that poor gs 
trying to fit it into whatever profile you have set for RGB (including a possible 
gamma change). Doing channel copies in multichannel mode and then RGB 
should be the more profile-neutral way to go. Great pointer, thanks!

Antonis

--- In DigitalBlackandWhiteThePrint@y..., Dan Culbertson <danculb@b...> 
wrote:

... My solution is to convert from grayscale to multichannel,

> create two copies of the original grayscale channel, then convert from
> multichannel to RGB.  If you are using any process that requires you to
> convert your grayscale file to RGB and apply curves, you may want to try
> this additional conversion step - especially if you have noticed any
> posterization happening in the shadows.

> Dan,
> 
> it would make sense that a gs-to-RGB would stretch and twist that poor gs
> trying to fit it into whatever profile you have set for RGB (including a
> possible 
> gamma change). Doing channel copies in multichannel mode and then RGB
> should be the more profile-neutral way to go. Great pointer, thanks!
> 
> Antonis

I just now figured out what peculiar thing I was doing that made this
problem sporadic.  Normally I deal with grayscale images in a gamma 2.2
space.  If I convert to RGB I convert to Adobe RGB - a gamma 2.2 RGB space.
No problem.  The problem came when I got a file with a black to white
gradient in ColorMatch RGB.  Because I needed the overall image in grayscale
to test a B&W process I converted this to a 1.8 gamma gray space (so far so
good - histogram just fine).  Then, as part of an RGB process I was testing,
I converted it to my standard Adobe RGB space (2.2 gamma).  Poof - garbage
histogram and posterization in the shadows.  So I solved that by using a
Multichannel duplication process to get back to my Adobe RGB preference
rather than a gray to RGB conversion.

After a midnight "Aha!!!" experience, this morning I created a new file with
a black and white gradient in a 1.8 gamma gray space then converted it to a
2.2 gamma gray space.  The histogram exhibited the same gaps in the shadow
region as the conversion process I was using before.  Of course I had *just*
provided advice to a list member advising that grayscale files, if they are
to be converted to RGB, should go into an RGB space with the same gamma --
then I violated my own advice (I can only claim sleep deprivation as an
excuse).  At any rate I proved my point - even if unintentionally - in
grayscale,  a 1.8 to a 2.2 gamma conversion (and vice versa) is hardly
lossless, and that applies when the conversion is into a different gamma RGB
space.  Don't convert to a different gamma working space unless there is no
alternative and if you *have* to convert into a different gamma RGB space
use a multichannel Channel duplication process rather than a simple mode
change.

-- Dan Culbertson
so many years, so little time...

Excellent advice Dan. Nothing like a midnight "Aha" experience (with or 
without Absolut).

;----)

Antonis

--- In DigitalBlackandWhiteThePrint@y..., Dan Culbertson <danculb@b...> 
wrote:

 Don't convert to a different gamma working space unless there is no

> alternative and if you *have* to convert into a different gamma RGB space
> use a multichannel Channel duplication process rather than a simple mode
> change.
> 
> -- Dan Culbertson
> so many years, so little time...

>> Dan knows his bits.

 > Never lose a bit if you can help it. :-)

Dan, you are so good simply because you, more than anyone else, really give
a bit....

Okay, this gamma stuff is starting to make some sense. The only thing I'd
like to review is the "gamma for print" concept. This gamma adjustment is
applied in the driver Space, and it is in lieu of a custom dot curve? One
makes a few, and tries them to see which yields the best print. Higher gamma
numbers darken the print, while lower numbers lighten it. Once one finds the
right gamma tweak, it should work for all images that follow suit, IOW,
images that are in that same working space and are printing to that same
printer/paper/ink combo. If the answer is yes, I'm finished; if no, I'm
getting some cheap vodka.

Todd

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...>
wrote:
> ...
snip...
>The only thing I'd
> like to review is the "gamma for print" concept. This gamma
adjustment is
> applied in the driver Space...

Todd, I don't mean to butt in, but why even fool with it? Why not
simply have a workflow from scan to print that leaves the 
file in the same gamma throughout? Between editing your scan, and
doing whatever separation methods you use, enough 
potential bit lose is occurring.
I haven't been following the thread, so maybe I missed something.
Tyler

> Dan knows his bits.
> 
> Thanks Martin, Tim and Dan.
> 
> Todd

Never lose a bit if you can help it. :-)    No magic here,  my multichannel
method avoids losing bits simply by going around the gamma change from 1.8
grayscale space to 2.2 RGB space (or vice versa).  It changes the image
appearance by avoiding changing the image numbers.  It is the same as doing
a grayscale  "Assign Profile" to the grayscale file then doing a "Convert to
Profile" to the same gamma RGB space.  In other words if you have a 1.8
gamma grayscale space and *assign* it a 2.2 gamma then convert to Adobe RGB
there will be no gamma change and therefore no histogram change.  The image
will change on screen but not the histogram.

This whole discussion just illustrates why you should not do any gamma
conversion until it is time to send the image to the printer (when it may be
necessary to make the image print correctly).  Open your grayscale scan with
no gamma conversion, assign your working gamma to it (if it isn't already
assigned by default), edit it with a curve as necessary to make it look
right, send it to the printer with the gamma tweak necessary to make it
print right.   If you use an intermediate RGB step and Adobe RGB is your
chosen RGB space then your working gamma is 2.2 and your grayscale gamma
should be that also.  If you typically use Colormatch RGB your working gamma
is 1.8 and  your grayscale gamma should match that.  Only time you get into
trouble (and need that workaround of mine) is when you are stuck with a file
in the wrong gamma space and just don't want to stay there (which was my
situation). I was converting a standard color file in ColorMatch RGB into a
standard B&W file in Adobe RGB and had to pass though grayscale mode in the
process.   Not *too* often you would have to do that, even with the odd
things folks do here on this list!   Bloom where you are planted, never
leave the gamma space your file was born in.  :-)

-- Dan Culbertson
so many years, so little time...

--- In DigitalBlackandWhiteThePrint@y..., Dan Culb
ertson<danculb@b...> 
wrote:
> Hi Tyler,
> The only problem is that the only way you can do that is to find
the 
gamma
> of the printer/ink/paper and stay in that space forever.  If you 
change any
> part of that you have to adjust gamma anyway....
snip...
Exactly. That's what I meant. What you are calling the gamma of a 
printer/paper/ink combo is compensated for within the workflow, your 
RGB curves. The grayscale scan, edits, conversion to RGB, and RGB 
separations all take place in the same gamma, 2.2, right?

>since I don't use a final gamma move in the final print process
> since I build it into the RGB curve.
Right, I thought the discussion was about the potential problems of 
doing a final gamma move which seems like something to be avoided. If 
an element like paper changes, new sepaprations would be best.
I suppose a file from a past life, saved in some other space,
presents 
a different problem.
I find your multi mode change method useful for all kinds of things.
I try to do one every morining with my first cup of coffee
Tyl

> Okay, this gamma stuff is starting to make some sense. The only thing I'd
> like to review is the "gamma for print" concept. This gamma adjustment is
> applied in the driver Space, and it is in lieu of a custom dot curve? One
> makes a few, and tries them to see which yields the best print. Higher gamma
> numbers darken the print, while lower numbers lighten it. Once one finds the
> right gamma tweak, it should work for all images that follow suit, IOW,
> images that are in that same working space and are printing to that same
> printer/paper/ink combo. If the answer is yes, I'm finished; if no, I'm
> getting some cheap vodka.
> 
> Todd

The answer is "Yes"  -- now go get some *good* vodka to celebrate!

Dan

> Todd, I don't mean to butt in, but why even fool with it? Why not
> simply have a workflow from scan to print that leaves the
> file in the same gamma throughout? Between editing your scan, and
> doing whatever separation methods you use, enough
> potential bit lose is occurring.
> I haven't been following the thread, so maybe I missed something.
> Tyler

Hi Tyler,
The only problem is that the only way you can do that is to find the gamma
of the printer/ink/paper and stay in that space forever.  If you change any
part of that you have to adjust gamma anyway.  So my strategy has been to
keep to a standard grayscale working space for all editing and convert to
the printer's gamma at print time.  Since I am using a softproof process I
stick with a standard gamma space for the grayscale editing, convert to RGB
(of the same gamma), and then separate the channels with an RGB curve using
the quadtone preview to match the tonal range of original grayscale.  In
other words, since I don't use a final gamma move in the final print process
since I build it into the RGB curve.  Then my RGB curve is saved for the
particular ink and paper combination with the file (turn it on and off at
print time).  Same as a last minute gamma change in the suggested process
but my RGB curve and gamma change are all done together.

This is exactly the same set of options you have with color printing -- scan
and edit in a CMYK print space and archive in that very precise space, or
scan and edit in a broader RGB space and have greater flexibility for output
-- with a profile applied at output time taking the file into the printer
space.  In the grayscale case the output profile has been replaced with a
custom gamma version of the RGB space (which replaces the typical custom dot
area curve which can't be used in RGB processes).  Both are good options
depending on how you want to archive the file.

Not sure which standard grayscale space is really the best for most printers
- or for most monitors, but Blatner and Fraser recommend 2.2 for RGB mode
for perceptual uniformity in editing and since I am going through RGB space
I use a gamma 2.2 grayscale working space to edit.  I could be totally wrong
on that choice though.  Some radical folks have suggested that a 1.0 gamma
would be the best working space - others swear by 1.8 since it is nearer to
most printer's natural print space.  But since there are many paper types
there will always have to be some way to get the file into a precise printer
space - even if just to compensate for small dot gain changes and (if you
use an RGB grayscale file with no profile) the only quick way to do that is
with a custom RGB space at print time.   The best way to do that is with a
custom RGB profile and a softproof (which holds true with either grayscale
printed to CMYK inks or to quad inks) but the original process under
discussion didn't use one so this RGB gamma tweak at print time was the
suggested alternative.

Dan

> Hi Tyler,
> The only problem is that the only way you can do that is to find the gamma
> of the printer/ink/paper and stay in that space forever.  If you change any
> part of that you have to adjust gamma anyway.  So my strategy has been to
> keep to a standard grayscale working space for all editing and convert to
> the printer's gamma at print time.  Since I am using a softproof process I
> stick with a standard gamma space for the grayscale editing, convert to RGB
> (of the same gamma), and then separate the channels with an RGB curve using
> the quadtone preview to match the tonal range of original grayscale.  In
> other words, since I don't use a final gamma move in the final print process
> since I build it into the RGB curve.  Then my RGB curve is saved for the
> particular ink and paper combination with the file (turn it on and off at
> print time).  Same as a last minute gamma change in the suggested process
> but my RGB curve and gamma change are all done together.

So in the case of using Paul's method, since his separation curves are
designed around EAM, you might not use a custom gamma space when using that
paper/ink combo, but you'd use the custom gamma space as a transfer function
when using different papers? How is it different from a transfer function
BTW?
 
<snip>

> Not sure which standard grayscale space is really the best for most printers
> - or for most monitors, but Blatner and Fraser recommend 2.2 for RGB mode
> for perceptual uniformity in editing and since I am going through RGB space
> I use a gamma 2.2 grayscale working space to edit.

So does Bruce F., BTW.

> ......since there are many paper types
> there will always have to be some way to get the file into a precise printer
> space - even if just to compensate for small dot gain changes and (if you
> use an RGB grayscale file with no profile) the only quick way to do that is
> with a custom RGB space at print time.   The best way to do that is with a
> custom RGB profile and a softproof (which holds true with either grayscale
> printed to CMYK inks or to quad inks) but the original process under
> discussion didn't use one so this RGB gamma tweak at print time was the
> suggested alternative.

Any tips on setting up an RGB softproof for Quad printing that takes Paul
Roark's separation curves into account? I don't know how familiar you are
with his workflow, but it's "complicated" by the fact that he is devoting
the yellow ink purely to distributing, or holding back, cool tone across all
but the darkest 10% or so of the print (that about right Paul?).

I could e- you a set of his curves if you're ever interested in looking at
them.

Todd

--- In DigitalBlackandWhiteThePrint@y..., Dan Culbertson <danculb@b...> wrote:
snip
> I can take a look!  Unfortunately,  so far the only profiling package I've
> tried that will make a good RGB profile for quads is Profiler Pro and a
> spectro.  But Tyler just emailed me telling me he made one with Profiler RGB
> (scanner based) and it worked quite well so there is a cheaper alternative.

I was in a hurry and just doing a quick test. So I used the scanner based option in Profiler Pro, same as Profiler RGB to my 
knowledge. Only problem was the test was with Archival Matte (sometimes I use it for proofing) which nearly glows in the 
dark and sets off geiger counters. So my scanner couldn't read above about 5% on that paper. The spectro would have 
worked much better I'm sure. But I wonder now if the really affordable profilers like WiziWIG or EZcolor would help people 
with quad RGB soft proofing, they may choke on it though. Obviously Profiler RGB would work. Even though it wasn't perfect, 
it helped me build some pretty good RGB curves in about 5 minutes.
Dan's pdf about all this should be uploaded to the files section here. For those who want to work in RGB, and have profiling 
ability, it's very useful.
Tyler

>> Hi Tyler,
>> The only problem is that the only way you can do that is to find
> the 
> gamma
>> of the printer/ink/paper and stay in that space forever.  If you
> change any
>> part of that you have to adjust gamma anyway....
> snip...
> Exactly. That's what I meant. What you are calling the gamma of a
> printer/paper/ink combo is compensated for within the workflow, your
> RGB curves. The grayscale scan, edits, conversion to RGB, and RGB
> separations all take place in the same gamma, 2.2, right?

Yep -- with my workflow there is no need for a gamma change at print time.
That is built into the RGB previewing and separation/editing process.  But
the "Convert to RGB Caution" thread sort of got mixed with another thread
(probably me trying to consolidate advice) which was providing advice on a
different RGB process which doesn't use a profile.  If you have an RGB
profile for the printer you just set that as your proof setup and then when
you send the file to the printer it will print as softproofed (which is true
with both CMYK inks and quadtone inks).  But if you do not have that profile
you need to do some sort of a final tweak.  The customized RGB space trick
was to allow for that since a dot gain adjustment in the print space drop
down would convert the file back to grayscale on the way to the printer
(undoing the RGB adjustment).  Of course once you find the Custom RGB space
that gives the perfect RGB gamma tweak at print time you could, from then
on, use that customized RGB space as your working space minimizing (or
avoiding) any final RGB gamma tweak in the printer space.  May very well be
the way to go now that you mention it.

Dan

> So in the case of using Paul's method, since his separation curves are
> designed around EAM, you might not use a custom gamma space when using that
> paper/ink combo, but you'd use the custom gamma space as a transfer function
> when using different papers? How is it different from a transfer function
> BTW?

What is "EAM?"  The customized RGB Space is just a way to avoid the use of a
grayscale dot area adjustment in the printer space dropdown (which would
convert the RGB file back to grayscale on the way to the printer). IE it is
*very* similar to a CMYK transfer function for a CMYK file or a grayscale
transfer function for a grayscale file.   I've never actually had a need to
use a transfer function in Photoshop with an RGB file but when I bring up
the dialog while in RGB it gives me CMYK channel tweaks (which would imply
to me that it intends to convert the file to CMYK rather than leave it as
RGB?).   At any rate, if you *can* use a transfer function without going all
CMYK in the process then that would be similar to using a custom RGB space
provided you use the "all the same" selection and don't differentially
change the color balance.
> 
> <snip>

> Any tips on setting up an RGB softproof for Quad printing that takes Paul
> Roark's separation curves into account? I don't know how familiar you are
> with his workflow, but it's "complicated" by the fact that he is devoting
> the yellow ink purely to distributing, or holding back, cool tone across all
> but the darkest 10% or so of the print (that about right Paul?).
> 
> I could e- you a set of his curves if you're ever interested in looking at
> them.
> 
> Todd

An RGB softproof simply requires a custom RGB profile.  Works with any
grayscale workflow that passes through RGB.  I haven't used Paul's workflow
but what I've read about it I'd say it would be no different (from the
softproof perspective that is).  By all means please email me the curves so
I can take a look!  Unfortunately,  so far the only profiling package I've
tried that will make a good RGB profile for quads is Profiler Pro and a
spectro.  But Tyler just emailed me telling me he made one with Profiler RGB
(scanner based) and it worked quite well so there is a cheaper alternative.
Tyler also points out you really don't need to set the View / Proof Setup
settings in Photoshop 6 -- if you *assign*  your quadtone RGB profile to
your file, PS 6 automatically uses it to softproof the file.  But never,
never *convert* to an RGB quadtone profile, they are only for seeing, not
converting - or rather try converting to one once and you will never do it
again :-)

Dan

Tyler,

if you or Dan email me the pdf, I will upload it. Thanks for the suggestion.
And take a look at our Files section: it keeps growing to eventually become a 
great resource for BW digital printing (I hope).

Antonis

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

> Dan's pdf about all this should be uploaded to the files section here. For 
those who want to work in RGB, and have profiling 
> ability, it's very useful.
> Tyler