Designer: best practice using colors?

[expressoaddict]

Hi,

 

having worked with vector packages from the early days of Corel Draw for Windows, I consider myself having quite a grasp of coloring, CMYK values, separation for print and whatnot.

 

But with Affinity Designer a problem is introduced that I have never encountered in any other vector app: The CMYK values seemingly being transformed using RGB color profiles and turning out something completely different from what I intended.

 

While in other packages exporting a 100% K renders just that: complete blackness, a 100% K surface from Affinity seems to result in a greyish almost-black (and if exporting to a bitmap format, 100%K transforms into 94%.)

 

This seems to be the case regardless of export format.

 

Is there any documentation for how to use color values in Affinity, and how (or why) conversion takes place?

Can it be turned off?

Or is the CMYK color model in Affinity Designer only there as a coarse guideline, translated internally to and from RGB even if my intended use is printing?

 

Any help and explanation greatly appreciated.

 

(Case in point: Yes, you could argue that 100%K on paper isn't as rich and totally black as K with some percentage of CMY — but being a vector app, I want to be able to design a logo with a BLACK element — to be printed with K only — then print it as vector in complete blackness while also exporting it to, say, a web page header, with the black element still being completely black. This seems, confusingly, impossible with Affinity Designer today. Am I right?)

[R C-R]

In Designer is your document set to use the CMYK color space? Are you exporting to a bitmap format that supports that color space? (For example, PNG does not.)

[expressoaddict]

In Designer is your document set to use the CMYK color space? Are you exporting to a bitmap format that supports that color space? (For example, PNG does not.)

 

 

Not sure about how this answers my question yet — but here goes:

 

The document is set to "print", and the color to CMYK/8

About color space, it doesn't matter what format I export to — 100%K turns into some lighter off-black, which I can't see why it should.

 

I'll try to explain what I mean:

 

100%K should turn into #000000 regardless of colorspace — from a (line art) designer standpoint, K is as black as can be and should be treated as such.

Again, designing line art using some "enhanced black" say, CMYK 222X, isn't a good idea due to the potential bleeding and misalignment that may follow.

 

It seems to me Designer lives in a photo world, forgetting that vector graphics, designed in CMYK for print, need no color space. They are what they are.

Is there any way to have Designer not handle colors at all?

[R C-R]

It seems to me Designer lives in a photo world, forgetting that vector graphics, designed in CMYK for print, need no color space. They are what they are.

I have no idea what you mean by that. Vector or raster, every digital graphics file has to be referenced to some color space to be rendered.

[Fixx]

Rendering happens for monitors. CMYK colour in vector object usually stays as it is though its appearance on screen may be altered by using colour profiled work flow. 

 

That is why CMYK objects can have slightly different look when printed to different materials or with different processes. Usually colour output is not fitted to different press processed. If company colour is C60Y100 it looks different on different materials. (Of course professional printer manages colour output to achieve maximum quality, but he does not really compensate material differences so much.)

 

Photographs and pixel art are fitted to processes using different conversion profiles for different devices.

 

OP, I have no answer for your question. What kind of work flow you have? Do you have any idea why any RGB profile mixup would be happening? Your document colour format is CMYK8, right?

[expressoaddict]

Rendering happens for monitors. CMYK colour in vector object usually stays as it is though its appearance on screen may be altered by using colour profiled work flow. 

 

...

 

OP, I have no answer for your question. What kind of work flow you have? Do you have any idea why any RGB profile mixup would be happening? Your document colour format is CMYK8, right?

 

Thank you for understanding my initial question.

 

Yes, this is what's odd — even printing a 100%K surface (to printer or to PDF) gives me a not-quite-black surface where it should. I can't really see why RGB conversion should be involved in the process at all here — especially of the color "completely black" which should be at the absolute end of any color model anyway. 

 

And the answer is yes — my color model is CMYK8. Which makes it even less understandable.

 

So how does everyone else do? I surely can't be the only one using CMYK colors in Affinity Designer...?

[R C-R]

Rendering happens for monitors.

Rendering also happens during printing, as a stage in a RIP or by the print driver. Color conversion between color spaces is necessary in any color managed document. Between an additive color space like RGB & a subtractive one like CMYK conversion can never be exact, but it would be impossible without some kind of color space reference.

[R C-R]

expressoaddict,

 

I created a very simple AD document (attached) using the CMYK/8 color space & the U.S. Web Coated (SWOP) v2 color profile. I drew a single rectangle in it, set to no fill & a stroke set to C=0, M=0, Y=0, & K=100 in the Color panel set to display CMYK sliders. (To keep things simple, the stroke is set to bevel join & inside alignment, with Force Pixel Alignment on.)

 

Exporting this to jpg with Pixel Format set to "Use document format," ICC profile set to "Use document profile," & embedded metadata & profile, results in a CMYK jpeg that when imported back into AD still shows C=0, M=0, Y=0, & K=100 for the stroke. The same thing happens exporting to TIFF using the TIFF CMYK preset.

 

I don't know what printer you are using or how you are measuring black values on the printed page, but when I print this out from any app I have it uses only black ink -- there is no C,M, or Y ink used.

 

Do you get something different?

test CMYK.afdesign

[expressoaddict]

Rendering also happens during printing, as a stage in a RIP or by the print driver. Color conversion between color spaces is necessary in any color managed document. Between an additive color space like RGB & a subtractive one like CMYK conversion can never be exact, but it would be impossible without some kind of color space reference.

 

I am sorry, but are you responding to my question or to one that you would like me to have asked instead?

 

I am designing things in CMYK. When ripping such graphics to a CMYK printer no conversion shall take place.

That's the beauty of vector graphics — and the difference to bitmap/raster — if working in CMYK I set the values to be printed and that's it.

 

Color conversion may take place for display onscreen (which is RGB) but that is totally different from the ripping process.

If I have a number of CMYK objects, as in Affinity Designer, they shall be ripped/printed/separated as per my settings, period.

If I also add an RGB photo to my design then by all means, it — and only it — need be converted at the time of rip/printing. 

But not the rest.

 

It is true that no color conversion can be exact.

That is why none should take place, when I design a CYMK object and print it as such.

 

My question, to clarify, is: Why does it?

And: When conversion does take place, why is it off, so that 100%K — the blackest — isn't rendered as RGB(0,0,0) ?

[MikeW]

I am pretty much at a complete loss as to understanding this thread. I mean, is it about 100% K hitting the print device? Or that 100% K should map to 0,0,0 if exported to an RGB format? Both? And what is the OS being used? What is the print device used?

 

How is the 100% K being inspected once it has been sent to a print device? Or is the print version hitting a PDF first and the PDF being printed? In any case, I never print direct, I always go to PDF and 100% K will hit the PDF as 100% K unless there is a profile to profile conversion. As will any other as-designed CMYK object--it will hit the PDF in the CMYK colors I use in the design.

[expressoaddict]

I am pretty much at a complete loss as to understanding this thread. I mean, is it about 100% K hitting the print device? Or that 100% K should map to 0,0,0 if exported to an RGB format? Both? And what is the OS being used? What is the print device used?

 

Both, in fact. Printing a 100%K object, either direct or from a PDF, gives me a weak, weak raster — I guess corresponding quite well to the 94% I see if exporting to RGB. So one could also say that the only way for me to print full black is to set RGB(0,0,0) and not 100% K.

 

I'm on MacOS Sierra, printing to two different Laser printers, one Samsung and one HP.

 

So I think you're understanding my question perfectly — I would so dearly like my CMYK objects to print at the CMYK values I set...  :)

 

 

 

100% K will hit the PDF as 100% K unless there is a profile to profile conversion. 

 

So — you can choose a conversion? Is there a way to just turn it off? Or what am I not doing the way you are?

[expressoaddict]

Perhaps at the risk of becoming crazy here... 

 

If I add an object, set the color picker to CMYK, make the object 100%K — then right there in the document what I get is an almost-black object.

If I then change the color picker to RGB, it will change not to (0, 0, 0) but to (35, 31, 32).

 

So quite obviously, Affinity Designer has decided that 100%K is a greyish color — which is also the way the object prints.

 

I don't think I can explain it any clearer — all I do is wonder why something I set to a CMYK value won't print with those values.

[MikeW]

Make an object 100% k. Export to pdf. Upload the pdf.

[R C-R]

I am designing things in CMYK. When ripping such graphics to a CMYK printer no conversion shall take place.

That's the beauty of vector graphics — and the difference to bitmap/raster — if working in CMYK I set the values to be printed and that's it.

??? Vector or raster makes no difference in this respect. Everything still has to be handed off to the printing software & rasterized to be printed by a laser or inkjet printing device. In particular, a typical home/office class color laser printer has four toner cartridges, one each for cyan, magenta, yellow, & black, while an inkjet might have three or more color ink cartridges, plus two black ones, one used in combination with the colored inks for better color mixing & the other used for 'pure' 100% K blacks.

 

The printing software takes into account the properties of the paper or other print media & how that interacts with the inks or toners, which is determined in part by the color profile specified for the document. On a Mac, depending on the installed printer driver, this can be set in the "Color Matching" section of the print dialog to either use the built-in Colorsync matching or the printer's color management system, & the "Quality & Media" & "Color Options" sections can be used to set it for various media types, color levels, & printing quality.

 

Together, all these things determine the colors of the printed output, including how black the printed blacks will be.

[expressoaddict]

??? Vector or raster makes no difference in this respect. Everything still has to be handed off to the printing software & rasterized to be printed by a laser or inkjet printing device. In particular, a typical home/office class color laser printer has four toner cartridges, one each for cyan, magenta, yellow, & black, while an inkjet might have three or more color ink cartridges, plus two black ones, one used in combination with the colored inks for better color mixing & the other used for 'pure' 100% K blacks.

 

The printing software takes into account the properties of the paper or other print media & how that interacts with the inks or toners, which is determined in part by the color profile specified for the document. On a Mac, depending on the installed printer driver, this can be set in the "Color Matching" section of the print dialog to either use the built-in Colorsync matching or the printer's color management system, & the "Quality & Media" & "Color Options" sections can be used to set it for various media types, color levels, & printing quality.

 

Together, all these things determine the colors of the printed output, including how black the printed blacks will be.

 

Let me just close this topic by stating that if I have purchased a vector design package that does not print the same CMYK values to a CMYK printer that I have set the artwork to be, then I am the fool for thinking an app for forty bucks could do a professional job.

 

I don't want to be rude — I have just read your bio and realize that you are not a graphics professional — but the information in your post above makes no sense at all from a professional standpoint, nor are your deductions about color handling correct. 

I could go back to the early days of manual color separation, when we printed four sheets of black-and-white film at the very expensive typesetter service, then exposed them onto plates, which in turn were used for offset printing onto paper. Those four sheets were the respective originals for the C M Y and K printing colors, which meant that if I gave an object a certain mix of these components, each film would represent that mix in a literal, one-to-one ratio. If my color was 20C, 30M, 40Y, 10K, then the cyan film would be 20% grey, the magenta 30% etc. 

 

This, quite simply, is how CMYK printing works. 

 

So. Designing in CMYK and printing to CMYK, I don't want any conversion to take place.

If I want my blacks to be 100%K, I design my artwork accordingly. If I want something else, then that's the value I'll set.

But I alone decide how black my blacks will be.

 

In case your answer is to be considered an official contribution to this forum, I guess I'll have to go back to using apps like InkScape which, while crazily inferior in features and UI, has never once let me down in terms of printing and designing in CMYK.

[MikeW]

Upload a PDF that fails. I get the exact cmyk values in my pdfs that I specify.

[A_B_C]

Hmm … could it be that you are talking about sending your files to an office or home printer, expressoaddict? :unsure:

 

I'm on MacOS Sierra, printing to two different Laser printers, one Samsung and one HP.

 

In that case, I can confirm that a shape set to CMYK 0/0/0/100 gets slightly rasterised on my Samsung mono-colour laser printer, as long as the document is CMYK. However, when the document is RGB and I create a shape set to RGB 0/0/0, the printer output will be pitch-black without any rasterisation.

 

As is well known, most regular office or home inkjet printers expect RGB files, and from my experience, the same is the case with my Samsung device (I never went through the trouble of actually reading the documentation, since I use it only for notes and office correspondence). If you send such printers a CMYK file, they will usually convert it to RGB, and then back to whatever flavour of CMYK they use for printing. To be sure, all that depends on the printer drivers, settings, color profiles used, specific printer etc. etc.

 

Just another point to consider …  :)

