Digital BW, The Print

Olivier

No problem.  I have not joined the QTR group yet (in general I am against
fragmentation of this list - it is powerful due to its breadth).  I am not
so far in front of you on this stuff so sorry if I am not definitive at
times.


> From: odesmais <odesmais@...>
> Reply-To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Date: Mon, 08 Aug 2005 11:51:39 -0000
> To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Subject: Re: [Digital BW] QTR ICC still in the dark...
> 
> Steve,
> 
> First I need to apologize : I have double posted the below in here and
> QTR group which is not very ethical... In fact I just realised as you
> below mentionned that Roy would be of help in this.
> 
> I did look at the kTRC explanation and also the color.org explanation
> of BPC, apparently this is an issue the organisation is wanting to
> tackle, I don't know if this is being implemented in v4 or not, but by
> experince not all soft (profilers, don't know about editing
> softs) "understand" v4. There's also a lack of standardised perceptual
> intents (seems all profilers implement a proprietary algorithm) which
> is also something they are looking at, and to make it even more
> confusing there's now a debate about CIE Lab as a PCS (it does not see
> the same for XYZ)due to hue shifting thus non-uniformity... Also this
> is simply and unfortunately coming from booking reading and web
> browsing : I try to know but seldomly understand.
> 
> Anyway, in fact what happens is that since my PS color settings is
> (default, I never bothered to set it properly)grey : dot 15% I work
> with too "light" a working space and since the stepwedge is not tagged
> PS assumes the dot 15% as a source space thus printing light after
> converting.

I use Gray Gamma 2.2 but this should not make a difference as the raw pixel
values are sent.  What you are measuring with the ICC profile is simply the
response behaviour associated with a particular pixel value.  When you do
the conversion to the ICC profile created by QTR Create ICC then the pixel
values are altered so that the shades of grey produced are the same in the
new space.  (I am sure you know this!!)

> 
> I'd like to measure the actual output of the QTR-ICC profiling but I
> feel it's a lost search. When printing the raw stepwedge in QTR, datas
> are fed irrespective of color space, so the raw L* value are dependent
> on printer-ink-paper and does not reflect...anything else than the
> linearised stepwedge printed on ONE printer with ONE ink set and ONE
> paper.  May be there's a way to translate the linear L* measurements
> into a gamma and set it as a grey working space to perform the
> conversion with the QTR ICC profile to evaluate, but I don't know it. I
> asked Roy if 1.8 would make sense. If not I leave it here since anyway
> it will not improve the workflow. I'll set color settings grey : gamma
> 2.2 (RVB and the windows environment) to minimize conversions and that
> will do.

In a Same as Source workflow your workspace makes a difference.  A
particular (visual) shade of grey has a particular (and different) pixel
value associated with it in each space.  So the same grey sends a different
number to the printer from different spaces.  This is why Black Only users,
for example, have fiddled with or tried various workspaces to improve their
print to screen match.  (QTR Grey Lab was an attempt to more closely align
working and print spaces for QTR users when it was a Same as Source
workflow.)  I use GG 2.2 simply because it is closer to the gamma embedded
in ProPhoto RGB or Adobe RGB and hence perhaps eases the space mapping when
doing conversions in and out of colour spaces (eg at initial B&W conversion
or when sharpening with Photokit Sharpener).

But one of the advantages of moving to a "colour" managed workflow (ok QTR
ICC profiles aren't colour profiles but you get my point) is that your
workspace no longer matters.  Because you have profiled the luminance that
the printer produces when receiving pixel value x you can simply do a
conversion to this space before printing so that the right file values are
sent.


> 
> BPC remains a mystery : I use to do the soft-proofing with
> perceptual+BPC+white paper (which also turns on Blakc ink).


I don't think it is toooo much of a mystery.  Scale values in XYZ_Y to
adjust for the weaker black ie make the range black point relative.

>However it 
> might be that you need/can soft proof not turning BPC but Black ink
> simulation (which is done when white paper is checked)... to be
> followed since it's only my understanding.

I think because Roy has done the BPC in the profile it throws Adobe PS out
of whack when it comes to soft proofing.  It sees perfect black and so
Simulate Ink Black etc is greyed out.


> 
> I'm sure I'm tiring many people with some lack of competence/knowledge
> and not-so-important issues... So, thanks Steve for your great
> willingness to help, I do appreciate a lot.
> 

Never give up trying to understand!! (especially if it is not working for
you)  I am puzzled by the results you posted and can't help but think the
answer is very simple....I would start by doing a methodical check of each
step:  is the Linearize function in the QTR ink descriptor file, is this the
same ink curve you are using, are you doing the conversion in PS and then
using QTR the same as before etc etc.

Steve