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

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.  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.  We always knew that in any
Same as Source workflow the workspace or document space influenced results.
I don't believe people tried different workspaces for any other reason than
to try to influence the output. (GG 2.2 and all the others each have all the
colours we need.)  Given the understanding generated from the whole QTR
Create ICC path, I think we have found new insight into the "ideal" B&W
linearization, looked at from an end result.  Personally, I wonder if Epson,
Cone et al have been deploying this knowledge also.

The ICC approach is of course more flexible because it can handle any
document space (not a biggie in that if one had to only use one there is
little disadvantage) and it provides built in soft proofing.  The latter is
the key advantage over the "smart linearization" approach.  It does,
however, introduce another step in the workflow and another hurdle for
understanding.  Personally, I think it's all very, very worth it.

Steve


> From: Roy Harrington <roy@...>
> Reply-To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Date: Sun, 23 Oct 2005 06:56:11 -0000
> To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Subject: Re: [Digital BW] ICC v. Transfer Function in Epson driver
> 
> 
> You could do the all-in-one "smart linearization".  Like you said it would be
> possible to match a specific assumed embedded profile -- but of course it's
> only good for only one input profile space.  To use other workspaces you'd be
> putting say GG 2.2 as your print space, so it boils down to the same situation
> -- a print profile and QTR settings including the QTR profile.
> 
> The QTR linearization method isn't an absolute.  It could just as easily have
> been
> something else.  
> 
> Roy
> 
> 
> --- In DigitalBlackandWhiteThePrint@yahoogroups.com, Steve Kale
> <stevekale@b...> 
> wrote:
>> 
>> BTW.....
>> 
>> Recalling my question of the 20th:
>> 
>> "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."
>> 
>> 
>> .... there ought to be no reason why one couldn't incorporate into a RIP a
>> "smart linearisation" (for want of a better term) which incorporated a
>> transform from the unlinearised data to linear data and a transform to bpc
>> and white point scaled output - all in one hit.  We are just doing this in
>> two steps with the advantage that we gain a soft proofing tool and, very
>> importantly, separation from a defined workspace.  (These are not
>> insignificant advantages.)
>> 
>> The scaled output is a curve but an ICC profile still has to interpolate
>> such a curve as would the RIP.  I would be interested if there is any
>> difference in the maths at the end of the day - I suspect not.  I have no
>> idea how it would complicate the mixing of two curves though.
>> 
>> The ICC approach is dramatically more flexible but a RIP designer without
>> these skills could reprogram their linearisation function for a defined
>> workspace and achieve most of the same result.

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.