Alex

[R C-R]

... the information in your post above makes no sense at all from a professional standpoint, nor are your deductions about color handling correct.

Please refer to Apple's Technical Note TN2035, ColorSync on Mac OS X, particularly the Color Management in Printing section. I am not "deducing" anything, just summarizing the information about color management in OS X presented there.

 

Note in particular what it says in the Print Dialog section about the 'advanced' options. You cannot avoid conversion, only choose what method is used.

[Fixx]

This is about the same problem that occurred in InDesign 2, black was rendered to grey in export. That is why there is now a preference named "Appearance of black".

[AlainP]

I am quite sure that CMYK color works as it should in AD. You will never get the same colors for RGB to CMYK and vice versa. I worked many years with Photoshop and a CMYK 100% Black is never a "pure deep black", it renders exactly as AD does. A "true Black" is something like " C75 M68 Y67 K90", but there are many "recipies". C0 M0 Y0 K100 is usually used for text printing over a background.

 

There is a short article on Blurp site that explains this: https://support.blurb.com/hc/en-us/articles/207792816-CMYK-black-values

and if you can also "google" for "true black CMYK in PS".

[R C-R]

This is about the same problem that occurred in InDesign 2, black was rendered to grey in export. That is why there is now a preference named "Appearance of black".

One way or another, it is all about the Color Management System (CMS) in use & how applications & users interact with it. There is no way to prevent conversions from occurring, no way to avoid the complexities of the process or the need for it. There are dozens of articles about this on the web, for example this Wikipedia article or this three part one from Cambridge In Colour.

 

