Black Point compensation

[Schewe]

Yes...since in LR you can't turn it off anyways...

[MHMG]

BPC should always be on. IF it isn't needed, nothing happens. If it's needed, something good happens (the black compensation is applied). Now if you have a profile that doesn't need this, having it off will be OK, but having it on and sticky makes more sense.

Andrew, I'm not sure you are correct about BPC never does any harm. It seems at least in PS's implementation of BPC, the compensation is being applied by checking the chosen ICC printer profile for what maximum black is reproducible and then scaling the image tone curve from that value whether the image contains those dark values or not. That's not the same as evaluating the image content to see if the actual image has any shadow or black values that would require some compensation to stay within the chosen printer/ink/media color gamut.  In other words BPC behaves like a variant of an ICC profile Look up table rather than a variant of a "smart" CMM.

Try this softproofing test. Use a profile like HnPHoto Rag for your printer. It will be able to reproduce gray values down to about L* = 18 without any need for BPC.  Now create a gray ramp that stops above that value, say sRGB =50,50,50 which renders L*=21. Since all is in gamut within this image, BPC should do nothing. Yet, on my screen it lifts (i.e., compensates the gray scale) as if full RBG 000 black is also present. Hence, dumb CMM not "smart CMM".

Where turning off BPC becomes useful then is in the occasional high key/lower contrast image or painting reproduction where all is within gamut for the paper without requiring any further compensation to bring colors and/or tones into gamut.  In those instances, RelCol without BPC will a better choice whereas Perceptual and Relcol w/BPC will attempt to lower the image contrast somewhat further to make headroom for additional deep colors and tones that aren't even in that image. Again, it's a "dumb" CMM versus "smart" CMM issue, and until modern color management gives us a truly smart CMM, having both BPC and no BPC available extends our rendering choices (i.e., perceptual, relcol, relcol w/BPC, and abscol) in a useful way.

Where I agree that BPC does nothing in PS is when checked on along with use of perceptual rendering. In that instance, the vendors' perceptual tag secret sauce has already accounted for the necessary black compensation so BPC does nothing.

[MHMG]

Barbara, I'm not sure how well this issue got covered for you, so I'll give it a go.  Because ACE isn't an available 64-bit CMM option with the iPF8300 plugin, the simplest and safe workaround when wanting to use ACE and its BPC feature with the 8300 plugin is to duplicate your image in PS and then use PS's "convert to profile" menu. Making the conversion in PS gives you the all the ACE rendering intent options including BPC. Then export the converted file to the 8300 plugin and make sure that in the plugin you've got "color management off" selected on the main page of the plugin. I use a duplicate because the layers get flattened during conversion. If I decide to make further image edits, then I throw the duplicate out, rinse and repeat This workflow is much faster than trying to step out of PS 64 bit mode to open PS running in 32 bit mode.

cheers,
Mark

[digitaldog]

Andrew, I'm not sure you are correct about BPC never does any harm.

I've yet to see when toggling on and off, it isn't better looking with BPC (in cases where the toggling affects the image).

[BarbaraArmstrong]

Mark, yes, I have been following the explanations.  Suppose I just print out of Photoshop, using Relative Colorimetric and Black Point Compensation, and forgo the "stickiness" of the settings in the plug-in?  Doesn't that solve it? (when I want that combination) --Barbara

[MHMG]

Mark, yes, I have been following the explanations.  Suppose I just print out of Photoshop, using Relative Colorimetric and Black Point Compensation, and forgo the "stickiness" of the settings in the plug-in?  Doesn't that solve it? (when I want that combination) --Barbara

Since CS5 and now CS6, I"ve have not had good luck printing from PS and also find the menus and submenus confusing (and not sticky as noted by others), but YMMV. However, I'm on a Mac, and that may contribute. The 8300 plugin is pretty much foolproof, and also when I use "convert to profile" in PS and no color management in the plugin, I never worry about double profiling or losing setting values. That said, printing from PS should allow you to invoke Canon's "free layout" feature which is really fantastic when printing multiple images or copies to roll rather than cut sheet because it's turns your printing pipeline into a full blown RIP with nesting capabilities. For many printing jobs this nesting capability trumps the convenience of the plugin. I wish Canon would also have put the free layout capability into the plugin but whatever. So, when I want to print to roll, I use Indesign and check the free layout box in the driver to get the full nesting capability. And Indesign is very robust on it's print dialog menu and settings are sticky plus it has always played nicely with the Mac regarding color management, whereas other Adobe programs like Acrobat, LR, and PS seem to be OS challenged in Mac 10.7 and 10.8.  I"m not sure those OS conflicts have ever been fully resolved, but again, the plugin and Indesign just work right all the time on my Mac.

[BarbaraArmstrong]

My next post could be veering a little bit OT, but all this stuff is so inter-related!  I'm starting with images in ProPhotoRGB, editing in ACR and Photoshop on a Windows7 computer, then printing to a Canon iPF 8300.  If I print from Photoshop, is my file being printed as an 8-bit file, while if I printed from the Canon plug-in, it would be read as a 16-bit file?  (I became confused on this point, especially after reading Jeff Schewe's post.)  My first (earlier) question was posed thinking black point compensation was the deciding factor in deciding which software to print from.  Now I am wondering if the bit-depth of the file at the printer end of the process is also a factor.  I do think I've comprehended the discussion to this point; but this aspect remains unclear to me.  At first, I thought what I was giving up by printing from Photoshop was only the stickiness of the settings in the Canon plug-in.  Now I am wondering if, to keep the file 16-bit to the very end, I need to print from the plug-in.  And then, of course, there is the question of whether keeping it 16-bit makes any/much difference in a final print.  I am enlarging images to print at 20 or 30-inch shorter dimensions, and imagine that an enlarged image might be more prone to posterization in the printing process (but maybe I am wrong about that).  Would you all be so kind as to weigh in to clarify this?  --Barbara    P.S.  I actually enjoy the complexity of each of the aspects of digital photography and printing and enjoy understanding what I am doing.  If it were easy, anyone could do it!

[JeffKohn]

If I print from Photoshop, is my file being printed as an 8-bit file, while if I printed from the Canon plug-in, it would be read as a 16-bit file?

Correct. The standard printing pipeline in Windows supports an 8-bit data path, which is what you get printing through the Photoshop dialog to the regular print driver for the iPF.

The iPF print plugin bypasses the Windows print pipeline and supports 16-bit data path to the printer. Some will tell you it makes no difference; for many images that's probably true. But the 16-bit option will never make things worse, and for some images it can be an improvement; so I'd rather just stick with it and know I'm always getting the best possible output from my printer.

Plus, as Mark mentioned the options in the iPF plug-in are pretty straightforward/consistent and don't change with every Photoshop release so I'd rather stick with what I know.

[tho_mas]

ACE=Adobe Color Engine
CMM= Color Matching Method

CMM= Color Matching Module (at least in the context of color conversion "engines") 

[BarbaraArmstrong]

Jeff, thanks again!  Your answers have been really helpful.  Now I need to start practicing the new "workflow" until it feels  automatic!  --Barbara