Send Colorsync-users mailing list submissions to
email@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.apple.com/mailman/listinfo/colorsync-users
or, via email, send a message with subject or body 'help' to
email@hidden
You can reach the person managing the list at
email@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Colorsync-users digest..."
Today's Topics:
1. FERIENABWESENHEIT: Colorsync-users Digest, Vol 8, Issue 105
(email@hidden)
2. Re: Printing with No Color Management (again) (Graeme Gill)
3. Re: Printing with No Color Management (again) (Chris Murphy)
4. Re: Printing with No Color Management (again) (Graeme Gill)
5. RE: Profile monitor for many users (Matthew Finlay)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Apr 2011 03:24:02 +0200
From: email@hidden
Subject: FERIENABWESENHEIT: Colorsync-users Digest, Vol 8, Issue 105
To: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset="UTF-8"
------------------------------
Message: 2
Date: Thu, 28 Apr 2011 12:31:11 +1000
From: Graeme Gill <email@hidden>
Subject: Re: Printing with No Color Management (again)
To: ColorSync <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
------------------------------
Message: 3
Date: Wed, 27 Apr 2011 21:08:20 -0600
From: Chris Murphy <email@hidden>
Subject: Re: Printing with No Color Management (again)
To: Graeme Gill <email@hidden>
Cc: ColorSync <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=us-ascii
On Apr 27, 2011, at 8:31 PM, Graeme Gill wrote:
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.
It's not just printing test charts. Prematched print jobs are in the
same category. Those are clearly still a minority of all Mac OS
print pipeline print jobs, but it overwhelms the volume of test
chart print jobs.
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".
Does not happen on Windows.
Does not happen with PDF/X-3 workflows if you actually follow the
spec, unless encountering a lifeform that has not been found on
numerous recorded worlds, one that has acid for blood, etc.
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.
Apple might actually believe this, but it fails to withstand
scrutiny. kPMApplicationColorMatching does not apply to the ~90%
workflows where the app is not color aware, or for ordinary users.
It's used in a very express situation, exactly and only the express
use cases: targets and prematched content. Therefore the two cases
are not concomitant, and any notion of trade-off is a false
impression.
There is absolutely zero reason I have found why Apple cannot leave
everything exactly the way they want for that 90% of ordinary users
and apps (the vast majority of which don't knowingly use ColorSync,
using printer manufacturer proprietary defaults instead), and also
provide a reliable off switch using a special SPI or API for doing
so, and readily making documentation available to the handful of
companies you and I could count on two hands, that really need it.
Not just would want it. But necessary for their business models and
software to function.
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.
Sorry yes, I'm not thinking of Adobe as being in the print profile
application business. I think of those as companies like X-Rite,
ICS, you, and a few others. But yes it does use it.
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.
There are a bunch of APIs that capture driver dialog settings that
get baked into the PDF print spool file and also there's 2nd
"sidecar" like file that contains other metadata for theprinting
system. So directly inserting a PDF minus all of this other stuff I
don't think would be straightforward.
More straightforward would be to yank cgpdftoraster which calls
Quartz2D which is responsible for rasterizing and calling ColorSync,
for something that just rasterizes and never calls ColorSync. CUPS
is designed for swapping out raster filters so someone could do it,
but would it survive OS updates? What else would break? What other
things are you stepping on since Epson, HP, Canon drivers all
currently depend on it. I'm not sure. But I have thought about it.
Chris Murphy
------------------------------
Message: 4
Date: Thu, 28 Apr 2011 13:54:35 +1000
From: Graeme Gill <email@hidden>
Subject: Re: Printing with No Color Management (again)
To: ColorSync <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Chris Murphy wrote:
I guess the other approach would be to see about writing ones own
PDF into the print
queue, bypassing the whole mess.
There are a bunch of APIs that capture driver dialog settings that
get baked into the
PDF print spool file and also there's 2nd "sidecar" like file that
contains other
metadata for theprinting system. So directly inserting a PDF minus
all of this other
stuff I don't think would be straightforward.
More straightforward would be to yank cgpdftoraster which calls
Quartz2D which is
responsible for rasterizing and calling ColorSync, for something
that just rasterizes
and never calls ColorSync. CUPS is designed for swapping out raster
filters so someone
could do it, but would it survive OS updates? What else would
break? What other things
are you stepping on since Epson, HP, Canon drivers all currently
depend on it. I'm not
sure. But I have thought about it.
It would be a trade-off of risk. If the failure mode is not to work
at all rather
than producing the wrong color, it might be a reasonable choice
though. The trick
would be using a replacement for cgpdftoraster for just for the test
charts,
not a general replacement. That doesn't help application color
matching though.
Graeme Gill.
------------------------------
Message: 5
Date: Thu, 28 Apr 2011 17:14:32 +1000
From: Matthew Finlay <email@hidden>
Subject: RE: Profile monitor for many users
To: John Gnaegy <email@hidden>
Cc: email@hidden
Message-ID:
<email@hidden>
Content-Type: text/plain; charset=us-ascii
Hi John,
Thanks for your reply. Sorry for any perceived "apple bashing", this
was
not my intention. I was merely trying to point out what I believe to
be
an issue.
If there is another more correct channel in which I should be
directing
my concerns please let me know...
I can now understand why this approach was taken when apple were
developing this architecture for use with their manual color
calibration
utility.
Despite the "usefulness" of Apple's "Calibrate" utility to people who
may need a quick fix and do not want to pay for a spectrophotometer or
colorimeter to calibrate their monitor, IMO very few "professionals"
would actually use this software as it is based on visual correction
which is arbitrary.
The current norm for professional users is to calibrate their monitor
using a measuring device such as those described above. With many
currently available monitor profiling software packages it is now also
possible to verify how accurate a display/display profile
combination is
through a series of measurements and comparisons. So to answer your
questions:
Q.) "You can have more than one admin user, so what happens if they
disagree on which profile all other users should use?"
A.) It is possible to prove which profile is more suited to the
display.
Use the most correct profile.
Q.) "Does the most recent admin profile choice override the previous
choice of another admin user?"
A.) Yes. That way a monitor can be continually re-profiled over time
to
adjust for drifts in it's behavior.
Q.) "Won't that come as a surprise to the original admin user?"
A.) Not if the color is being managed correctly.
You may see this as a "request" but to professional users it is
really a
"requirement" of any system which allows its users to manage color
across an environment with multiple users.
I guess the real question is one of responsibility though, do you see
this as the responsibility of apple to create this functionality or do
you feel that the software developers who create this kind of product,
will have to try to create their own customized ways to bypass this
issue?
Regards
Matt
-----Original Message-----
From: John Gnaegy [mailto:email@hidden]
Sent: Friday, April 22, 2011 5:48 AM
To: Forum ColorSync
Cc: Matthew Finlay; MARK SEGAL
Subject: Re: Profile monitor for many users
This isn't a flaw, a bug, or broken. I know it's much more dramatic
to
portray it that way so if you want to, sure go for it. But that's not
what it is.
It's intentionally designed to allow a user choices over the
calibration
of their display for white point and gamma. It's intentionally
designed
to allow a user to create multiple profiles reflecting these choices.
What you are describing, letting an admin user disallow all other
users
from having that choice, is a feature request. Feature request is not
the same as "it's flawed now". You can have more than one admin
user,
so what happens if they disagree on which profile all other users
should
use? Does the most recent admin profile choice override the previous
choice of another admin user? Won't that come as a surprise to the
original admin user?
I understand the situation you describe, you want to be able to manage
this choice for multiple users. Ok, that's a request. You don't
really
need to go past "request" and into a rant about how flawed it is and
how
horrible Apple is. There's plenty of internet for that, but not here.
------------------------------
_______________________________________________
Colorsync-users mailing list
email@hidden
http://lists.apple.com/mailman/listinfo/colorsync-users
End of Colorsync-users Digest, Vol 8, Issue 106
***********************************************