This article claims the "color-managed workflow is fairly straightforward" but I am not so sure I agree with that. Abstract mathematical concepts like a Profile Connection Space (PCS) are not that easy to visualize. It does not help that the complexities of human vision -- different sense receptors for color & luminance at the physiological level & the incompletely understood process of interpreting that sense information at the psychological level -- is notoriously difficult to model accurately. What our brains tell us we see is strongly dependent on the intensity & color spectrum of the light illuminating it & narrow spectrum sources like RGB monitors trick us into seeing colors that are not actually there. Additive/transmissive & subtractive/reflective color models are fundamentally different. "Pure black" is the absence of light, so everything is pure black if no light strikes it or none is reflected from it. There are no pure black inks or toner powders. Advances in materials science have made possible things like Vantablack; in comparison to that every printed black is a shade of grey.

 

I hope this does not strike anyone as too far off topic or irrelevant. My intent is only to point out that this is not as simple a topic as it may seem.

[F_Kal]

By no means am I an expert, but I'll try and summarize everything being said here and give some further suggestions regarding color sliders!

 

What is expected?

Let us agree that 

1) if you work on a CMYK document, and choose via the CMYK sliders a CMYK value (eg. 0,0,0,100) and then save that document as a CMYK file, the file should contain the precise CMYK values you handpicked. 

