Digital BW, The Print

Except that I am talking about the mechanism which does the "profile
conversion".  This had to be formulated and then programmed.  You are
assuming this as a given - that it is both sound in terms of the principles
it attempts to apply and that it applies them properly.  I agree a good
profile made with an application which deploys good "profile conversion"
algorithms can correct for certain (up to a limit) anomalies in the "state"
of the driver.  The key point is that its algorithms work well, ie they make
sense are applied properly.

In this case Roy had to identify and then program into QTR create ICC the
manipulations performed on the measurement data which is fed to QTR Create
ICC.  Initial versions weren't operating properly because the wtpt flag was
incorrect.  Then they didn't work properly because we had not identified
that the measured data had to be scaled for media relativity.  The formula
for this scaling is part of the ICC spec and so this wasn't too hard to fix
- once the problem was identified.  At the other end, Roy found that he
could not get Adobe BPC to work with the new LUT based profiles (it seems
odd that he couldn't) and so had to embed the necessary bkpt scaling into
the profile ie he had to perform another manipulation to the measured data
prior to its inclusion in the profile.  There is very little information
available on exactly how Adobe BPC is done. (It is not part of the ICC
spec.)  If any of these computations were done improperly then the profile
would be improper.  But you'd still get wysiwyg because the same profile is
used for printing and proofing.

Therefore I am simply saying that wysiwyg is not a proof that the transform
being deployed is sound or soundly deployed.


> From: Tyler Boley <tyler@...>
> Reply-To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Date: Sun, 23 Oct 2005 19:56:34 -0000
> To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Subject: Re: [Digital BW] ICC v. Transfer Function in Epson driver
> 
> I'm saying that no matter what the characteristics of the driver (this
> includes it's linearized
> state) a profile to profile conversion will make those unique characteristics
> nearly 
> irrelevant. Therefore the particulars of the linearization standard become
> less important. 
> This can be witnessed by the wide variety and undesirable non-linear nature of
> Epson 
> drivers, but when well profiled will all print very much the same given
> ink/media similarity.
> Obviously at a certain point of "bad" behavior a profile conversion will only
> be able to do 
> so much, and it breaks down.
> Given your extreme example, if the badly behaving device is well profiled,

I did not say the device was behaving badly but rather the profile algorithm
was improper.  You can have a well behaved device and even good measurement
input for the profile but if the profile clips the data because its bpc its
"incorrect" then you are not going to get very far.

> some of those 
> problems will be taken care of at the profile conversion point, and what isn't
> I can deal 
> with in soft proof. Clearly though, "linearizing" that behavior out to begin
> with would be 
> best...
> I'm just saying in a CM workflow, the standard becomes less important, the
> profile 
> conversion will become very important.

I am simply saying that one needs to test the sensibility and implementation
of the computation that manages the differences in tonal range response.