Re: Printing with No Color Management (again)
Re: Printing with No Color Management (again)
- Subject: Re: Printing with No Color Management (again)
- From: Graeme Gill <email@hidden>
- Date: Thu, 28 Apr 2011 12:31:11 +1000
Chris Murphy wrote:
Yes, I agree. But I also think they don't really understand that what an ugly hack is,
or they'd realize the multitude of ugly hacks they have already rolled into Mac OS X to
make this function the way it does. It is, in effect, a Rube Goldberg contraption that
does goes to extremely unnecessary and complicate lengths to do a straightforward
thing, and then regularly fails to reliably print profile targets or prematched
content.
I think I understand how you can end up in such a position. Printing test charts
is a "special case", that doesn't fit into normal color workflow. That's awkward.
In a flash the idea comes to mind - the null transform! Neat. This is a way
of making the special case go away, of making sure that every device color
space is labelled, so that everything is guaranteed to be color managed.
Once that idea has lodged in place, and a whole system has grown up
around it, it's difficult to reconsider it. It's hard to say
"I was wrong, I stuffed up".
It's only if you start looking closely that the cracks are revealed. In
reality there is rarely a real null transform. Even the initial case
of gamma/matrix profiles isn't perfect if you follow the current ICC
spec. If you transform a PCS to device and the device clips, then
the device to PCS doesn't give you the same value. Oops. Then
as soon as you introduce tables, it gets worse - tables are approximate,
they don't perfectly reverse. Then it gets worse - cLUT profiles have
intents. There is no guarantee that (say) a perceptual intent A2B
is the mirror of the B2A. Then it gets worse - CMYK profiles
won't preserve the black value. So the CMM recognising that the
source and destination profiles are the same, and substituting
a null transform is in fact introducing a special case that
may behave quite differently to what would be expected.
Depending on the system organization that special case may
be important in eliminating unnecessary conversions that would
slow things down and degrade quality. (I think it would be better to
eliminate such situations though.)
But there is the more fundamental issue I already mentioned,
that it doesn't actually convey the correct intention. It's
just a side effect.
Telling people the present architecture "works as designed" is pretty hilarious because
in effect it's a statement that Apple thinks that having the most unreliable printing
architecture on the planet for professionals who depend on ICC workflows, is either
something Apple intended to provide us in advance, or the fact that's how it has turned
out is something they don't have a problem with.
A guess would be that the following trade-off was made:
Using this scheme makes color work more reliably for ordinary users,
particularly in the face of applications that aren't color aware. The
trade-off is that it makes things less reliable for color professionals.
Color professionals are a small group compared to ordinary users, and
they are more technically sophisticated. Hmm.
The real answer is not to be in a position to trade one group
of users experience for another's.
Don't take it personally. Of all the companies you'd think Apple would have been
pro-active in informing what SPI (or API) to use, it would be the companies that
produce apps that print profile targets. From my testing thus far, NONE of them are
using kPMApplicationColorMatching and I would not be surprised if none of them has ever
heard of it because it's not a public API. You have to know about it, to ask about it.
And I think that's fakaked.
Hmm. Adobe use it in ACPU - I can see the string in the executable. It is
in the system header OPMPrintSettingsKeys.h:
/* Possible values for the kPMColorMatchingModeKey*/
#define kPMVendorColorMatchingStr "AP_VendorColorMatching"
#define kPMApplicationColorMatchingStr "AP_ApplicationColorMatching"
#define kPMColorMatchingModeStr "AP_ColorMatchingMode"
/* Value is CFStringRef - one of kPMColorSyncMatching (deprecated),
kPMVendorColorMatching,
kPMApplicationColorMatching */
Of course one has to guess how to use it.....
There are no references on http://developer.apple.com/,
(But then Apples development doco has always been a bit hit or miss in my
experience.)
I guess the other approach would be to see about writing ones own PDF
into the print queue, bypassing the whole mess.
Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden