I am curious about what palette to use for what purpose. I know you are supposed to use CMYK palette when designing for separations printing processes, but on the other hand - you could use the RGB palette just as well, if you have a color calibrated system and a printer profile and if you leave a PDF to the printer, which I suppose most people do. It works if you set the color output to CMYK and use the printer ICC profile for conversion.
So, what is your choice regarding color models? It would be interesting to hear how you all work.
Hello there Shabbadang,It depends really on the assignment, and from time to time.I have different colours, my own palette of colours, so that even if I work with RGB it comes out as I like it when I cmyk it. But then of course, as long as I dont know the quality of the paper, or dont have a profile from my client or the printer (tryckeriet eller kunden), I go by instinct when colouring my illustrations I make for magazines and newspapers (Tabloid, morning newspaper or glossy magazines paper).If the client and myself set up a profile then of course I follow that specified colour profile, weather its cmyk, RGB or even PMS/Pantone.But 99% of the time I ask the client questions if necessary how they like to have it delivered. There are times, if not so often, but still, when the client ask for RGB.
Hej Stefan,
Your answer is a bit elusive ... But I try to understand it [:-)] Anyway, my question really boils down to me thinking the RGB palette is sort of easier to work with. The CMYK palette gets rahter dul when you turn color calibration (CM) on, while the RGB seem to retain a wider gamut (but that must be wrong, mustn't it?) so it's easier to find a color you like. The CMYK palette gets rather muddy, especially the darker greens, with CM turned on. So I'd rather use RGB, buth then again, you don't want to be too far off gamut.
>colors in standard palettes mathematically are the same, then they should print the same, but something makes them not to and I don't know why.
Variations in color engines, rendering intents, color profiles and default RIP internal conversion tables. To mention a few.
Your job is to eliminate all those variables by converting to CMYK in the application allowing A NON-COLOR MANAGED pre-press work flow to transfer your CMYK numbers along to the RIP and plate setter. This is done via postscript color management.
David Milisock said:Variations in color engines, rendering intents, color profiles and default RIP internal conversion tables. To mention a few.
Great, thank you for making me not going insane But why is this stuff so inaccurate?
I made a test with my Phaser 8550 solid ink Post script printer. I used the canned Xerox profile for this printer. Since solid ink does not blend with the paper, but rather forms a film on the surface of the paper, one can assume that the profile is correct and that paper does not play a big role here.
Anyway I made a few setups in Color Management module in Draw, each with the same printer profile, but with different rendering intents. I then brought a test file up that consists of the primaries in RGB and CMYK, all six colors in both color models.
Now the interesting part comes: I did some ink reading of all colors in all the four setups and I took notes of how each color would translate from RGB into CMYK. It made quite a table, but I won't publish it all here now unless someone is interested. What is interesting is not the differences between each rendering intent but that the RGB secondaries are so far out the window.
For example, and I take examples from the perceptual rendering intent: RGB Cyan (G255B255) was transformed to C57M0Y16K0! As you can imagine this is hardly what you would call cyan. And with the other rendering intents it was just about the same, the saturation RI, being a bit more saturated.
I have attached a screen dump of the test file with colors calibrated in Draw (I took dumps of all RI modes, but it seems you can only attach one file).
The readings for the other colors goes like this (perceptual RI): 255-0-255 (magenta): 38-79-0-0 255-255-0 (yellow): 13-0-86-0 255-0-0 (red): 0-95-98-0 0-255-0 (green): 65-0-100-0 0-0-255 (blue): 90-78-0-0
Now as you can see, the RGB primaries are doing a little better than the secondaries, with red doing the best (in saturation RI mode it was spot on 0-100-100-0). But generally the RGB colors are mapped to a color space smaller than CMYK! Guess what the RGB "yellow" looks like. Yes, a dull lime, rather than yellow.
I also made a test print shutting the printer profile off, and then RGB and CMYK colors printed exactly the same. Not as on the screen of course, but they print the same, as they should. Because nothing had been fiddling with the colors, they were sent directly to the printer. They were then printed with the largest color gamut the printer could produce. To me it seems logical that this should be the result even if a profile is used. Then RGB cyan should be mapped to C100, not 57-0-16-0, as is the case now.
Now, is this a case of color management using a bad printer profile or is this the way it is supposed to work?
>Great, thank you for making me not going insane But why is this stuff so inaccurate?
I'm going to offer some advice. I've been doing this since 1975, I 've watched the MAC come and go transforming itself into a music player and then into a phone.
Develop a relationship with your monitor and output devices, by that I mean understand the difference between what you see on the screen and what you see on the paper. Then output your work, make money and be happy.
The detailed analysis of this will drive you crazy and into bankruptcy.
The reason is that R255 G0 B0 - R0 G255 B0 - R0 G0 B255 correspond to nothing in CMYK so any conversion is subject to the software designer. Even the starting point since those RGB numbers mean nothing unless assigned to a specific color space. So there is no RGB CYAN, RGB magenta, RGB Yellow or RGB black.
In fact because of a near zero standardization in pigments the CMYK color space has mutated and has very little value in standardization except if you use SWOP, Euro or GRACOL standard pigments.
The best you can do is align your color management policies, use commercial profiles, keep a properly lit and colored work environment, use professional level graphic applications that support postscript and ICC color management and use proofing equipment that has some commercial certification for your region.
Would you think a custom built profile would give me a better result with this printer? If so, I would be happy to pay for that.
I simply can't get into my head why the RGB values aren't mapped to use the CMYK color space. I mean RGB is a larger color space to begin with, and then it's crazy that it should be mapped to an even smaller space than CMYK by the profile! I mean mapping G255B255 to anything other than C100 is a logic very hard for me to accept. If G255B255 was mapped to C100 it would be a logic I could happily accept, but not that it's mapped to 57-0-16-0. What do you think of that logic?
Sally Bode said:Actually there are some colors which cannot be mapped and there are no real good substitutes.
Well, all RGB colors must be mapped to something, and that's where the rendering intents come into play. But when the results are as bad as I described above I find it ridiculous. I mean when RGB cyan (G255B255) is mapped to something less than C100, then surely something must be wrong. RGB is the larger color space and thus shouldn't look like the lesser when printed. Well, it might be just this printer profile, I don't know. Cause when I print without applying the printer profile both RGB cyan and CMYK cyan look the same. Thus, the printer profile is actually worsening the output rather than improving it. Do you see what I mean?
Sally Bode said:I don't understand when these tools are available, that you want it to work differently?
I have no problem with the way CM works in Corel Draw. It is almost comprehensible compared to some other programs (no names) I've seen and used. It seems my hangup stems from the poor accuracy of some profiles I am using. And therefore I am asking some questions.
>I mean when RGB cyan (G255B255) is mapped to something less than C100, then surely something must be wrong.
Here is where you have a misunderstanding. If sRGB G255 B255 is mapped to C100 what do they map ProPhoto G255 B255 to? These are two different pure blues in RGB and what would you have them mapped to?
You're treating RGB colors as absolute and they are not.
David Milisock said:what do they map ProPhoto G255 B255 to?
I don't know what that is, but I suppose it's a larger RGB space than SRGB and I suppose it will have to be mapped to the same. I mean you are only working in one RGB space at the time, so why bother about the others? And how much could it differ? The inkreading figures I presented are way out as far as I can see anyway. Agree?
David Milisock said: You're treating RGB colors as absolute and they are not.
I'm not sure about that, I just think RGB should be mapped to make use of the printers whole gamut. Why less? I think it's ridiculous that a larger color space should be represented by an unnecessarily small color space. Well, I can just turn CM off and print the values uncalibrated and I will get the larger gamut, but then I will have no idea when looking on screen what they will look like as printed. Only that they will be as vivid as possible.
To me that is not what CM is about. It is about letting you know on screen what the printed matter will look like, not to alter the appearance of the printed matter. Agree?
>I mean you are only working in one RGB space at the time, so why bother about the others?
Unfortunately those who design color profiles have to figure out how their profile is going to handle each and every color space. That's why the same readings for Prophoto and sRGB that should produce in your opinion a true cyan do not. It can't or how would it distinguish between Prophoto and sRGB.
>I'm not sure about that, I just think RGB should be mapped to make use of the printers whole gamut. Why less ?
Look at it this way, CMYK is a finite gamut in which RGB gamuts have to be mapped. With your concept how does a CMYK device distinguish between two RGB gamuts of different size? When in reality the same RGB numbers display differently in two different color spaces so the CMYK renderings have to reflect those two very different colors.
>It is about letting you know on screen what the printed matter will look like, not to alter the appearance of the printed matter. Agree?
No. In 32 years of printing I have never seen a job on paper that looked like the monitor. Close but no cigar! Color management is a process of controls that allow us to manipulate the errors in all the current color technologies in a way that produces predictable results from desktop to print.
I have downloaded your Phaser driver, what a Charley Foxtrot!
First you can screw up the CMYK process in the driver settings. Second RGB in the office color is passed along in the postscript stream and we can assume that the conversion is guided by the dialog in the more options dialog.
In the press match regardless of the setting the proper CMYK numbers are being passed along so this would imply that a tone curve may be applied by changing the setting as the postscript stream passes through the engine.
To control any RGB to CMYK conversions one will have to do them in the application and live with the final result as there is no way to use a color profile with the printer.
I do not have the printer but those of you who do can use the different press match settings and create a solid CMYK color swatch and print it to the printer. Compare this print to a current process CMYK color guide. The larger the mismatch between the print and the guide the farther out your prints will be. Many hardware providers do not use standard commercial pigments. This is done to widen the standard CMYK color space. In my opinion this device is a poor choice for color managed digital workflows.