Digital BW, The Print

> From: Roy Harrington <roy@...>
> Reply-To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Date: Wed, 26 Oct 2005 21:32:18 -0000
> To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Subject: Re: [Digital BW] ICC Soft Proofing -- The issue . . .
> 
> --- In DigitalBlackandWhiteThePrint@yahoogroups.com, Steve Kale
> <stevekale@b...> 
> wrote:
>> 
>> Hi Roy
>> 
>> You know this stuff much better than I do but as I understand it there are 4
>> parts to any A2B0 (or other like tag):
>> 
>> 1. The identity matrix - a given for Lab PCS
>> 2. The 1D input table (curve)
>> 3. The multidimensional CLUT
>> 4. The 1D output table (curve)
>> 
>> You've used 4. to generate the transform rather than 3. If PS normally goes
>> looking into the CLUT for bpc generation etc then what will it find?
>> Colorsync portrays the CLUT contents as perfect lab.
>> 
>> Thinking about it a little more, I guess PS would most likely pass data
>> through the entire transform 1-4 but I am just speculating.  If that's the
>> case, for a single channel situation it doesn't matter where in 2-4 the info
>> is kept.  
> 
> Yes, this is the idea.  With multidimensional input and output there's a lot
> of
> space saving by having multiple steps.  The CLUT is the one that takes up all
> the room.  Typically 25 points are used giving a 3in-3out size of 25*25*25*3*2
> bytes.  With only 25 points per dimension, linear interpolation is done for
> all
> the midpoints.  


I didn't realise there was a limit on the number of observations.

>The InCurves and OutCurves can afford all 256 values and these
> make the linear interpolation in the CLUT as accurate as possible.
> 
> So bottom line is the whole tag can be thought of as one transfer function
> that
> is usually n-inputs to m-outputs but if our case only one input is used.
> The B2A0 goes from the file's L* value to the QTR driver's K value.  The A2B0
> goes from a QTR driver K value to the L,a,b values of the soft proof.
> Using just the OutCurves fits the needs the best.  All the other pieces are
> identity
> functions (pass the data through unmodified).
> 
> 
>> But I am puzzled though by a comment you made some time ago
>> (probably offline) that PS bpc did not work with the new profiles and so you
>> had to build it in.  It suggests PS is not finding the data it needs.  (Of
>> course it all works in the end because you have done the bpc for PS.)
> 
> The difference is that in the TRC method there's only one curve which is setup
> most like a A2B0 curve.  The CMS takes the one curve and calculates the two
> directions so both directions come from the same data.  BPC could be used to
> fix a curve that didn't go through (0,0).

Yes.

> 
> With the A2B and B2A tags you specify exactly you want to happen in each
> direction.  In B2A0 L=0 must naturally map to dMax or K=100.  In fact you
> have to map all the L's into reasonable K's and this is the BPC-like scaling.

> My comment in the past about "doing the BPC myself" was for the B2A0 tag.

Yes I knew it was in relation to B2A0.   If this is the case, it makes me
wonder why there is a BPC in the print pane.  If all profiles map from file
pixel value 0 to dMax with black point scaling then there would be no need
for it.

> In the A2B0 K=100 maps into say L=16, and if you have Ink Black on it displays
> as L=16 but the default for softproofs is for PS to do BPC and map it to L=0.
> So PS is actually doing the BPC for the proof.

The PC guys have one advantage over the Mac guys re looking at profiles.
ICC Profile Inspector seems to allow people to look directly at the 16 bit
values stored in the CLUT.  I would love to look into the B2A0/1 CLUTs for a
GM i1 generated profile as a means of comparison...