Digital BW, The Print

> From: wwodets <odets@...>
> Reply-To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Date: Mon, 21 Nov 2005 17:10:38 -0000
> To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Subject: [Digital BW] GG 2.2 vs. DG 20 (Was Comparison: K3 versus Ultrachrome)
> 
> Steve-
> 
> I read your last post and found it both intellligible and correct in
> my understanding and believe it is an understanding that would be
> useful to any kind of workflow.  I wanted to clarify a few points
> that I think got lost in the shuffle.

Thanks

> 
> 1.  The first is that Epson actually does recommend a DG20 gray
> space.  In a document from their U.S. website called "Epson Color-
> Managed Workflow: Getting the Color you Expect in Your Prints," the
> first page recommends (and shows a screen shot) of the color settings
> dialogue.  The setting is U.S. Prepress Defaults, which is an RGB
> space of Adobe RGB (1998) and a gray space of Dot Gain 20%.  The
> document implies that it is for "color" workflow and based on "The
> Epson Stylus Photo 2200 printer . . . but the workflow is similar for
> other printers." 

>When I questioned this with an Epson tech rep (back
> in April), he confirmed that the expected working gray space on thwe
> 2400 was indeed DG 20.

This last part would surprise me greatly.  With the first part above the
focus is on the colour workspace, Adobe RGB.  Adv B&W's default settings
produce very good results on Epson papers when combined with a GG2.2
workspace - out-of-the-box and without the assistance of a QTR ICC profile.
All the beta tester discussion was, I believe, related to Adobe RGB/GG2.2.
Remember the Jeff Schewe article and his interview with Greg Gorman.  They
were all talking about printing from Adobe RGB (and thus by reference GG 2.2
the greyscale subset of Adobe RGB).   The fact that the default settings do
not produce reasonable results with DG20, as opposed to GG2.2, would alone
suggest that one is better off using GG2.2.

http://photoshopnews.com/2005/05/16/epson-r2400-and-ultrachrome-k3-ink-repor
t/

Maybe they didn't attempt to hardwire the printer response to a particular
workspace which would be a pity given they did not provide the colour
management missing link.  As noted before, the suggestion that they did was
just speculation.  At any rate, I prefer not to guess and would rather
separate my workspace choice from the equation by deploying colour
management to act as a translator.  I can profile the output of the printer
with QTR Create ICC and then use colour management to do the translation.

As soon as you don't have colour management to help, the choice of workspace
will greatly influence the results.  BO was never intended to print
photographs but Clayton found by experimentation that the DG20 space gave
the best first-cut output (for reasons I demonstrated quite some time ago).
You should not be surprised that an editing space that worked well for one
workflow/driver does not work well for a new workflow when you don't have a
translator sitting in the middle. You can either dig around to find a
workspace that works better than others or use colour management and divorce
yourself from this issue.

> 
> 2.  In a post to Clayton earlier on in the fray, I mentioned that I
> used the Gamma 2.2 workspace but the "light" setting in the driver
> because I got better ICC profiles.  (By using the light setting one
> is doing nothing more than changing the color space of the printer in
> an easy, reliable, repeatable, consistent way).  The reason for my
> doing this is that the *unmanaged* targets printed for ICC profiles
> reflect exactly the compression we'd expect of GG 2.2.  In the
> shadows, the closeness of the patches is more difficult for the
> spectro to discriminate.  In some recent tests with Paul (in which we
> measured our own targets five times and then each others, each with a
> different instrument and in my case in both patch and strip mode)
> variations on the order of L* 0.5 were quite common, and I showed one
> as high as L* 0.88.  Thus the target from the light setting makes
> these errors much less significant and provides more reliable data as
> a basis for the ICC profile generation.  Having better resolution of
> the data at this level and then recompressing the 85-100 K for visual
> correctness is, I think, more reliable.  So, the issue is not that
> the target doesn't "look right," it is that the "darker" target is
> more difficult to reliably read.  Incidentally, we both found that
> the variations from the printer (target to target, printed
> consecutively) were greater on my 4800 and Paul's 180 (?) than were
> the variations in spectro reads.

An important difference here is you are using colour management.  You are
using a setting that makes profiling the printer easier.  You are not using
that different setting to change the look of the output in any way.  The
profile just profiles the revised stimulus-response behaviour.  I have no
problems generating profiles from 101 patches with the 4800 at default
settings.  Also, if I recall correctly, your problems were with third party
papers.  We can't expect Epson to calibrate their printers to work well with
every paper under the sun.

> 
> All of that said, the magic of the QTR Create ICC has recently made
> itself known to me again.  I have several photographs I am having to
> reprint.  These were originally printed with a DG20 workspace to the
> 2400 using a workflow similar to Clayton's current one.  In
> reprinting them now to the 4800, I am simply converting to the GG 2.2
> profile and printing through the ICC printer profile.

You could have just printed from DG20 (or whatever the files are tagged as)
with conversion to the output ICC profile (ie omitted the conversion to
GG2.2).  Because you are using colour management the interim step was
unnecessary.  If you weren't using the output profile then the space the
files were in would matter.


None of this stuff is perfect.  The tonal management embedded in a QTR
Create ICC profile may not do things the way you want it to for every file.
After all you are buying into the one algorithm Roy embedded in the program.
But you can soft proof it and it's a damn good start.

A key point to understand along the way is that printers and computers only
know numbers and the colour attached to a number changes with the colour
space that gives it meaning.  The corollary to this is that the viewed
difference between two greyscale numbers - their separation - also depends
on the colour space in which those numbers are being interpreted.  The
separation between 90% K and 95% K is greater in DG20 than it is in GG2.2.
It's meant to be. And convert a document from one space to another and,
without colour management in the printing leg, you send the printer an
entirely different set of numbers.