Yahoo Groups archive

Digital BW, The Print

Index last updated: 2026-04-28 22:56 UTC

Message

Re: [Digital BW] ICC v. Transfer Function in Epson driver

2005-10-18 by Steve Kale

Paul et al

I thought it might be useful to talk about some of the pluses and minuses
(in relation to this discussion) of transfer curves vs custom dot gain ICC
profiles vs PS curves vs QTR Create ICC profiles.  When Roy first delved
into this following a long discussion we had where I was saying that
linearising to L* was not enough I immediately saw the potential of the
approach. Having made two "generic" ICC profiles, Roy then put it off to one
side for a while.  I wanted to take it further and be able to create ICC
profiles from actual rather than hypothetical data (as the generics did).  I
don't have Roy's programming skills so I was looking for another method of
creating them.  I had a bunch of conversations with Phil Green - yes the
"ask Phil" guy you see on www.color.org.  He kept saying "I don't see why
you don't just use a PS curve to put the right transform in place".  Bruce
Fraser alerted me to the fact that PS can generate an ICC profile from a
custom dot gain.  So I've been around the various options here but only as
my understanding of the topic was growing. Thankfully Roy became interested
in the subject again and really produced a great product.

"Custom Dot Gain ICC Profile Generation"

A very cool part of PS is that it can create a simple greyscale ICC profile
from Custom Dot Gain information.  This profile can (and is intended to)
then be used for printing.

I struggled with this initially because I thought I needed to be able to
move the end points in order to reflect paper white and ink black.  Later I
understood that the inputs into an ICC profile are media relative and so I
didn't need to be able to move the white point.  But you do still need to
get the white point info into the profile.  The inability to move the black
point (bottom left) is a problem. In order to do a soft proof of ink black
properly you can't give PS a profile that indicates that the printer can
achieve perfect black.  Checking Simulate Ink Black will merely leave the
deep blacks at monitor black and you miss one of the key points of soft
proofing B&W.  So that's a big negative for using the Custom Dot Gain
approach.

Of course the other issue is you still need to know the stimulus-response
behaviour of the printer (ie to be able to measure the luminance of your
step wedge) and then do the scaling calculations for media relativity
(adjusting for white point) and also BPC (because the inability to shift the
black point forces you to "embed" BPC).

The last issue is of course the limited number of observations that a Custom
Dot Gain can accommodate.

"PS Curves"

PS Curves are useful in two ways.  You can create a curve to use as a soft
proof of the printer behaviour (eg reduced black and dull white).  You can
also create a curve to modify the luminance of the file data so that it is
scaled for paper white (media relativity) and ink black (BPC).  But the two
curves are very different and you don't want the soft proof curve to still
be there when you send the file to print.  Also you don't want the scaling
curve to be left in the file because it is only relevant for a particular
media/printer setup. It's all a bit messy. Furthermore, you still need to be
able to do all the measuring and scaling calculations to get the curve(s)
right.  So the complexity of the task has not changed except for the fact
that once you have the calculations done you do have a mechanism for putting
them into effect - better than nothing.

"Transfer Curves"

A transfer curve is simply the second of the two curves I mentioned above.
It has the one great advantage of not being embedded in the file.  It is a
print only curve.  But you can't soft proof with a transfer curve.  In order
to soft proof even just luminance, you need to create a soft proof curve as
mentioned above.  So net-net Transfer Curves don't get you much further than
PS curves.

"ICC Profiles"

The cool thing about ICC output profiles is that they don't need to
"embedded" in the file by a conversion (ie a change of data info).  They can
be invoked only at printing (an on-the-fly conversion) and soft proofing.
Done properly they can provide a soft proof for ink black (ie no embedded
BPC).  [I looked at Colorshop X's Greyscalebuilder utility but it is clumsy
and can't be used to automate the input of actual data.  (It did, however,
greatly help in my understanding of media relativity - at first I couldn't
understand why when I changed the media white point the curve did fall from
the top right corner!)]

I thought the programming of an ICC builder that read actual
stimulus-response behaviour into a kTRC (grey tonal response curve) to be
daunting enough.  But having got this under control Roy quickly turned his
attention to the alternative method of using A2B0/B2A0 lookup tables.  When
Roy mentioned to me that he was getting to grips with how these tables
worked I said that would be awesome because he could record colour
information for the soft proof direction and still leave the printer
direction managing luminance only.  What we have now is a first draft of
exactly that and is an awesome achievement.

(One has to remember that it is very difficult to ask colour engineers
questions about this stuff.  They think and breathe colour and getting them
to help in the constrained B&W world can be difficult.  There is also a lot
of info at the ICC site but it's a lot of "this is" and not a lot of
"because of this" - ie a lot of factual stuff but little "why".  Roy has
done a tremendous job filtering through all this stuff for our benefit.)

Linearising vs Profiling

In theory a more linear printer means profiling is easier.  This is because
it is impractical for the profile to have every possible observation in it
(although it is much more practical for greyscale than colour) and so it
needs to interpolate between observations.  Linearity makes interpolation
easy.  But get enough observations in the sample and linearity becomes, I
think, less important.  I suspect, although I am not knowledgeable enough on
this stuff to be definitive, that for B&W so long as the printer has a
semblance of linearity then 51 observations is more than enough for sensible
output and linearising the printer becomes less relevant.  (I think the
whole Epson Colorbase trip we all went on a couple of weeks back was a wild
goose chase.)  My bet is that 51 observations would be enough to manage even
the crude Black Only luminance scale for example.  Only testing will tell.
Remember 51 observations (even 21) is a huge number of observations for a
single axis - imagine doing that number for each combination of 3 axes R, G
and B.

Now to practicalities.

One can pay the QTR shareware fee and use QTR Create ICC even if you don't
have an expensive spectrophotometer.  You can simply plug the hue data
(Lab's a* and b*) with zeros.  You will need a densitometer that either
outputs L* or XYZ_Y and then you can convert that to L* - ie you need to be
able to measure luminance.  But in the grand scheme of things these are
relatively cheap.  You will not be able to soft proof the hue of your output
but I think this is a secondary concern.  What I like about the QTR Create
ICC profiles the most is that my print workflow is now really very
automated.  I know that the profile will scale the image luminance properly
for my print media and simply need to focus on getting the image looking
right on screen.  The first soft proof really is the print "at size".

Even if one has to spot read the 21 or 51 patches this isn't so bad.
Getting the data into the right format is easy once you understand what
formats are allowed.  A simple text editor can do this.

Of course if you do have a spectrophotometer - and it doesn't have to be an
EyeOne - then you can include the a* and b* information and get a soft proof
of hue as well as luminance.

I hope this helps.

Steve

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.