elliotjnewman (signed name?),

The color spaces we all use are based on the ICC system of color management. The ICC specifies that only two color modes are supported by ICC profiles: RGB and CMY(K). (Well, that's not exactly correct - there's also CIEXYZ - a color space used by profile-building software. It's a color mode you'll never encounter in regular digital image editing.) Anyway, the modes we have to work with in a color-managed environment are RGB (3-channel) and CMYK (4-channel), not grayscale (1-channel) or duotone (2-channel).

Printing black and white on inkjet means working in RGB with a very tightly controlled output engine (ex: a print driver like Epson's Advanced B&W, or a RIP like ImagePrint or ColorBurst.) The neutrality of the values are controlled in the output engine in conjunction with a well-built ICC rpofile that describes the behavior of the output device (inkjet printer). The creative tonal editing is done by you in your calibrated/profiled editing environment.

Preparing black and white for CMYK/offset output means working in CMYK with very well-constructed ICC profiles built for a specific output device (offset press). Profiles specific to black and white will be built with a heavier black (ex: GCR Heavy) and less of the color components.

In any case, black and white digital imaging is performed in either RGB or CMYK using the same best practices as you would use for full-color images. The workflow laid out in dpBestflow is valid for both color and black and white.

(BTW, there are a variety of non-color-managed approaches. In inkjet, there are hybrid quad-tone solutions that involve hacking your inkjet printer and replacing the standard set of inks with a set of various gray inks (from light gray to black.) Some folks swear by these systems. However, with the current set of sophisticated tools we have to use that ARE color managed, I'm not sure they are worth the extra cost and effort. In offset printing, you can use multiple hits of black from plates built to address various sections of the tonal spectrum. If you have the money to spend, multiple-black offset printing IS worth the effort. Both of these approaches involve more experimentation because they are not color-managed.)

HTH,

Rick McCleary
author, CMYK 2.0, A Coopertive Workflow for Photographers, Designers, and Printers

Hi Valeria,
You have been approved for the CMYK 2.0 forum. Your account is now active. Feel free to take any further questions regarding CMYK and color management to that forum.
Rick

But, to finish the discussion here:
If the ultimate output for the majority of your images is print, use the ISO 12646 guidelines for monitor calibration (D50).
If the ultimate output for the majority of your images is on-screen, use the ISO 3664 guidelines (D65).
However, in NO case should you be switching back and forth. Select one white point and stick to it. As Peter alluded to, your eyes will adapt to whichever you choose (a phenomenon called chromatic adaptation.)
As an aside, my monitors are all calibrated to D50. My primary output is print - both CMYK and inkjet.

One aspect of this subject that is often overlooked is the lighting conditions under which you view your prints. That is just as important as the calibration of the monitor.
This subject is covered in significant detail in the book CMYK 2.0. I'd be happy to discuss it further.

Thanks,
Rick

Andris -

In a color-managed workflow, there's no need to set your BP/WP at 15/245.  The CMYK profile will place the BP/WP where they should be at the time of conversion.  When working on RGB files, if you want an area to be max black, place it at 0.  Anything else will result in a very "gassy" looking CMYK conversion. 

Regarding gamut and gamut warnings:
Forget about the Gamut Warning overlay in Photoshop; it doesn't give you any valuable information.  If you try to get rid of all out-of-gamut colors by following the Gamut Warning, you'll end up with a very sad looking image.  Use soft-proofing.  You can fix things that are important and ignore things that don't matter (like deep shadows whcih will almost always be out-of-gamut.)  The important stuff is in the mid-to-3/4 tones.

If your client requests an RGB file that you know is destined for CMYK, a good way to make it "dummy-proof" is to convert the RGB to CMYK, then convert it back to RGB and send it off.  No out-of-gamut colors - guaranteed.

I sympathize with you on the communications gap you perceive.  More on that later...

Rick

Nice shot, Dan. 

I don't see much difference between the "before" and the "after" aside from the whites.  Am I missing something?  What areas did you work on with the Vivesa plug-in?

Rick

Sara -

First off, beautiful work.  I like the B/W composite portraits.

re: computer -
I just got a MacPro 2.8 8-core, lots of RAM (8Gb) with Leopard.
Everything is running very smoothly and the thing is really fast.
No regrets here.

re: software -
I only use Photoshop CS3, Bridge, iView.  It all runs flawlessly.
I have no experience w/ Lightroom.  Others here can certainly comment about that.

Rick

I'm testing a new MacPro (Early 2008) running Leopard 10.5.2 w/ the Leopard Graphics Update installed.

The only issue I've seen so far is with iView:
Operationally, iView 3.1.3 runs fine.  However, there's one anomoly:
The thumbnails do not appear to be properly color managed; they are very "hot".  Neons reds, etc.
"Media View" displays correctly in the iView window.
"Convert Image Files..." creates an accurate JPEG properly tagged w/ sRGB which displays correctly in Photoshop.

I'm wondering if this is a Leopard thing, or if there's a setting I've missed.  Anyone?

Thanks,
Rick

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

BTW, all is good so far w/ the basic programs - PS, ID, AI. Acrobat.  However, I haven't gotten into a heavy production environment yet w/ ID and AI.
I've downloaded the updated print drivers for Epson and HP and they're working fine. 
JBOD runs fine.
External FW drives run fine.
Keeping fingers crossed (and keeping the Tiger machines up and running!!)

Peter,
Do you know a way of looking at a drive and determining if the OS9 driver was installed at the time of formatting?  I've looked at the drives with Disk Utility and with Get Info, but there's no indication other than the format [Mac OS Extended (Journaled)].
Rick

I think a tethered shooting discussion would be great. 
And by the way, Andris, don't feel like you need to have all the answers to lead a discussion.  The wonderful thing about a forum like this is the way information on best practices can emerge from the collective wisdom of all the participants.
(Thanks for the reference to the Death to Film blog.)

RIck

Peter,
More investigation reveals the following:
All of the files that don't build proper thumbnails display an empty "Encoding" field in iVIew's Info Panel (under "Media Info".)  This occurs with L*a*b files as well as with the occasional CMYK and RGB file (no channels.)  Curious.
Rick

Peter,
Good idea.
If I post a few to my FTP, would you have time to look at them?
Rick

Hey Peter,

I just ran your test on a few of the CMYK files that are not giving me full-sized thumbnails.  Open file, re-save with a different name (add an "a" to the file name), import into iView.  It gave me 640px thumbnails this time.  But the problem files are already on my archive drives/DVD's.  I think I'll leave them be - I don't want to start pushing data around on the archive drives.  For the future however, I'd like to get to the bottom of this issue and learn what's causing the files not to be rendered by QT.

Thanks,
RIck

In Edit > Thumbnails & Previews, I've set thumbnail size to be 640px/High Quality, Use Built-In Thumbnails is unchecked. 

I've recently been cataloging some derivative files and the thumbnails are not building to 640.  The culprits are L*a*b files and CMYK files.  Is there a way to get large thumbnails from L*a*b nad CMYK files?

Thanks,
RIck

George,

Before you get into a disagreement with a client again, it would be good to clarify for yourself what you charge and the basis for those charges.  Then, in a negotiation (BEFORE any work happens), you can come to an agreement with your client on the various facets of the job and how they will be billed.

Regarding your specific question about post-production charges:
You are currently charging based on time ("$75 - $100 an hour".)  This is confusing to a client.  Change to a per/piece system of charging (like Peter suggested.)  It becomes very easy to explain that the $1/per capture charge directly replaces the old film/processing charge.  At $1/per capture, it's virtually a 1:1 replacement of the film charge.  (I used to charge $35/roll for a 36 exposure roll of slide film.)

Good luck.

Rick

... however, the link to the beta download page is broken.  Ho hum ...

They don't say anything about DNG support other than a brief mention on the RAW format support page under Sony cameras (?)
  "Adobe DNG (preliminary support)"

Capture One 4 beta is released.

http://www.phaseone.com/4/