When you export a file to PDF for prepress the CYMK values do not stay correct. Try a spot color and check values in Corel, export to PDF prepress. Open in Photoshop or Paint and check values. They are no longer correct!! This works fine in X4 and makes X5 pretty useless for commercial printing.
I was having major color issues in X5 myself but seem to have solved them so I thought I would share:
I downloaded and installed the free Adobe Color Engine for Windows. (recommended by another user on this forum)
The rendering intents in CorelDraw don't seem to be working the way I thought they should work. I almost always used Absolute since it gave the most accrate color for commercial printing, but when I use it in X5, my whites don't stay white and go to gray or yellow depending on my color profiles selected.
Image of my X5 color settings that seem to be working like a charm:
The one function that is still MISSING is being able to export 8-bit Paletted JPEGs. This option has disappeared in X5s new .jpg Export Dialog.
Hi,
Using Adobe CMM over Microsoft ICM is pretty much a must at the moment on XP systems. ICM 2.0 on XP does not support v4 ICC color profiles which causes a lot of problems, inaccurate colors are the least of them. Using Adobe CMM on Vista or Windows 7 is less straightforward. The color conversion results performed by ICM/WCS vs Adobe CMM ( BPC off ) are almost identical in absolute majority of cases. Adobe CMM has its own very peculiar bugs - e.g. incorrect grayscale processing which forces us to use rathre slow workarounds internally, unstable color conversions to LAB. Still, using Adobe CMM is the ONLY way to bring Black Point Compensation functionality into X5 for those who needs it.X5 renders Absolute Colorimetric intent correctly. Anybody using Adobe apps has to be aware of one interesting twist in their UI - no matter what is selected in "Rendering Intent" control there the Absolute Colorimetric intent is used for real ONLY when "Show Paper White" or "Simulate Paper Color" boxes are checked, and they are unchecked by default. Effectively Adobe apps by default use Relative Colorimetric even though UI might say "Absolute". User-friendly UI at work.Technically Absolute Colorimetric Intent is indeed the most accurate. The fact that it takes into account white paper color makes it useless though for pretty much everything except color proofing. It might be important to see how your content will look like on the real paper, it is rare you want this "paper white" to be used for all white colors in your content..
As for the Perceptual vs Relative Colorimetric intents advice. While David has valid point about the effect Relative Colorimetric conversions might have on content with fine tonal variations another point is missed completely. Choice of rendering intent is not only gamut-specific, it is also content specific. Using Relative Colorimetric intent on fine art raster images might be as disastrous as using Perceptual intent on the vector-based document containing branding colors - Perceptual modifies everything, you can not really "pin" colors you need without resorting to spot inks. This is the main reason Relative Colorimetric intent is de facto industry standard and is used by default in all color managed applicaitons I am aware off, not only ones from Adobe. If you need to change it - fine, but you need to REALLY understand what you are doing, giving blanket advice is unlikely to do any good.
Funny thing you have mentioned 8-bit paletted JPEGs missing in X5... There is no such beast as 8-bit paletted JPEG, it was an UI bogus in X4 which has been finally cleaned in X5. Using 8-bit paletted JPEG option in X4 would first run image through palette dithering algorithm and then output image as regular 24-bit non-paletted RGB JPEG. Net result - much worse quality because of dithering and much bigger file size as dithering kills JPEG compression efficiency.
Gennady
First let me say that this s a great discussion and thatmy only complaint is that BPC breaks with the ICC rules. Now with that said I wil point this out and then will place some image up in future posts.
A large gamut like Prophoto is at least 70% bigger than any CMYK considering a fixed pixel, so when using BPC 70% of the pixels color is significantly changed while 30% is left unchanged. This IMO causes in some cases issues, it's like a 500LB person lsing 300 LBS in a year. Sure they're thinner but their skin is still too big so they look odd. An od way to explain it but there is no one way nor one correct to compress a large gamut to a small gamut.
Ok I have put about 30megs up on my FTP site, these are files handled as perceptual rendering and WCS and also as relative colorimetric with BPC onand the Adobe CMM.
If you're serious about this conversation e-mal me at davidmilisock@graphictechnology.com I'll send instructions.
Hi David,
OK, lets do it. I will contact you via email to get these test images and see what you are talking about.
I sent the stuff.
Took me a bit of time to come up with the detailed answer. I have read your article with Black Point Compensation (BPC) critique before, now I had a chance to look into test files you posted on FTP server. First, I have several rather serious issues with the arguments you use in your article. My biggest problem is that you are claiming Adobe BPC whitepaper to say things, and rather ridicoulous things at that, they never actually did say. Here is the link to your BPC post http://community.coreldraw.com/forums/t/19601.aspx, and here is the link to Adobe BPC whitepaper - http://www.color.org/AdobeBPC.pdf, probably the best existing technical explanation of BPC, for anybody who cares to read, check facts and make their own conclusions.
1) In your article you state
: After using a full search of the ICC ( International Color Consortium) specification document I have been unable to find any support for such a standard. So BPC is ONLY AN ADOBE THING!
Claiming that BPC is not an ICC thing is simply not correct. Please read this thread - http://lists.apple.com/archives/Colorsync-users/2009/Feb/msg00071.html. And if you are excited to see Graeme Gill, creator of Argyll CMS, to be against BPC - do not be too hasty. Graeme is very factual man, and he merely points to the fact that BPC, regardless of its merits, should be implemented in the ways that do not contradict ICC v2 spec. Nothing more, nothing less. Aa a creator of CMS he has an ideal way to address the problem directly, the black point mapping can be incorprated into LUT-based profiles generated by Argyll CMS. As a user, not CMS creator/profile maker, you can not do that.
It is not "ONLY AN ADOBE THING" - Lcms, Argyll, WCS - they all do have ways to address black points mismatch problem, by the way without resorting to particular Adobe BPC algorithm.
Waiting untill ICC comes up with some solution for black point problem does not help real users at all. Majority of color profiles out there are V2, and this is going to stay for quite long time.
2)
Well isn’t that dandy? Not only is BPC not supported by the ICC even Adobe admits that it should not be necessary
Adobe makes no such admissions, they do not need to. You are making quite a big leap concluding that as far as BPC is not required for Perceptual intent it is not required at all. You are completely ignoring Perceptual vs Relative Colorimetric intents usability issues, something that is pretty obvious for anybody knowing how these things really work.
3)
How about this for a silly option? Remove bad or malformed profiles from your system and stick with perceptual rendering and ICC standards? NAH! Why do that? Let’s create something that confuses the entire process even more then it already is!!!
You are either ignoring or not aware of the issues that surrounds use of Perceptual rendering intent with ICC color profiles. What BPC whitepaper means, and this is obvious for anybody who cares to read ICC specs and examine insides of exisiitng ICC color profiles, is that a lot of color profiles out there do not have Perceptual transform, period. By the way this does not even make them malformed profiles in all cases. Matrix based color profiles are by definition contain only colorimteric transform. You try to use Perceptual intent with them - there is none - your shadow areas get squished. In quite common situation when profile contains perfectly valid relative colorimertic transform and user's workflow dictates the use of Relative colorimetric intent Perceptual is simply not an option, the only way to salvage blacks is BPC. Removing bad or malformed profiles most often not an option either. First of all because not always these profiles are even "bad" or "malformed" in any way. Second - how end user is really supposed to replace them?
As for the test files on your FTP server - from my understadning they where intended to illustrate the point the Perceptual intent mapping produces identical results with Relative Colorimetric intent mapping with BPC, hence prooving, in your opinion, that BPC is completely unnecessary. David, this is a mute point, both BPC and Perceptual intents preserve black point and shadow areas, this is a reason why BPC simply not necessary on top of correctly performed Perceptual mapping, this is stated clearly in any BPC description. These test files do not address two vital points though, one of which I have already mentioned - Perceptual intent is not always awailable. The second point is that Perceptual intent is NOT the same thing as Relative Colorimertic with BPC, period. They more or less match in shadow, closer to pure black, areas. They do not match outside of shadow area. There are situations, and this is not governed merely by how different source and target gamut volumes are, where Perceptual intent is undesirable. Every time you advise of using Perceptual intent over default Relative Colorimetric one you choose to omit this point completely. Perceptual intent WILL shift even in-gamut colors, something that is unexpected/undesirable for way too many workflows. You are not even warning users about this outcome.
Picture is worth a thousand words, here are illustrations that hopefully will actually help to explain Perceptual vs Relative Colorimteric and Perceptual vs. Relative Colorimtertic with BPC issues.
And here are the same illustrations in original CDR format http://www.mediafire.com/file/wo5zql0nmyw/BlackPointCompensation.cdr
these issues are subtle and something might be lost in JPEG compression
First thanks for the time and the files. Second BPC is NOT ICC compliant and that's my only real gripe. Third perceptual does things one way and relative with BPC does things another slightly different. What makes either one wrong is the NON-ICC compliance.
Now with that said, I ask this question. When you read the description of relative colorimetric rendering, herein lies the problem. a) render all colors that are present in the image and are directly reproducible by the printer to the proper color and (b) render all colors that are outside the printer gamut to the nearest color on the edge of its gamut
How can this apply to a wide gamut image such as prophoto converted to a narrow CMYK like us web uncoated?
It can't 80% of the colors are clipped. So in comes Adobe with a suedo perceptul rendering, bastardize the Relative colorimetric rendering definition and making a NON-ICC COMPLIANT confusion.
Ok the RGB geometric shapes inside the rectangles do not match their CMYK counterparts. I'm playing with this.
It certainly looks at first or second glance that some near pur colors transform with less variation.
It looks like using default document of CMYK, Adobe RGB and a wider gamut CMYK color space has different reaults