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-20 by Steve Kale

For what it's worth, here are the areas I would like to understand a bit
more on this stuff.  Some of these things hark back to core subjects like to
what should we linearise etc.  I feel like I am quite close to getting to a
level of understanding I would be happy with but I haven't closed the last
few loops.  Any help appreciated.

1.  I'd like to understand better the relationship between L* and XYZ_Y.  I
have trouble thinking in cubed roots!  I thought for a minute that XYZ_Y
followed the shape of the human perceived luminance curve but a couple of
sample observations show that's not the case.  I'm sure that with a little
thought I'll get there.

2.  I'd like to better understand the actual implementation of the BPC and
white point scaling, ie understand specifically rather than generically how
it is implemented.  We start with, at least with a RIP, printer greyscale
that is linear with respect to L* - how does the scaling actually affect the
shape of this? Both in terms of L* and XYZ_Y. I hope I can take this up with
Roy.

3.  I'd like to understand why linearisation is best done with respect to L*
and not XYZ_Y which is where the scaling is done.  This obviously requires
the first item to be understood.  I would guess it has something to do with
the linearity of L* as a concept and ease of interpolation but then on that
I am just guessing.

While Roy and Carl spotted the issue with Paul's tests, Paul will still find
that there is greyscale compression (as measured by L*) in the final result.
Remember that when we have the opportunity to do so, we linearise the L*
output of the printer prior to slotting in an ICC profile (which has BPC and
wtpt scaling).  The raw linearised L* output has good L* separation but is
flat and lifeless and we can readily see why from a quick sketch - the gamma
or contrast of the output is significantly less than "ideal".  If we are
going to restore this contrast into something visually appealing then
something's got to give so think either a handmade contrast s-curve or a
luminance-calculated ICC profile.  We readily recognise that the former
compresses luminance change at either end in order to restore contrast
through the important mid-tones.  Exactly what happens with an ICC profile
requires an understanding of my second point above.

One final comment:  what we are talking about here is gamut compression (and
as a result how contrast is affected):  how to compress a range from perfect
black to perfect white in the image file onto a piece of paper that is
certainly imperfect at both ends and more often than not a lot worse at the
black end than the white end.  In B&W the problem is simplified to a
discussion of black point and white point.  We don't have to worry about
other out-of-gamut colours because if we tackle these two then all else
falls into line even with intentionally non-neutral prints.  The points
Bruce Fraser (Real World Color Management pg 74) makes are very important:

"Color management systems use various gamut mapping strategies that let us
reconcile the differing gamuts of our capture, display and output devices,
but it's important to recognize that not only is there no "correct" way to
handle out-of-gamut colors, it's also pretty unlikely that any gamut-mapping
strategy, or any automatic method of compressing tone and color, will do
justice to all images.  So color management doesn't remove the need for
color correction, or the need for skilled humans to make the necessary
decisions about color reproduction.  As we've said before, perception of
color is uniquely human, and its judgement is decidedly human as well.  What
color management does do is to let us view color accurately and communicate
it unambiguously, so that we have a sound basis on which to make these
judgements."

We have rejected the full implementation of colour management because of
colour shifts and "metamerism" (a slightly misused term) - if it worked we'd
all be happily printing just like the colour guys.  What Roy has achieved
for us, and it is still a work in progress, is to allow us to take the
component of colour management most important to us - the achromatic
component (brightness) - and use it while leaving the the chromatic
components (hue and saturation) alone.  We manage the latter when we pick
the inks that make up our greyscale and choose our paper - we do not attempt
to have colour management help us with these.  So we have the core of a
technique that is very very broadly deployed in the colour world at our
disposal.  But that still does not obviate the need for human judgement as
to the effectiveness of its implementation.  In "auto mode" it does work
very well but there will of course be situations when it needs a tweak, most
likely with a PS curve.  The good thing is that if colour management is
deployed effectively throughout your workflow then you can preview the
effect of colour management with _reasonable_ confidence, make your own
judgements as to its case-by-case applicability and make corrections if you
deem necessary.

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.