Do you think it's asking too much for Xara to properly interpret CMYK files?
I get annoyed when I have to open Photoshop constantly to convert CMYK to RGB and output from Xara back to CMYK again. Seems kind of redundant to me.
That's a feature I'd like to see added to the next version.
Also the waiting business for the next version. I'd much rather have an occasional service patch for Xara with added features than wait 2 or 3 years for next major update.
Do you think it's asking too much for Xara to properly interpret CMYK files?
I get annoyed when I have to open Photoshop constantly to convert CMYK to RGB and output from Xara back to CMYK again. Seems kind of redundant to me.
That's a feature I'd like to see added to the next version.
Also the waiting business for the next version. I'd much rather have an occasional service patch for Xara with added features than wait 2 or 3 years for next major update.
you'll find a nice utility named "xPort" from sean Sedwards at the XaraXone Shareware page. Scroll down to appr. the middle of the page, right unter xPal.
This one does the trick for me when you set the Mode to "Plug-In"
...the only thing you should do with a CMYK file is print it: CMYK is an output format. There is no single CMYK to RGB conversion algorithm (nor RGB to CMYK) because CMYK are ink colours and the results depend on exactly what inks and paper are being used. Also, proper RGB to CMYK conversion is not reversible because there can be more than one RGB value for every CMYK. Even PhotoShop struggles with this; if you convert RGB - > CMYK -> RGB you'll find that the first and last don't match by a significant degree.
OTOH, X could import CMYK TIFFs which could be used as-is on the page (and maybe separated). The on-screen appearance would be an approximation but any output (e.g. EPS, TIFF) would contain the original CMYK values. X might also export CMYK TIFFs from vector drawings where the colours have been defined as such. There would be limitations because many of X's effects (transparency etc.) are based on RGB.
Performing a professional quality RGB to CMYK conversion would require duplicating all the options in PhotoShop and is probably a feature too far. X has a tolerable RGB to CMYK conversion (which you can access via my x-Port CMYK plug-in in 'Host' mode) and that could also be improved and made more accessible.
When I was working on my "Moms Angel" project within PhotoPaint, the gown color was this nice toned down mauve purple color, when I exported it as a .GIF it exported into this brighter violet color, then when I imported it in to XaraX to begin work on it, I turned on "show print colors' and it turned into this pinkish color, not even a purple tone in by my standards. This is really strange to me.
Seems that the conversion from 24 bit to 8 bit in PhotoPaint, in order to export as a transparent GIF, may not have included the 'mauve' color that I had chosen from the 24 bit palette as opposed to the 8 bit palette, so it compinsated, of course, but the exported color and the printer color within XaraX are really off base.
Any help in understanding this mess??? Anyway to fix it within XaraX???
There are several algorithms to convert from 24 to 8 bit colour and they don't all work by using the 256 most popular colours from the original. Hence you can't guarantee that any of the original colours will be present. OTOH, the 8 bit version should at least appear the same as the original, so I'm not sure what's happened here. I'd recommend you export at 24 bits, otherwise double check the conversion options. Maybe the transparency is confusing it.
X's 'Show Printer Colours' actually means 'Show the artwork as it might look if it was sent directly to a professional printer without CMYK compensation'. It's only an approximation (hence the odd colour shift) and it doesn't tell you anything about how your artwork will look when it's printed on a desktop printer or sent to a print bureau who will perform the CMYK conversion. Show Printer Colours is really only useful if you're working with Pantone or other CMYK colours on the page.
Well, just out of curiosity I went into PhotoPaint, did a little playing around. I took the image/painting into the various higher modes ( Image/Mode/Lab (24-bit), CMYK (24-bit), RGB Color (48-bit) then back to RGB Color (24-bit)) then I tried exporting it as a BMP, TIFF and GIF (transparent background)........Guess what?? All 3 exported with the color of the first swatch. So it makes me curious if I should work in CMYK or Lab or a higher RGB THEN export it in a lower one. It seemed to 'fix' the glitch.
I never tried this, but I DID try exporting the piece as a BMP, a TIFF and a GIF (transparent) before but just from 24-bit to 8-bit. But doing this extra transforming then back to the original 24-bit seemed to put it right. Doesn't sound quite right but this is all I can think of as the reason it actually worked.
There are allot of glitches in this release of PP10 so I don't doubt that it may be one of the bugs.
Thanks for your help, much appreciated. If you have any thing to add to my comments please, I'm all ears.
I still can't explain what's happening in PhotoPaint, but it makes sense to work at the highest quality level until you have to export to the web or whatever. If your output is not to the web, don't reduce the quality. 24 bit RGB should be sufficient and is the maximum that X can work at, as well as being the maximum quality of most printers. 48 bit RGB would only be an advantage if PhotoPaint can apply 48 bit effects. If the 48 bit format is just an export option then it's of no benefit.
As I mentioned above, CMYK is an export format. Unless your colours are defined in terms of printing inks or your next step is to send your artwork to a professional printer, you should avoid working in CMYK mode.
Reply With Quote
Bookmarks