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

> From: Tyler Boley <tyler@...>

> 
> --- In DigitalBlackandWhiteThePrint@yahoogroups.com, Steve Kale
> <stevekale@b...> 
> wrote:
>> 
>> Agreed.  Since I have been a participant on this forum, the question of
>> "what should we really be linearizing to" has been one of the deeper
>> recurring questions.  I think the fall-back to linearizing L* hasn't really
>> been that understood.
> 
> I don't think this issue has quite the import you give it. Linearizing to L is
> done with QTR, 
> sounds like Paul may be doing it,

Paul targets his own luminance scale (linear or not).

>but it's hardly a standard. StudioPrint lets
> you linearize 
> to contunuously variable and selectable dot gain percentage, I don't recall
> what Colorburst 
> linearizes to. Every RIP (there are many) or calabratable driver may have it's
> own standard.

OK.  I had simply observed that whenever this conversation cropped up on
this forum people seemed to settle back on a linear L*.  In September of
last year I began questioning the sensibility of this.
> 
>> The net-net of what we have learnt on this exercise
>> is that, for a given workspace, one is likely best to target a
>> "linearization" that generates a luminance curve that reflects bpc and wtpt
>> scaling - rather than a straight (linear) line.
> 
> If you mean it porportionally compensates for paper white and ink black, I'm
> sure that's 
> right. It is from my experience.


>But BPC is a different math entirely from what I understand.

Not really.  I am sure Roy could comment more accurately on the specifics of
Adobe's bpc maths - as we understand it - but it is comparable to wtpt
scaling.  There is no ink black compensation in the ICC spec.  Adobe's bpc
feature (and presumably those of other similar applications) fill a gap in
the spec.  

>We had this conversation long ago.



> 
> Regarding the rest, linearization and color management are two different
> functions. In 
> fact, if good color management practice is used throughout, it could be agued
> that the 
> results would be the same no matter what standard was chosen for
> linearization, within
> reason of course.

Yes linearization is simply a calibration feature that makes a device such
as a printer perform in a more predictable fashion.  This makes colour
management easier because colour management necessarily involves
interpolation between samples because to record the complete set of
stimulus-response behaviour is impracticable.  But if you stop at
linearization and don't employ a mechanism for managing differences in tonal
response then problems arise.  Your _printer device_ may still behave
predictably but workflow results will vary to the extent that different,
say, different work spaces are used.  And for any given workspace the result
may not be sensible in that it's not visually pleasing.  For at least the
last three years this is where the B&W community largely stopped (with a few
notable ICC colour managed approaches).  What's more, those that maintained
a policy of linearising L* provided no attempt to rationalise the tonal
mapping from even just one workspace to that of the printer.  I am glad we
now have available to us an affordable solution systematically and sensibly
managing differences in tonal range.  We are finally making use of what's
been known to the colour community for quite some time.

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.