Re: null match
Re: null match
- Subject: Re: null match
- From: Graeme Gill <email@hidden>
- Date: Mon, 15 Jul 2002 13:39:40 +1000
Chris Murphy wrote:
>
>I'm merely observing that running a CMYK value though the A2B table
>
>of profileA, and then running the PCS through the B2A table of profileA,
>
>will definitely give a different CMYK value than you started with, and
>
>will have been modified in ways that a particular user may regard as
>
>desirable
>
>
I'd like to know what sequence of steps allows you to use the same
>
profile as source and destination and you end up with different CMYK
>
values than you started with. I'm unable to reproduce this in Photoshop
>
with either ACE or the AppleCMM selected. I get the same values, no
>
matter the rendering intent.
Well, if the underlying CMM is removing "null matches", I'm not
surprised that you can't reproduce the effect!
To go through the steps manually using my command line
tools (icclu) with a typical CMYK profile (Chromalin proof media):
icclu -ff -ir cromalin.pf
.1 .2 .3 .05
0.100000 0.200000 0.300000 0.050000 [CMYK] -> Lut -> 76.483270 9.071158 21.767575 [Lab]
icclu -fb -ir cromalin.pf
76.483270 9.071158 21.767575
76.483270 9.071158 21.767575 [Lab] -> Lut -> 0.024541 0.163494 0.294350 0.149410 [CMYK]
and of course because the color has been converted to PCS and back,
the black generation has been removed, and ink limiting applied. A more
graphic example of the later for an inkjet profile:
icclu -ff -ir e10kpftlxsh.icm
1 1 1 1
1.000000 1.000000 1.000000 1.000000 [CMYK] -> Lut -> 0.000000 -2.151653 -5.195531 [Lab]
icclu -fb -ir e10kpftlxsh.icm
0.000000 -2.151653 -5.195531
0.000000 -2.151653 -5.195531 [Lab] -> Lut -> 0.065713 0.092986 0.939832 0.945039 [CMYK]
>
Some users want/expect all kinds of things they can't have. This is one
>
of them. If they want a conversion to occur where the source and
>
destination are the same, they will first need to convert to an interim
>
space, or they can use a device link profile.
I've got no problem with, a CMM behaving in this way, I was just hoping
to uncover the reasoning behind it, and to discover whether the
issue I raised had been thought through. I seem to have failed to
provoke any sort of in-depth discussion :-(
>
Have you sent them feedback? They were soliciting feedback a number of
>
months ago.
On the latest release yes. Many of the issues are of long standing,
and I know the ICC is aware of my concerns, as the web page in which
I detailed them was quoted in a set of their minutes, some time ago.
(see what happens when you don't protect a "private" web page well
enough, and the search engines get hold of it!)
>
Actually it also doesn't say that null matches MUST be honored through
>
conversion. To cause a conversion when source and destination are the
>
same by default is bad for workflow. It causes unnecessary conversions,
>
by default. It's safer for a conversion to not occur by default. If
>
you're looking to ensure ink limits have been honored, there's software
>
specifically designed to do this.
So you are asserting, and maybe you're right. It would be nice to
hear the reasoning though, and to hear some of the "use cases".
Graeme Gill.
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.