Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: Simon J.A. Simpson on March 08, 2012, 05:04:43 pm
-
In 2010 I bought a ColorMunki and have used it to successfully produce profiles for monitors and printers alike. Until recently I was using Apple’s Tiger (OSX 10.4.11) on a G5. I have two Canon printers, and A4 and A3 Pro.
Recently my G5 tower gave up and I acquired a new 27 inch iMac. This, of course has Lion (OSX 10.7.2). And this is when things started to become ‘interesting’.
For those who don’t know, the ColorMunki software produces its own targets (colour patches) and you print direct from the software.
The colour management path is quite different in the two operating systems. The issue revolves around the setting in the printer dialogue under “Color Matching” (see screenshot below).
When printing from Photoshop, using ‘Photoshop Manages Colors’ the “Color Matching” option is greyed-out in the printer dialogue although the “ColorSync” radio button is selected (but greyed).
When printing using the ColorMunki software there is a choice of “ColorSync” or “Canon Color Matching”. This is, of course, counter intuitive – we don’t actually want any colour matching. Using “ColorSync” you can then choose from a list of profiles. Leaving it on “Automatic” the driver seems to select a profile of the Canon paper type selected in the driver (it is listed underneath the menu – see screenshot below).
So what “Color Matching” should you select in the printer dialogue ?
In brief, there is conflicting advice – but advice which concurs with Eric Chan’s ‘null transform’ workaround.
On their website X-Rite ColorMunki advise using “ColorSync” and selecting the “Generic RGB” profile.
Datacolor/Spyder’s advice is more specific as to printers and operating systems. The most up-to-date operating system they refer to is Snow Leopard 10.6.3 and they say to use the “sRGB” profile.
So I have conducted some tests.
I have printed targets selecting the following profiles under “Color Matching”:
1. ColorSync – Generic RGB profile
2. ColorSync – sRGB profile
3. ColorSync – ProPhoto profile
I have also a target printed under Tiger to compare them with.
In addition I used the print dialogue to export a PDF of the target which I rasterised in Photoshop (CS5). When importing it had as its “Mode” set as sRGB (whatever that means) and had an sRGB profile attached. I discarded the profile and opened it as a ‘non colour managed’ document. I saved it as a tiff and then printed it using Adobe’s ‘Color Printer Utility’ (designed for printing targets without colour management). For ease of reference I will call this test print the “PDF target”.
So, what did I find ?
Well all the targets are different. We can disregard the ProPhoto target as that was wildly out (much too light). The Generic RGB target was slightly darker than the other three so can we safely eliminate that one ? That leaves the remaining three:
a. sRGB target
b. Tiger target
c. PDF target
There are slight visual, and measurable, differences between all the three. There are slight differences in hue and lightness.
So my question is this:
Which of the three targets will most closely replicate the conditions under which Photoshop prints ‘Photoshop Manages Colors’ so I can get accurate prints ?
-
When printing from Photoshop, using ‘Photoshop Manages Colors’ the “Color Matching” option is greyed-out in the printer dialogue although the “ColorSync” radio button is selected (but greyed).
Some software products are using a private (undocumented) SPI called kPMApplicationColorMatching which you see in Photoshop and Lightroom and the Adobe Color Print Utility. When you set Application Manages Color, the area of the driver that controls Colorsync will alter the radio buttons such they are grayed out. X-Rite’s i1Profiler has also implemented this SPI so I suspect at some point, we’ll see ColorMunki use it too.
-
You need to be selecting Canon Color Matching and then set No Color Correction on in the driver when printing from ColorMunki.
Also to clarify your attachment shows the dialog you will get from an application that uses Apples old printing path or a setting of Printer Manages Color from application that uses Apples new printing path.
I would use the Print Dialog to output a tif for printing in Adobe’s ‘Color Printer Utility’. I think I tested the PDF method one time and could not find a way to create a tif from it with some conversion happening. This I tested from a profiling application that had the ability to export tif and that was the only method I could find to get a match in PS.
The big question is how does your Canon driver support applications that use Apples new printing path? Does the driver need a special cases file like the Canon iPF drivers or not. Refer to this thread for information on that. http://www.luminous-landscape.com/forum/index.php?topic=58226.0
-
Rodney.
When Photoshop is using the kPMApplicationColorMatching SPI is it using the ‘null transform” method or is it switching colour management off ?
-
Just for clarification, although it may not change things, OS X Lion is now up to v 10.7.3 so Simon you may want to update . idon't know what if any changes were made between 10.7.2 and 10.7. 3 as I went straight from 10.6.8 to 10.7.3.
-
When Photoshop is using the kPMApplicationColorMatching SPI is it using the ‘null transform” method or is it switching colour management off ?
As far as I know, this simply sets this portion of the driver for the user correctly and doesn’t allow them to set it incorrectly.
-
So I guess we still don't know what is going on, under the hood so to speak, when ‘Photoshop Manages Color’ – what is happening when the the “kPMApplicationColorMatching” SPI is used. Is it a “null transform’ or simply switching-off colour management in the Apple part of the path. It would be useful to know so as which method to adopt when printing targets.
It is clear to me now that there are three things which can manage the colour in the printing path:
1: The printing application
2: The Apple OS
3: The printer driver.
Hmmm … Thinking aloud – eliminating what is going on in the Apple part of the path seems to be the problem.
-
Hmmm … Thinking aloud – eliminating what is going on in the Apple part of the path seems to be the problem.
There are plenty of printer drivers that do this ( eliminating what is going on in the Apple part of the path), so what does that say.
-
I've been talking with Adobe's Printing engineer about all of this and what's in store for the future and indeed it's a mess. To make a long story short when "Printer Manages Colors" is specified Photoshop sends profiledRGB, ProfiledCMYK and ProfiledGray to the OS without conversion. The OS may change the colorspace if it's not in the correct color mode (like RGB for inkjets). So the Null transform trick is *the* way to profile both RGB and CMYK devices from PSCS5. Just make sure to choose RGB for printer drivers and CMYK for true Postscript printers. I've been implementing this procedure as I travel around the country profiling all kinds of devices and it's been working great for some time.
-
So the Null transform trick is *the* way to profile both RGB and CMYK devices from PSCS5.
What about just using Adobe’s Color Print Utility?
-
You need to be selecting Canon Color Matching and then set No Color Correction on in the driver when printing from ColorMunki.
There is no simple way (like a radio button or menu item) of turning ‘off’ colour management in the driver, or selecting ‘No Color Correction’.
There are plenty of printer drivers that do this (eliminating what is going on in the Apple part of the path), so what does that say.
Actually, the printer driver cannot, by definition, eliminate what is going on in the Apple part of the path – in the same way that an application cannot. This is the problem, for all brands of printer and indeed all applications. It says, therefore, this is an Apple created problem.
Onsight.
Thank you for your posting. This gives me the confidence to stick with the ‘null transform’ method and selecting an sRGB profile. I will try making and testing some profiles over the next few days and report back.
What about just using Adobe’s Color Print Utility?
This is what I was wondering. But what is odd is that the ‘null transform’ and the Adobe Print Utility targets (see above) are slightly different, visually and measured, when I would expect them to be the same. But the ‘settings’ for printing of the targets (application/Apple/printer) have to exactly replicate those for making accurate prints from the resulting profile. Thus my question as to which method to use. Perhaps Adobe or Apple could give us the answer since this is the crux of the matter ?
-
Going back to the original question on how to properly print profiling targets:
Simple answer: Use Windows. It just works. Oh wait ... wasn't that a slogan (http://www.youtube.com/watch?v=rnzCnPSQM7c) for something else?
On a Mac, your best bet is, as Andrew mentions above, to use Adobe's print utility. As far as I am aware, none of X-Rite's applications use kPMApplicationColorMatching. Without it, any print driver claiming a native color management mode using an ICC profile rather than sRGB or Adobe RGB will create a color transform on the way to the printer and corrupt your targets. A really wonderful aspect of Apple's mess is that the kPMApplicationColorMatching SPI allows, by design even, some objects to be managed by ColorSync while the remainder are not. What could be the practical use of that? Beats me.
If you use the ACPU for target printing be aware that it shrinks the target dimensions by about 3%. If you are using minimum patch dimensions, this can create chart reading problems or measurement inaccuracies depending on the instrument used. Scale the target size up slightly and you'll be fine.
-
As far as I am aware, none of X-Rite's applications use kPMApplicationColorMatching.
i1Profile is.
-
What about just using Adobe’s Color Print Utility?
Although it works great for the inkjet-only masses, it's functionally is too limited for people like myself for these reasons:
1) Occasional issues with scaling.
2) Doesn't support CMYK or Grayscale.
3) The masses have Photoshop and don't have ACPU. In a remote profiling situation the hassle of downloading and using new software is just too much for some people.
-
On a Mac, your best bet is, as Andrew mentions above, to use Adobe's print utility.
Why use the ACPU when you can use the Null transform trick? It's one method that works for all devices on all operating systems.
-
Onsight. Thank you for your posting. This gives me the confidence to stick with the ‘null transform’ method and selecting an sRGB profile.
Recommend assigning and printing with AdobeRGB (RelCol, no BPC) over sRGB. There are a lot of weird sRGB profiles out there. I'm using the old "U.S. Web Coated (SWOP) v2" profile to profile CMYK Postscript devices (think laser printers).
-
Recommend assigning and printing with AdobeRGB (RelCol, no BPC) over sRGB. There are a lot of weird sRGB profiles out there. I'm using the old "U.S. Web Coated (SWOP) v2" profile to profile CMYK Postscript devices (think laser printers).
Scott, I'm not quite sure we're on the same page here ?
Having tried this in previous testing (not quite as the OP above) I would not be confident that the Adobe RGB would work in a ‘null transform’. Certainly there are visible differences between using sRGB (point taken about weird profiles), Generic RGB, and ProPhoto RGB (the last being dramatically different). My understanding is that, in theory, the profile does not take part in the Apple part of the printing path, it merely tells the Apple part not to ‘colour mange’ the document (oh what tangled web has Apple woven !).
BTW – Andrew, sorry to have have called you Rodney (smiles apologetically). My mistake.
-
Simple answer: Use Windows. It just works. Oh wait ... wasn't that a slogan (http://www.youtube.com/watch?v=rnzCnPSQM7c) for something else?
Actually I'm told Microsoft is following Apple lead and will soon adopt the policy of converting images in the wrong color mode to the correct color mode as Apple's OS does now. Adobe tells me they are prepping for this and because they have no control over the OS they were forced to eliminate the "No Color Management" policy. Again, the null transform trick in CS5 behaves identically to CS3's "No Color Management" as long as it's done right.
-
[quote author=SimonS link=topic=63451.msg511229#msg511229 date=1331400635
Actually, the printer driver cannot, by definition, eliminate what is going on in the Apple part of the path – in the same way that an application cannot. This is the problem, for all brands of printer and indeed all applications. It says, therefore, this is an Apple created problem.
[/quote]
This is simple not the truth. There are many printer driver and application combinations that do not cause the OS to do any CM in the driver or the OS.
-
Having tried this in previous testing (not quite as the OP above) I would not be confident that the Adobe RGB would work in a ‘null transform’.
Yes, be confident that it will! It does. CS5 works great for the null transform trick via RGB, CMYK and Grayscale. Your results may vary on old versions of PS.
Certainly there are visible differences between using sRGB (point taken about weird profiles), Generic RGB, and ProPhoto RGB (the last being dramatically different).
Doesn't matter. For RGB profiling targets, assign and print with AdobeRGB, RelCol, noBPC and you're good.
My understanding is that, in theory, the profile does not take part in the Apple part of the printing path....
In theory yes, in real world usage, some profiles have been known to screw this up.
-
I did some testing with Chris Murphy a few weeks back when some of his students indicated there might be an issue with Lion. Here is the copy and paste using several methods of printing targets. ACPU is the Adobe Color Print Utility:
Targets printed on Luster, Epson 4900. Dried down over the weekend.
ACPU 10.6.8 vs. 10.7.3
-------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.21
Max dE: 0.66
Min dE: 0.01
StdDev dE: 0.10
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.19
Max dE: 0.35
Min dE: 0.01
StdDev dE: 0.08
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.41
Max dE: 0.66
Min dE: 0.35
StdDev dE: 0.06
--------------------------------------------------
--------------------------------------------------
So no issue there.
Then there is i1Profiler versus ACPU on 10.6.8:
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.43
Max dE: 0.84
Min dE: 0.04
StdDev dE: 0.17
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.39
Max dE: 0.66
Min dE: 0.04
StdDev dE: 0.15
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.73
Max dE: 0.84
Min dE: 0.66
StdDev dE: 0.04
--------------------------------------------------
--------------------------------------------------
i1Profiler 10.6.8 vs. 10.7.3 (this is a tad high which is odd):
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.50
Max dE: 1.12
Min dE: 0.02
StdDev dE: 0.24
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.45
Max dE: 0.82
Min dE: 0.02
StdDev dE: 0.20
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.91
Max dE: 1.12
Min dE: 0.82
StdDev dE: 0.07
--------------------------------------------------
--------------------------------------------------
Finally i1Profiler vs. APCU on 10.7.3:
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.14
Max dE: 0.46
Min dE: 0.01
StdDev dE: 0.08
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.13
Max dE: 0.25
Min dE: 0.01
StdDev dE: 0.06
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.30
Max dE: 0.46
Min dE: 0.25
StdDev dE: 0.05
--------------------------------------------------
--------------------------------------------------
So Chris, at least with this paper on a 4900, I think all is good with ACPU and perhaps i1P. An average dE of .5 isn’t great, leading me to recommend the use of ACPU until we hear further from X-Rite.
-
Scott, I'm not quite sure we're on the same page here ?
Having tried this in previous testing (not quite as the OP above) I would not be confident that the Adobe RGB would work in a ‘null transform’. Certainly there are visible differences between using sRGB (point taken about weird profiles), Generic RGB, and ProPhoto RGB (the last being dramatically different). My understanding is that, in theory, the profile does not take part in the Apple part of the printing path, it merely tells the Apple part not to ‘colour mange’ the document (oh what tangled web has Apple woven !).
BTW – Andrew, sorry to have have called you Rodney (smiles apologetically). My mistake.
The only way a null transformation will work is if you can determined the profile that your driver OS combination is using when it cannot turn off CM and then use that profile assigned to the target file in PS, because in PSCS5 you can not send to the printer an unmanaged target like you could in PSCS4 with the No Color Management setting. That is what the Adobe Color Printing Utility is for.
But it sounds like your printer driver is not able to turn off CM when instructed to by an application.
-
I did some testing with Chris Murphy a few weeks back when some of his students indicated there might be an issue with Lion. Here is the copy and paste using several methods of printing targets. ACPU is the Adobe Color Print Utility:
Why don't you throw in Null Transform trick!? And CMYK and Grayscale device profiling? :-] I think you'll find the null transform trick one method that works for all of them on all operating systems...
-
Why don't you throw in Null Transform trick!? And CMYK and Grayscale device profiling? :-] I think you'll find the null transform trick one method that works for all of them on all operating systems...
Scott would you agree that when a printer driver is working properly and turning CM off that the null transformation prints a target correctly, but when and printer driver is not working correctly and not turning off CM then it not print a target correctly unless you can determined the exact profile being used in the driver OS conversion and what rendering intent.
I believe this is the heart of SimonS's problem and his lack of understanding what is going on here.
-
The only way a null transformation will work is if you can determined the profile that your driver OS combination is using when it cannot turn off CM and then use that profile assigned to the target file in PS, because...
Can you tell me a situation where the null transform trick using AdobeRGB doesn't work in CS5 for RGB managed printers? Can you tell me a situation where the null tranform trick using "U.S. Web Coated (SWOP) v2" doesn't work in CS5 for CMYK managed Postscript laser printers?
And yes, like you, I like to use Photoshop's Plugin when profiling Canon iPF printers. Quite fool-proof!
in PSCS5 you can not send to the printer an unmanaged target like you could in PSCS4 with the No Color Management setting.
CS3 was the last version to have "No Color Management". CS4 had it's own problems let's not get into...
That is what the Adobe Color Printing Utility is for.
But all the same functionality and more is there in CS5... Why use ACPU with it's limitations?
-
Scott would you agree that when a printer driver is working properly and turning CM off that the null transformation prints a target correctly, but when and printer driver is not working correctly and not turning off CM then it not print a target correctly unless you can determined the exact profile being used in the driver OS conversion and what rendering intent. I believe this is the heart of SimonS's problem and his lack of understanding what is going on here.
I see - thanks Doyle. Yes, we agree and I wish I was sitting at Simon's computer so we could do some testing right now. But I think the driver will behave when printing from PS with the Null Transform trick. The Munki software and otherwise may have issues...
-
Simon - as I understand it, the dialog you've posted looks that way when printing from Color Munki right? Have you tried printing from Photoshop using the Null Transform trick. To make a long story short that's how I think it should be done... There are otherwise too many variables and ways it can get screwed up.
-
Going back to the original question on how to properly print profiling targets:
Simple answer: Use Windows. It just works. Oh wait ... wasn't that a slogan (http://www.youtube.com/watch?v=rnzCnPSQM7c) for something else?
ROFL - good to see some humor here; but of course I'm a confirmed Windows user
If you use the ACPU for target printing be aware that it shrinks the target dimensions by about 3%. If you are using minimum patch dimensions, this can create chart reading problems or measurement inaccuracies depending on the instrument used. Scale the target size up slightly and you'll be fine.
Yes, this has been commented on to Adobe a number of times and they appear reluctant to do anything about it. I first noticed it when I was printing out targets to use with ArgyllCMS. Quick question, how do you scale up the target patches (Photoshop???).
thanks,
Alan
-
I see - thanks Doyle. Yes, we agree and I wish I was sitting at Simon's computer so we could do some testing right now!
I might have missed it but I don't see where SimonS mentions what specific printer he has. But, I do know with the iPF printers that if PSCS5, ACPU, or i1Profiler 1.2 were not listed in the special cases file I would be seeing the same issues when printing targets.
My experience with null transformation were with Epson printers when this issue brought about by changes in the OS first occurred. So in PSCS5 are you choosing Photoshop Manages Color or Printer Manages Color when sending a null transformed target.
-
ROFL - good to see some humor here; but of course I'm a confirmed Windows user
Yes, this has been commented on to Adobe a number of times and they appear reluctant to do anything about it. I first noticed it when I was printing out targets to use with ArgyllCMS. Quick question, how do you scale up the target patches (Photoshop???).
thanks,
Alan
Oh but shrinking targets was a Windows problem. Trading one problem for another. We can't win.
-
I might have missed it but I don't see where SimonS mentions what specific printer he has.
His screen grab shows he's using a Canon iP4700. No plug-in for that, AFAIK.
But, I do know with the iPF printers that if PSCS5, ACPU, or i1Profiler 1.2 were not listed in the special cases file I would be seeing the same issues when printing targets.
Yes, true, and thanks for all your help with the XML files. Again, this is one more reason to use the PS Plug-in when profiling iPF printers if possible.
My experience with null transformation were with Epson printers when this issue brought about by changes in the OS first occurred. So in PSCS5 are you choosing Photoshop Manages Color or Printer Manages Color when sending a null transformed target.
Just to clarify, one needs to use "Photoshop Manages Color", AdobeRGB, RelCol, noBPC with a target that has AdobeRGB assigned to it, for RGB managed printers (inkjets mostly).
-
Oh but shrinking targets was a Windows problem. Trading one problem for another. We can't win.
Yeah and Windows is about to behave exactly the same as the Mac OS as regards to all of this... Again, the null transform trick is one that works with all devices and operating systems, even upcoming ones from Microsoft and Apple within the forceable future.
-
Yeah and Windows is about to behave exactly the same as the Mac OS as regards to all of this... Again, the null transform trick is one that works with all devices and operating systems, even upcoming ones from Microsoft and Apple within the forceable future.
I think Windows 7 may be in my future for a lot longer if that's the case!
-
I think Windows 7 may be in my future for a lot longer if that's the case!
I know what you mean! I thought the same thing about XP a while ago but have been forced to move along...
-
Just to clarify, one needs to use "Photoshop Manages Color", AdobeRGB, RelCol, noBPC with a target that has AdobeRGB assigned to it, for RGB managed printers (inkjets mostly).
But for those printer drivers that will not turn off CM when "Photoshop Manages Color" is selected then you need to assign the same profile that the driver/os is using for conversion. As I recall OS 10.5 used sRGB, 10.6 uses AdobeRGB. So what is 10.7 using?
-
But for those printer drivers that will-not/ can-not turn off CM when "Photoshop Manages Color" is selected...
Which ones are those?
-
Which ones are those?
That is the big question. Which ones?
But that has to be determined first before you can start diagnosing all the other possibilities.
-
That is the big question. Which ones?
But that has to be determined first before you can start diagnosing all the other possibilities.
Do they actually exist? Show me a printer I can't profile! :-p
For my business, all things start with the null transform trick (or the PS plug-in in the case of iPF printers). If that doesn't work I'll start digging deep but it's pretty rare that that's needed. In the case of the OP I think he should start with the null transform trick and see if that doesn't work for him. I think it will work fine.
-
Do they actually exist? Show me a printer I can't profile! :-p
Pretty hard to profile consumer printers that don't respect color management nor offer a way of turning CM off. The one I've got you can't really profile is an Epson PictureMate printer. I just feed it sRGB and use Printer Manages Color.
-
I did some testing with Chris Murphy a few weeks back when some of his students indicated there might be an issue with Lion. Here is the copy and paste using several methods of printing targets. ACPU is the Adobe Color Print Utility:
Andrew: Your data suggest that the problem is i1Profiler on 10.6.8. Both the i1P vs ACPU on 10.6.8 and i1P 10.6.8 vs. i1P 10.7.3 show higher average error and, more tellingly, at least double the standard deviation of the other two comparisons. The errors are not limited to a few outliers; the "Best 90%" data also show comparatively high variances.
Actually I'm told Microsoft is following Apple lead and will soon adopt the policy of converting images in the wrong color mode to the correct color mode as Apple's OS does now. Adobe tells me they are prepping for this and because they have no control over the OS they were forced to eliminate the "No Color Management" policy. Again, the null transform trick in CS5 behaves identically to CS3's "No Color Management" as long as it's done right.
Interesting. Can't say that we've heard the same, but Adobe certainly has more extensive NDAs than we do. Windows 8 does not implement the same level of color cluelessness as does OSX. Win 7 initially was slated to support "High Color", a space with sRGB primaries but allowing values outside the [0 .. 1] range. Monitors that supported High Color would map untagged images into their native space, avoiding the wildly oversaturated look that wide-gamut panels can give. That initiative went the way of WCS.
-
Andrew: Your data suggest that the problem is i1Profiler on 10.6.8.
Well I’ve attempted to make them aware of this.
-
Pretty hard to profile consumer printers that don't respect color management nor offer a way of turning CM off. The one I've got you can't really profile is an Epson PictureMate printer. I just feed it sRGB and use Printer Manages Color.
Hey, Jeff,
Maybe it's time for you to upgrade to a serious printer, like, say the Epson 2200! ;D
-
Maybe it's time for you to upgrade to a serious printer, like, say the Epson 2200! ;D
Well, when I make quick prints for family and friends and want 4.5x6 borderless glossy, the PictureMate is just way easier...
-
Hi all,
I'm completely new at this but I was just wondering why nobody hasn't mentioned the ColorSync Utility? If you open a file and then go to Print, it has an option to "Print as color target" (under Color).
-
Hi all,
I'm completely new at this but I was just wondering why nobody hasn't mentioned the ColorSync Utility? If you open a file and then go to Print, it has an option to "Print as color target" (under Color).
Is this something new in 10.7? I don't see it in 10.6.8.
-
I'm completely new at this but I was just wondering why nobody hasn't mentioned the ColorSync Utility? If you open a file and then go to Print, it has an option to "Print as color target" (under Color).
I’ll have to test this. Yes, the option IS there and yes, it does invoke the correct settings for Color Matching (Apple as you would expect or maybe not, is implementing kPMApplicationColorMatching).
-
Is this something new in 10.7? I don't see it in 10.6.8.
I think it is new in Lion (also available in first preview of 10.8 )
-
Win 7 initially was slated to support "High Color", a space with sRGB primaries but allowing values outside the [0 .. 1] range. Monitors that supported High Color would map untagged images into their native space, avoiding the wildly oversaturated look that wide-gamut panels can give. That initiative went the way of WCS.
It does seem like many "revolutionary" color features are pumped up in the PR departement, only to be silently forgotten in when it comes to shipping actual software. I wonder why that is.
-h
-
Simon - as I understand it, the dialog you've posted looks that way when printing from Color Munki right? Have you tried printing from Photoshop using the Null Transform trick. To make a long story short that's how I think it should be done... There are otherwise too many variables and ways it can get screwed up.
Scott. No I haven't tried this. I will, over the next week and report back (might need a new pack of paper though !). The great thing about the ColorMunki software (assuming it is giving the correct target) is that its a cinch to use (or may be I'm just a bit lazy … ?!).
Hi all,
I'm completely new at this but I was just wondering why nobody hasn't mentioned the ColorSync Utility? If you open a file and then go to Print, it has an option to "Print as color target" (under Color).
Hmm, interesting. I'll try this too (takes time out to order another pack of paper). May be it'll give me yet another choice of how to print targets ! (grins). BTW, my A3+ printer is a "professional" printer – at least that's what Canon says. Would that my wife would let have something bigger (a printer, that is).
-
Something is very screwy using the ColorSync utility so I’m going to recommend not using it for now. Here are the differences between it and Adobe Print Utility and Photoshop CS5 using the null transform trick. Note that it doesn’t appear to matter if you select RelCol or Perceptual or Black Point Compensation in Photoshop:
Photoshop CS5: RelCol without BPC versus Perceptual with BPC:
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.18
Max dE: 0.71
Min dE: 0.01
StdDev dE: 0.10
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.15
Max dE: 0.31
Min dE: 0.01
StdDev dE: 0.07
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.39
Max dE: 0.71
Min dE: 0.31
StdDev dE: 0.08
--------------------------------------------------
--------------------------------------------------
Rendering intent and BPC do not appear to affect NULL transform.
ACPU vs. Photoshop (Perceptual with BPC):
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.26
Max dE: 0.97
Min dE: 0.03
StdDev dE: 0.15
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.22
Max dE: 0.45
Min dE: 0.03
StdDev dE: 0.10
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.57
Max dE: 0.97
Min dE: 0.45
StdDev dE: 0.11
--------------------------------------------------
--------------------------------------------------
ACPU vs. Photoshop (RelCol without BPC):
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.26
Max dE: 0.99
Min dE: 0.02
StdDev dE: 0.15
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.22
Max dE: 0.46
Min dE: 0.02
StdDev dE: 0.10
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.58
Max dE: 0.99
Min dE: 0.46
StdDev dE: 0.11
--------------------------------------------------
--------------------------------------------------
Now the shocker (since the above three are close, I'm only selecting one to compare with ColorSync utility):
APCU versus ColorSync Utility
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.47
Max dE: 4.08
Min dE: 0.03
StdDev dE: 0.44
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.35
Max dE: 1.02
Min dE: 0.03
StdDev dE: 0.21
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 1.52
Max dE: 4.08
Min dE: 1.02
StdDev dE: 0.52
--------------------------------------------------
--------------------------------------------------
-
Andrew,
Thank you very much!
Care to speculate on why such a large difference in the worst 10%?
-
While delta E= 4 isn't a huge error unless it's in a low chroma color, it is still puzzling to find, but just because Adobe Color utility is consistent with the null transform trick (which also relies on Adobe components) on Mac 10.7 , doesn't necessarily mean Adobe has found the "pure" unaltered data path and Apple hasn't with Colorsync Utility. If one actually completes making a profile with these two approaches, then makes prints using printer manages color (as Apple presumably thinks most of it's customers do if they choose colorsync settings), and lastly performs a delta E test comparing predicted to actual output, the outcome could possibly tip in favor of the Colorsync utility accuracy. One reason I suggest this is that I never was able to get totally consistent target generation across Mac OS 1.5 on Power PC to 10.5 on Intel and 10.6 Snow Leopard (Intel only). Differences even larger than what Andrew has reported kept cropping up. That outcome leads me sadly to believe that nowadays custom ICC profiles may not only be printer/ink/media/driver-settings specific, they may be OS specific as well! Also, Adobe Color Utility totally failed to "hijack" the printer pipeline when I tried it in conjunction with my Canon ipF8300's "Free layout" printer driver, even though the appropriate settings were grayed out. So, like Onsight, I just use the Canon 16 bit plugin for target generation. That works great, but of course, only works for certain Canon iPF printers.
-
While delta E= 4 isn't a huge error unless it's in a low chroma color, it is still puzzling to find, but just because Adobe Color utility is consistent with the null transform trick (which also relies on Adobe components) on Mac 10.7 , doesn't necessarily mean Adobe has found the "pure" unaltered data path and Apple hasn't with Colorsync Utility.
Let’s put the ColorSync test on hold a bit longer. I printed out another target in the CS utility because this first result seemed so odd, and the dEs were lower but still higher than the others. I’ve been using i1Profiler, on an iSis, with the minimum patch size it supports (6mm). This worries me a bit. So last night I built a slightly smaller patch target but with a much wider (12mm) patch and printed using ColorSync, Photoshop and ACPU. The targets were made in ColorPort and I plan to measure them today. I just don’t trust i1P at this point! Let’s wait and see if there is some ‘bug’ or other issue using the 6mm patch.
-
Let’s wait and see if there is some ‘bug’ or other issue using the 6mm patch.
Hmm, it was released nearly a year ago now.
-
I’m giving up on trying to print targets with the ColorSync utility. It is SUPER buggy just trying to get the damn target to print correctly!
I am unable to get the CS utility to exactly print a target from ColorPort correctly as far as scaling. I can’t figure out why! The original target out of i1Profiler printed just like those from Photoshop and ACPU and measured correctly. The newer target is scalled too large and will not measure.
Even if I resize the ColorPort TIFF to exactly match the other target, than copy and paste it into that document, I get wrong scaling. And the dialog here for size makes no sense to me (why is it defaulting to 70%)? Set it to 100%, way too big.
I did get measurements from CS5 and Adobe Color Print utility from dried targets using a wide, 12mm patch, the dE’s look pretty good:
--------------------------------------------------
dE Report
Number of Samples: 343
Delta-E Formula dE2000
Overall - (343 colors)
--------------------------------------------------
Average dE: 0.21
Max dE: 0.70
Min dE: 0.03
StdDev dE: 0.13
Best 90% - (308 colors)
--------------------------------------------------
Average dE: 0.18
Max dE: 0.37
Min dE: 0.03
StdDev dE: 0.09
Worst 10% - (35 colors)
--------------------------------------------------
Average dE: 0.47
Max dE: 0.70
Min dE: 0.37
StdDev dE: 0.09
--------------------------------------------------
--------------------------------------------------
I’d either print from ACPU or CS5 using the ‘null profile hack’ at this point.
-
Andrew. Many thanks for the answer, and for all your work. Much appreciated.
-
And yes, like you, I like to use Photoshop's Plugin when profiling Canon iPF printers. Quite fool-proof!
I'm not sure I'd say that as I'm seeing an average dE2k of 12.99 between ACPU and the 16 bit plugin (using CS5... I'm scanning another copy printed with CS4, but visually the CS4 and CS5 targets look identical, the ACPU version is WAAAAAAY different (OS version is 10.6.8):
dE Report
Number of Samples: 1005
Delta-E Formula dE2000
Overall - (1005 colors)
--------------------------------------------------
Average dE: 12.99
Max dE: 49.37
Min dE: 0.25
StdDev dE: 10.30
Best 90% - (904 colors)
--------------------------------------------------
Average dE: 10.33
Max dE: 29.74
Min dE: 0.25
StdDev dE: 6.66
Worst 10% - (101 colors)
--------------------------------------------------
Average dE: 36.84
Max dE: 49.37
Min dE: 29.93
StdDev dE: 4.98
--------------------------------------------------
-
I'm not sure I'd say that as I'm seeing an average dE2k of 12.99 between ACPU and the 16 bit plugin (using CS5... I'm scanning another copy printed with CS4, but visually the CS4 and CS5 targets look identical, the ACPU version is WAAAAAAY different (OS version is 10.6.8):
If the ACPU version is the one that's different, why wouldn't you say the Plug-in is fool proof?
-
If the ACPU version is the one that's different, why wouldn't you say the Plug-in is fool proof?
Because I woke up early (at least for me, 8AM is early)... and I've already taken some melatonin and it's beginning to take effect (I'm sleepy... ). ;D
Printed yet another copy with a Null Transform and visually that matches the 16 bit plugin (I've yet to confirm that with some measurements). I'm hoping that's enough confirmation that all is well with the 16 bit Plugin but damn... these things don't instill a whole lot of confidence in... well, I'm still not exactly sure who it is that I should or shouldn't have confidence in. Apple writes the APIs, it's their job to maintain the codebase and gracefully deal with changes to said codebase so I feel like they deserve a big finger pointed at them but... When ACPU is supposed to solve such problems and it doesn't match something which is.. err... was... um... is??? a known quantity, I start questioning everything. 'Tis frustrating.
Time to sleep so I can look at this with a clear head tomorrow (profiling Innova's IFA-45... very very nice stuff)
-
Which method of printing targets should we trust ?
Surely it would be the one that emulates what Photoshop does when ‘Photoshop Manages Colors’. Although we hope (and pray) this does not introduce any colour “management” per se, for printing targets for profiling we need to replicate the conditions under which Photoshop/OS/printer–driver print our (colour managed) images. Since we no longer seem to have any control over what a combination of Photoshop and the Mac OS do then somehow we need to determine which method of printing untagged target files appears to produce the minimum (or hopefully zero) difference error. Evidence to date suggests which method … ? At the moment ACPU has won out for me – subject to extended testing.
Of course Apple and Adobe engineers have the answer, but they're not telling us (or perhaps they don't know ?).
BTW Canon have a “Color Management Tool Pro” to produce targets for profiling. Current version (3.0.0) works with the ColorMunki and i1 Pro. Haven't played with it yet – but might.
-
Because I woke up early (at least for me, 8AM is early)... and I've already taken some melatonin and it's beginning to take effect (I'm sleepy... ). ;D
Printed yet another copy with a Null Transform and visually that matches the 16 bit plugin (I've yet to confirm that with some measurements). I'm hoping that's enough confirmation that all is well with the 16 bit Plugin but damn... these things don't instill a whole lot of confidence in... well, I'm still not exactly sure who it is that I should or shouldn't have confidence in. Apple writes the APIs, it's their job to maintain the codebase and gracefully deal with changes to said codebase so I feel like they deserve a big finger pointed at them but... When ACPU is supposed to solve such problems and it doesn't match something which is.. err... was... um... is??? a known quantity, I start questioning everything. 'Tis frustrating.
Time to sleep so I can look at this with a clear head tomorrow (profiling Innova's IFA-45... very very nice stuff)
ACPU will only print correctly if it is listed in the AppColorMatchingInfo.xml file.
What are your driver settings when printing from ACPU? Specifically under Main/ColorMode:?
Doyle
-
Which method of printing targets should we trust ?
I propose the null transform trick for most RGB and CMYK (Postscript) printers and the Canon printing plug-in for their large format iPF printers. This approach works 100% of the time on any system.
-
I propose the null transform trick for most RGB and CMYK (Postscript) printers....
It won't work with Photoshop CS6. Trying to use the "trick" results in a warning dlog from CS6's Print window.
-
It won't work with Photoshop CS6. Trying to use the "trick" results in a warning dlog from CS6's Print window.
What's it using to identify the profile? If it's just using the name you could always duplicate and rename a profile's file name and internal name.
Cheers, Joe
-
Well I guess the story that 16-bit applications have to use Apple's new printing path has been debunked.
Illustrator CS6 is 16-bit and does not use Apple's new printing path. It print routines still function the same as ILCS5.
-
What's it using to identify the profile? If it's just using the name you could always duplicate and rename a profile's file name and internal name.
Cheers, Joe
Why can't you use ACPU? Answer my question if you are having trouble with it.
Or use Indesign CS6 if you have it. It still allows you to turn off CM with the "Emulate Adobe Indesign 2.0 CMS Off."
Doyle
-
Why can't you use ACPU? Answer my question if you are having trouble with it.
I was going to use it as I've been printing in CS4 with the Canon 16 bit plugin but I've had CS5 on my machine for 1/2 year now and I'd like to get rid of CS4. Knowing that there were some issues with CS5 (I wasn't aware that the 16 bit plugin was exempt from those issues but makes sense that it is) I thought I'd try out ACPU and compare a chart from ACPU and the 16 Bit plugin (on the ipf8300). There was a 12.99 dE2k between the charts.
I just ran a null transform with the regular PS printing workflow to see if that agreed with the Canon plugin and indeed it does... Average dE2k of 0.33 for 1005 patches. So that's encouraging but it leaves me scratching my head as to why I'm getting such different results with ACPU.
-
ACPU will only print correctly if it is listed in the AppColorMatchingInfo.xml file.
What are your driver settings when printing from ACPU? Specifically under Main/ColorMode:?
Doyle
Sorry Doyle... I missed this earlier. I'll double check the AppColorMatchingInfo.xml file tomorrow! Thought I'd changed it but maybe I did it on one machine and not another? Always a possibility.
-
It won't work with Photoshop CS6. Trying to use the "trick" results in a warning dlog from CS6's Print window.
Yes but you can cancel it and still print with the printer profile that same as the assigned profile. Doesn't that work.
-
It won't work with Photoshop CS6. Trying to use the "trick" results in a warning dlog from CS6's Print window.
Well I need to do some more testing on this and confirm with Adobe's printing engineer but it does appear to work to me. Sure they warn us that it's not officially supported, and AdobeRGB is hidden but one can assign and print using sRGB for example... Besides the dialog box, what experiences have you that suggest it doesn't work?
While it works great for many users with limited usage, the ACPU has too many problems for someone like myself to consider using. Image resizing and no support for CMYK or grayscale being the biggest issues. There is another application coming soon that will be better, IMO. Can't say more just yet.
-
Well I finally spoke to Adobe's printing engineer this morning and yes, they've intentionally removed working space profiles from the print dialog box which makes the Null Transform Trick we know and love pretty much dead. That's not to say you couldn't use other profiles to make this trick work but some testing is in order...
-
Well I finally spoke to Adobe's printing engineer this morning and yes, they've intentionally removed working space profiles from the print dialog box which makes the Null Transform Trick we know and love pretty much dead. That's not to say you couldn't use other profiles to make this trick work but some testing is in order...
I’ve talked to them too and the reason they did this was, like removing the no color management option, to make the print process easier on the masses. It wasn’t to piss color geeks off <g>.
You’ll notice that sRGB is still around thanks to Epson, assuming you’ve got an Epson driver installed.
-
I’ve talked to them too and the reason they did this was, like removing the no color management option, to make the print process easier on the masses. It wasn’t to piss color geeks off <g>.
The removal of working space profiles was specifically to make things easier on Adobe's support team, which is distinctly different from customers.
-
The removal of working space profiles was specifically to make things easier on Adobe's support team, which is distinctly different from customers.
Sorry, that doesn’t make sense to me. If it was no issue for customers, why would they be bugging Adobe Support?
Outside of such rare null profiles, when would a user be selecting these RGB working space profiles in this print module?
-
Your points aren't lost on me Andrew. I just think there could a more elegant way of keeping all users happy. Photoshop's traditional massive list of profiles in the print dialog contrasts with Lightroom's highly focused customizable menu. Why not have a customizable menu that allows for working space profiles but shows only printer profiles by default? Simplicity and powerful flexibility can exist together - and do in the best GUI implementations.
-
Your points aren't lost on me Andrew.
My only point was that the addition of these profiles are unnecessary for the vast number of Photoshop users and apparently Adobe felt it was confusing and removed them. Just as the removed the NCM option. Other than those tiny few who print targets, it wasn’t necessary. If you look at the 20+ years of Photoshop history, it is really rare to have them remove anything, even stuff that should be removed (or at least fixed, like the Gamut warning overlay).
Photoshop's traditional massive list of profiles in the print dialog contrasts with Lightroom's highly focused customizable menu. Why not have a customizable menu that allows for working space profiles but shows only printer profiles by default?
I’d love to see that. The Photoshop team is moving into that direction as the result of output profiles for the selected printer, at least those in the packages, float towards the top.
-
Having a bunch of display profiles show up in the print dialog is useless. Hiding working space profiles and custom printer profiles is going to be pretty problematic for a fair number of users I think!
-
Would this document shed any light on this subject? Help me understand it.
http://developer.apple.com/library/mac/#technotes/tn2035/_index.html
I've been reading up on that after concerns over unexpected behavior changes in my Epson driver interface and how it deals with tagged images out of CS3 Photoshop print dialog using "Printer Manages Color" with my Epson NX400 in Mac OS 10.6.8.
At first in Tiger the Colorsync radio button was selectable over Epson Color Controls in "Color Matching" menu by first selecting "Photoshop Manages Color" in Photoshop print dialog. Now they're both grayed out with Colorsync selected. It's vice versa when "Printer Manages Color" with Epson Color Controls selected and both grayed out.
In Tiger and throughout all the driver updates I always get pretty darn close color matching where at the beginning it required the color space data be in AdobeRGB and using AdobeRGB and 1.8 gamma selected in Epson's Color Management menu.
Upgraded to new computer with OS 10.6 and now it worked having the data converted to sRGB. If I didn't have the right conversion it would show up in print similar to assigning each color space to the wrong data with regards to hue/saturation.
Now after subsequent Epson printer driver updates from Apple with the final in OS 10.6.8, it doesn't matter what color space the data is written printed out of Photoshop. I can edit the image in any color space and the Epson print using "Printer Manages Color" and the AdobeRGB 1.8 gamma Epson setting will render it faithfully in the print.
That document above got me to wonder how and in what spooling format the data of the image in Photoshop is being handed off for Epson to print from where I still get the same color match even with all these on/off driver settings and color space data changes. How is Epson, Photoshop and the image data working between each other in translating the data so it provides this match without "Photoshop Manages Color"? It's like it's generating the data from the color managed display screen dump.
This is the quote from the above Apple developer doc that makes me wonder if Quartz, PDF and Colorsync is getting involved under the hood when using "Printer Manages Color"...
From "Color Model In Quartz" chapter:
PDF color space equivalence
Another simple but very important concept that Quartz inherited from PDF is color space equivalence. An implied rule is that color conversions are necessary only if the source color space is different from the destination. Quartz takes advantage of this simple rule to properly organize the flow of color data through multiple rendering stages:
How is the data being handled and in what format is it being spooled from Photoshop and handed off to the Epson driver to get such close and consistent color matching through all the driver setting/color space changes that don't happen in Safari and Preview where I don't get a color match no matter the Epson setting or color space?
It looks as if there's something going on under the hood I don't think even the Apple and Epson engineers understand.
Correction: I can now get color matching out of Preview using Epson Color Controls and the AdobeRGB/1.8 gamma setting with the image written in sRGB. And now it works with the image written in AdobeRGB.
-
question: with Preview, you mean the apple program called Preview that comes with macs?
-
question: with Preview, you mean the apple program called Preview that comes with macs?
Yes.
But to clarify I only get matches printing on Ultra Premium Photo Glossy paper with Premium Photo Glossy selected in the Epson driver Print Settings menu where you set High Speed, Color Photo, etc. I only use the NX400 for low volume printing like on demand business cards runs which look quite good.
-
In addition all of this works as described printing out of Photoshop CS3.
Just checked printing from CS5 and the "Colorsync" and Epson Color Control radio button menu isn't grayed out with each now selectable.
The Epson Print Preview and Print Scaling/Centering interface within CS5 Photoshop print dialog has now put a button for selecting Epson Page Layout dialog for choosing Letter or Borderless Letter and other paper sizes inside the interface. In CS3 it was a separate "Page Setup..." selection above "Print..." under Photoshop's file menu.
So this is even more evidence that all three vendors Epson, Apple and Adobe are tweaking things with each upgrade/update. Who is doing what is anyone's guess.
I still get decent print matches printing to Ultra Premium Photo Glossy paper.
-
I don't know if this interests you guys, but Linux has being moving to a color managed print workflow with untagged assumed to be sRGB, as on the Mac, thereby creating a seamless printing workflows for naive Desktop Linux users who want to print their Jpeg family snapshots and mobile phone photos.
However, as the color specialist for Gutenprint, I've lobbied to make it a design goal of color management for CUPS/Gutenprint on Linux that we be able to print files with "no color management". I must say that what motivated me was my experience on the Mac the few past years, and conversations re. inkjet printing frustration which were held on the sidelines at ICC meetings I attended. After considerable debate, Till decided that a special *documented* option flag that passes through data without conversion would be implemented.
As a print option, this flag will override even the implicit assumption of sRGB now applied to print output from legacy apps. Also, entire print queues will also be able to run with this flag set, thereby allowing the use of a Linux/CUPS/Gutenprint configuration as an externally color managed print server for legacy hardware.
With some luck, and if you lobby the Mac CUPS Gods hard enough (eg. feature requests), the same options *may* be propagated back into the version of CUPS on the Mac. For political correctness, let me emphasize that these options are designed to be used exclusively by experts who deliberately wish to bypass the consumer color management which is there to serve the vast majority of users.
Here is Chris Murphy's wonderfully clear explanation of the debate and its eventual outcome:
To get color management enabled for dumb apps, we have to second guess their claimed usage of device space. Upon second guessing their claimed usage of device space, we now need an alternative way to specify when device space is really wanted. I don't see that we're going to get away with this by tagging the target files themselves, it seems inevitable we'll need an application or advance print dialog option that attaches job ticket metadata to get the behaviors we want/need.
The name of the option is still under debate. Here is Mike Sweet's comment on the default value of this print option, which of course is that color management is on:
The only change I would recommend is ... call it "normal" instead of "profiled". Not only is that more explicit about the intent (the normal mode) but you'll get fewer questions when users start playing with this new "expert" option they think will solve their current woe..
Edmund
-
Edmund, do you think Quartz/Colorsync/PDF print spooling is what's responsible for getting such close matches on my dinky consumer level Epson "All In One".
What's your take on that Apple Developer page I linked to several responses back.
What I don't understand is from where the color translation is being defined through this "Printer Manages Color" pipeline in getting that close of a match. When I see how easily third party apps try to implement their own color management with terrible results regardless of settings, it makes what I'm getting with the Epson seem like a miracle.
Does Apple's Quartz graphics communicate with the printer driver? I've tried using Apple/Epson driver supplied Gutenprint printer describers with very bad results.
Why is it so hard to describe colors when a graphics card frame buffer and electronics can determine the right voltage level to be sent to illuminate each RGB filtered pixel seen on a display? Why couldn't they derive a color description/translation language that way?
-
Does Apple's Quartz graphics communicate with the printer driver? I've tried using Apple/Epson driver supplied Gutenprint printer describers with very bad results.
Everything communicates with everything :)
As regards Gutenprint on the Mac at the moment, if you want high quality output, IMHO you really need to invest *a lot* of time in setup and profiling it, although the results can be worthwhile for people with expensive legacy printers. Some pro graphics arts guys with big legacy printers use it in production, with good results, but it is not intended at the moment to give professional results to naive users. On the other hand the Mac vendor drivers used with vendor media work very well out of the box.
Edmund