[Lcms-user] Re: Questions on CMS

[<ma...@li...>]

Hi,

>>Proofing is a bit more complex since it involves two intents.
>I agree and is a stumbling block for the end user. Unfortunately, many of 
>the terms used for CMS can obscure the meaning of things for end users.  

Yes. But has some logic indeed.
For example, I want to proof how a photo will look on a given printer. 
The "main" transform would be perceptual, since what I will use to 
print is perceptual to maintain contrast. Then, I could choose to 
view the proof  perceptually, that is, matching the _appearance_ of 
the printed sheet, or absolute, that is the rendered  colors on sheet 
ready to side-by-side matching. 

Most users are unaware the adaptation stuff done by the our eye/brain, 
so they choose "absolute colorimetric"... Only to next  complain about 
"yellowish" result. 

Absolute proof does completly depends of the illuminant used, and 
since ICC system is based on D50, proof is viewed as done on a D50 
box. 

In the other hand, perceptual will us give a overall proof on how 
will look the result, no matter wich illuminant and with the only
 requeriment of fully adapted observer. A nice feature IMHO. 
But it cannot match side-by side unless the room illuminant were D50.
Not very frequent after all. 

So, what to choose as default?
I belive each one has its virtues/defects, and the best move would be
to let enduser to select between them, perhaps giving perceptual as 
a reasonable default (Windows ICM does use abs. colorimetric by 
default)


>My only comment is I have one client set up like this and 95% of their 
>images have a workflow like this:
>
>Scanned RGB tiffs - no auto level adjustments in the scan> PS 6> Source=scanner 
>profile > Destination= CMYK Press Profile. Working space is Bruce RGB or Adobe 
>RGB.  

Very typical workflow. I assume workspace to be efectively null, 
since PS6 does use workspace only to modify image. This can be done 
by lcms by just ONE transform, scanned RGB tiff -> CMYK Press profile. 
You can use TIFFICC utility to do some testing. TIFFICC can do
the conversion even more accurately, by using 16-bit TIFF. 
If you want to do softproofing to your monitor, you will need another 
transform, form CMYK output space to monitor RGB. Here applies the
intent stuff I was commenting before.


>At least my clients have, uncommonly I find, : 1) Accurate monitor 
>profiles refreshed every couple of months. ( I tape the settings over, 
>once they are set properly.) 2) A fairly accurate press profile with 
>matching inks and paper. 3) Fairly consistent soft proofs from machine to 
>machine.   

These are the three big issues on the stuff, I agree. Specially the
monitor, that IMHO has a vital role.

> Testing by me shows relative colorimetric gives us very similar results. 

As it should. 

Perceptual = Relative colorimetric + appearance corrections 

In your case all would be same except on gamut boundaries. But there 
are gamut mapping algorimts that does move all colors, in this case 
intents are different. Although this is really a rare case.


>Can you tell me which program can or by default put in the preview tag? 
>Is there a way in little CMS to do this programmatically?

As said I think a aproximation could be done by two transforms, and 
indeed I would avoid the preview tag. Not because lcms being buggy,
that is not, just because most profile builders does stored bogus
content in preview tags!! surprising but true. Chris Cox did notify 
me that Adobe itself is ignoring such tag for this reason.



>I am playing with the monitor profiler.  Works well - no crashes.  I'll 
>have some questions about that later on. I'll have a chance to test the 
>scanner profiler soon. 

Glad to know :-)

Best regards,
Marti.