Digital BW, The Print

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.
> 
> 
> 
> 
> 
> 
> 
> > From: Steve Kale <stevekale@b...>
> > Reply-To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> > Date: Sat, 22 Oct 2005 03:20:14 +0100
> > To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> > Conversation: [Digital BW] ICC v. Transfer Function in Epson driver
> > Subject: Re: [Digital BW] ICC v. Transfer Function in Epson driver
> > 
> > I believe that the graph in the document "Linear vs ICC L* Output" is a much
> > more accurate depiction of the effect of QTR ICC colour management of my QTR
> > HPR greyscale curves.
> > 
> > http://homepage.mac.com/stevekale/stevekale2/FileSharing37.html
> > 
> > Please correct me if I am wrong!  I read the L* in the Lab info palette for
> > each patch given my GG2.2 workspace and plotted this expected number vs the
> > actual output of the print.
> > 
> > 
> >> From: Steve Kale <stevekale@b...>
> >> Reply-To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> >> Date: Sat, 22 Oct 2005 02:50:52 +0100
> >> To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> >> Conversation: [Digital BW] ICC v. Transfer Function in Epson driver
> >> Subject: Re: [Digital BW] ICC v. Transfer Function in Epson driver
> >> 
> >> I agree though that for each colour managed line I should have plotted the
> >> L* expected by the colour patch given my workspace against the actual
> >> achieved, rather than the "step vs the L*" - I agree the step is no longer
> >> valid - and compared this against the linear line of the non colour-managed
> >> output.
>