2) if you print a CMYK file with pure colors (eg cyan:100,0,0,0 or text-black: 0,0,0,100) and the printer treats it at face value, the pure colors should appear... pure with no halftoning.

3) The printer will decide on its own how it will print the CMYK values it gets though (some home printers will convert it to RGB first and the back to some different CMYK value if you are unlucky).

4) if unintentionally someplace in the creation process you switch to RGB, then some conversion will happen. RGB 0,0,0 is translated into CMYK 78,68,58,94 on Photoshop. It is translates to CMYK 72,68,67,88 on Affinity Designer. But this is because there is conversion from RGB to CMYK and conversion is something subjective so both pieces of software make a guess about what color this would be (in particular when there isn't an absolute RGB colorspace defined such as in the case when you are working on a CMYK document).

 

What works - can you reproduce this?

I've created a CMYK document in AD, created a rectangle, entered on the CMYK (color) slider 100,100,100,100,  exported it as a PDF and imported it in InDesign. InDesign correctly reports a 400% ink coverage with 100% on each channel. I don't see a problem here. If you have a problem thus far, you've stumbled upon some bug that is not affecting everybody. Keep reading to determine if there is no omission on your part or an actual bug. 

 

What could be wrong if the color values inside the PDF file differ?

If you use some RGB colorspace anywhere this imposes conversions and probably is the cause of your problems. Any of the following could be the culprit:

1) upon creation you chose a document type other than CMYK

2) you exported the file in some RGB colorspace

3) (this is a funny one, very annoying) you used the RGB (color) Hex sliders and/or the RGB (color) sliders(!) to adjust your color. You manually set a 100,100,100,100 CMYK value and then switched to the RGB or HEX sliders where it appears as 0,0,0/#000000. You think that you didn't change anything but when you go back to the CMYK sliders you realized that now the colors are 72,68,67,88! By using the hex/RGB sliders you were playing in the RGB field and there you are bound to have some conversions happen. Annoying, but easy to avoid if you keep it in mind (Photoshop suffers from that too)

 

What could be wrong if the color values inside the PDF are correct, but the printed colors are obviously different "than expected"?

Apparently one can not really expect the same colors on his RGB monitor and his CMYK print (unless monitor & printer are profiled, and you have a Soft Proofing layer for your paper type in affinity). Having said that pure colors should be pure and rich black should be deep (deeper than pure black) if this doesn't happen it apparently is the printer or the printer-driver's decision to render the color differently than our expectations. There may (or may not) be some way to force the printer to print it differently, but I wouldn't think it has to do anything with Affinity (maybe a different filetype or some PDF flags could force the driver to treat the file differently, but I have no idea)

 

hope it helps!