Jump to content

Recommended Posts

Posted

According to conversion charts like this; https://www.rapidtables.com/convert/color/cmyk-to-rgb.html CMYK black should convert to RGB black, and CMYK white converts to RGB white.

For example; CMYK 0/0/0/100 = RGB 0/0/0 (Black)

However, if you open the Publisher colour chooser and play around with the sliders, you'll see it doesn't do the conversions like this. Here's what Publisher does;

Selecting CMYK 0/0/0/100 on the CMYK sliders gives you RGB 35/31/32 (Some sort of dark grey??)

Selecting RGB 0/0/0 on the RGB sliders gives you CMYK 72/68/67/88 (Some variation of rich black??)

And here's the funny thing. If you select CMYK 0/0/0/100 on the CMYK sliders, switch over to the RGB sliders (which read 35/31/32) and just *touch* one of the values without even changing it, the CMYK values suddenly flip over to CMYK 68/67/65/74 ! Where'd that number come from? This seems a bit buggy to me.

Is there any way to tell Publisher to use the normal RGB->CMYK conversions, i.e. RGB 0/0/0 -> CMYK 0/0/0/100; This would make life much easier when switching colorspace from RGB to CMYK for sending to a commercial printers, for example. As it is, I have to manually go through the document, select all the black text, and change the colour to CMYK 0/0/0/100

 

Posted (edited)
4 hours ago, lacerto said:

Yes, you're right, the kinds of smart basic colors like [Black] in InDesign are not supported in Publisher, so what you get when making a CMYK<->RGB conversion is a conversion between the document color profiles (the latent one initially being determined by the setting you have in Edit > Preferences > Color).

Thanks for the reply, and for welcoming me to the forums.

Even if this behaviour isn't a bug, it's certainly an inconsistency in the interface of the Colour Chooser. I tried a few more combinations using Colour Chooser, basically selecting a value using the sliders in the RGB screen, and then checking to see what corresponding CMYK values I'm getting. Here I've created an RGB/8 (sRGB) document

Let's start with the colours that give CMYK its name;

RGB 0/255/255 (Cyan) -> CMYK 52/0/13/0 - should be 100/0/0/0

RGB 255/0/255 (Magenta) -> CMYK 27/82/0/0 - should be 0/100/0/0

RGB 255/255/0 (Yellow) -> CMYK 6/0/96/0 - SO CLOSE!

RGB 0/0/0 (Black) -> CMYK 72/68/67/88 - should be 0/0/0/100

Now onto the other basic colours;

RGB 255/255/255 (White) -> CMYK 0/0/0/0 - CORRECT!

RGB 255/0/0 (Red) -> CMYK 0/100/100/0 - CORRECT!

RGB 0/255/0 (Green) -> CMYK 62/0/100/0 - should be 100/0/100/0

RGB 0/0/255 (Blue) -> CMYK 88/77/0/0 - should be 100/100/0/0

Why is this issue important? - Because for commercial printing you're using some combination of four plates; Cyan, Magenta, Yellow and Black. If I'm in a CMYK colour space document, and I want to pick 'Yellow' for a block of text. I open up Colour Chooser but I'm on the RGB slider panel so I select 255/255/0 (That's yellow, right?) - My text changes to yellow, I produce my PDF and send it to the printers. But the colour separation isn't giving me a 100% yellow plate for my text, it'll give me 96% Yellow, with a 6% Cyan plate - how'd that get in there?

On the other hand, I want to change some text to Red - I quickly select 255/0/0 on the RGB slider, it maps to 0/100/100/0, and at the printers I've got a 100% Magenta and a 100% Yellow plate. Everybody's happy!

And here's the worst part. I have a load of text I want to print in Black. It's important that it only uses the Black plate at the printers, since I don't want to get blurred text by 4 plates not aligning. I know that pure Black will use only the K plate. I select my text, open up the Colour Chooser and pick RGB 0/0/0, that's black, right????....

Wrong.... It gets to the printers, my 'Black' is actually CMYK 72/68/67/88, resulting in 4 plates being used to print my text. And a blurry mess. I wouldn't want to be creating a 300 page book in Publisher and accidentally select RGB Black.

Arguably I should stay away from the RGB sliders when working in the CMYK colour space, and I can understand why this conversion between colour spaces has to happen Also, the other colours I tested aren't as important as Black. But Black is the important one; Does RGB Black really map to different CMYK values depending on the profile? How about a preferences checkbox that says something like 'Do direct RGB -> CMYK mapping in colour chooser' to at least map the 8 basic RGB colours directly to the CMYK equivalent?

Edited by jhonan
Fixed RGB value
Posted
33 minutes ago, jhonan said:

And here's the worst part. I have a load of text I want to print in Black. It's important that it only uses the Black plate at the printers, since I don't want to get blurred text by 4 plates not aligning. I know that pure Black will use only the K plate. I select my text, open up the Colour Chooser and pick RGB 0/0/0, that's black, right????....

No, RGB 0/0/0 is visually black but doesn't mean CMYK 0/0/0/100. Since RGB and CMYK are different color spaces it needs conversion, that is where the color profile matters and rules. (compare: 1 litre = 1 kg only for some liquids, e.g. water (at a certain temperature))

Aside the required conversion, note that a visual black (≠ 100 K) in CMYK can get achieved with several settings, for instance you can use more K and less CMY or do it vice versa and use more CMY and less K. This is what is called UCR vs GCR, an option which is not available yet in Affinity. Additionally the printing ink K is not a neutral, "colorless" ink but for instance in Europe ("Euroscale" DIN 12647-2) may appear yellowish while K ink in Japan looks rather blueish. That is why a so called "Rich Black" in Europe often gets set with more Cyan than Yellow, to compensate the brown tint of the black ink.

53 minutes ago, jhonan said:

Does RGB Black really map to different CMYK values depending on the profile? How about a preferences checkbox that says something like 'Do direct RGB -> CMYK mapping in colour chooser' to at least map the 8 basic RGB colours directly to the CMYK equivalent?

Correct, colour profiles influence colours, accordingly changing a profile, too. So if you started a CMYK document in profile A and then your printer requires profile B you better don't simply choose this profile in the export dialog window but switch before in your Affinity document: There you have the option to press the "Assign" button before confirming with "Okay". That way you can avoid conversion of colour numbers in your palette – but accordingly may get a different appearance on screen.

Unfortunately Affinity still lacks in the export option to maintain colour swatch numbers, for instance as used in a logo of a corporate design to get printed in 100 Cyan instead of a converted mixture. This article describes the problem and a possible solution for InDesign with its option to "preserve numbers".

In Affinity it is confusing quite a few users and did cause several related topics in the Affinity forums, for instance …

• MacBookPro Retina 15" |  macOS 10.14.6  | Eizo 27" | Affinity V1  
• iPad 10.Gen.  |  iOS 18.5.  |  Affinity V2.6

Posted
17 minutes ago, lacerto said:

To be precise, Affinity apps cannot do this when they convert from one CMYK profile to another

To me the "Assign" button appears to work that way: Swatch numbers of CMYK swatches are maintained + stay assigned to objects, while raster image colours do change with the conversion.

– Compare also:

 

• MacBookPro Retina 15" |  macOS 10.14.6  | Eizo 27" | Affinity V1  
• iPad 10.Gen.  |  iOS 18.5.  |  Affinity V2.6

Posted

Thanks for all the replies, they're very helpful.

I'd like to narrow this down to one simple issue; If I'm sending body text to a commercial printer, I want it to appear as 100%K 0/0/0/100 even if I switch profiles.

When I create a CMYK document from scratch, everything works as it should.

"File / New / Press Ready / A5" Gives me a CMYK/8 US Web Coated SWOP v2 document.

If I create a Frame Text Tool or Artistic Text Tool it defaults to 100%K, great!

But, I realise I've selected the wrong colour profile so I click on 'Document Setup' and pick Color Profile 'Coated FOGRA27 with 'Convert' selected, and click OK

Oh no! - My nice 100%K text has now been converted over to some 71/71/65/77 'Rich Black' value! :(

I'm fine with illustrations or blocks of black converting over, since black in that context might appear better as a rich black. But I certainly don't want my text going to the printers as anything other than 100%K - I want my printers to use the K plate only.

And now, I can't revert that change! - If I change back to the US Web Coated SWOP v2 profile, what was originally 100%K text now becomes 67/68/66/75

Which means that if I pick a CMYK profile when I create a document, I need to remember not to change the profile at any point or I'll lose my 100%K text. I'm not sure what I'd do if the printer comes back to me and asks for a different profile? - Do I click 'assign' instead of 'convert' in that case?

Posted
7 minutes ago, jhonan said:

But, I realise I've selected the wrong colour profile so I click on 'Document Setup' and pick Color Profile 'Coated FOGRA27 with 'Convert' selected, and click OK

So, why not pick Assign instead?

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
    Laptop 2: Windows 11 Pro 24H2,  16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU
iPad:  iPad Pro M1, 12.9": iPadOS 18.5, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.4

Posted (edited)
49 minutes ago, walt.farrell said:

So, why not pick Assign instead?

Yes, I think that's what I need to do.

I must admit to not fully understanding how Colour Profiles are used by the printers and why they're important during document creation. But that's the subject of another investigation!

Edited by jhonan
Posted
1 hour ago, jhonan said:

And now, I can't revert that change!

By the way: if you use saved text styles, it may be easy to update and re-define their text colour to 0/0/0/100 at any time.

Also, the Find and Replace Panel gives you the option to let it search for a certain text colour and replace with the desired colour it in all text in your entire document without the need to use the 'find' / 'replace' fields. (regardless of saved text styles)

476422602_FindReplaceformat.jpg.9c1ddc632eae895c26f95932f7d96949.jpg

360812030_FindReplacecolour.jpg.4f2aeb07cd78ddf1c512ceea28538c47.jpg

• MacBookPro Retina 15" |  macOS 10.14.6  | Eizo 27" | Affinity V1  
• iPad 10.Gen.  |  iOS 18.5.  |  Affinity V2.6

Posted
11 minutes ago, lacerto said:

(...) when you convert and you have swatch assignments, their links are broken (...)

So it appears that there is a clear bug in handling post-conversion swatch assignments.

Yes. But swatch handling in Affinity is special anyway. I'd say it is worth a separate topic. I am sure, it was reported several times before, – last but not least with the swatch ignorance issue when objects get copied between documents, even if they are global swatches in documents which have the same colour profile assigned. In various situations palette swatches in Affinity are forced by the app to be kind of useless – aside colour conversion issues.

• MacBookPro Retina 15" |  macOS 10.14.6  | Eizo 27" | Affinity V1  
• iPad 10.Gen.  |  iOS 18.5.  |  Affinity V2.6

Posted
34 minutes ago, lacerto said:

You cannot just reassign the profile in situations like this, but must convert. And then change "inadvertently" converted K100 back from rich black to K100. You can often facilitate that with styles, or Find / Replace formatting, but just supporting [Black] in the style of InDesign would make such operations unnecessary.

Even a 'Retain K100 text' checkbox in the assign/convert dialog would be a big help. Basically convert all the colours except any Frame Text or Artistic Text objects set to K100

Posted
1 hour ago, lacerto said:

Yet another point worth a note is that if there is an image with adjustments (even when the image is an sRGB bitmap), changing a color profile [whether by assign or convert; and disregarding if conversion is done by using File > Document Setup, or at export time] will not cause a resolved image color values to be recalculated to fit into the max TIC of the destination CMYK profile, not even when using export methods like PDF/X-1a, which causes all color values to be flattened and converted to final target CMYK values. To achieve TIC of the target profile, the image needs to be rasterized with its adjustments before exporting.

Who is the colour profile benefiting, as in, who uses it? - My understanding is that you set it during document production to make sure that your ink coverage % is within the correct limits for the selected stock, and that your on-screen colors match the final output as closely as possible (i.e. you're working in the same gamut range as the final printed output) - The reason we select CMYK profiles is because professional printers use a 4-colour process.

A PDF can be a mixture of CMYK and RGB elements for example (I don't even think the selected profile is stored in the PDF file) - Does the printing company read the profile or even care about it, or do they just take the PDF file as-is and work with it from there, creating the separations etc?

Theoretically, if I'm happy with a RGB colourspace document, I could output to PDF, send it to the printers and say 'print this' - The colour matching might be all over the place and out of gamut, and I might end up with holes in the page, but me telling the printing company what RGB profile I used won't stop that from happening! (Please correct me if I'm wrong about this)

Posted
4 minutes ago, BofG said:

Just to give you some context, an introductory level of book on this topic will run to at least a hundred+ pages. You aren't going to learn it from a few forum posts (although lacerto's posts are very good!).

Yeah, I thought I'd take advantage and try to learn a few things. Unfortunately I have very little experience in this area, as you can probably tell. But feel free to ask me any questions about Data Analytics, I've got about 30 years experience in that! 🤣

Posted
3 hours ago, jhonan said:

Yeah, I thought I'd take advantage and try to learn a few things. Unfortunately I have very little experience in this area, as you can probably tell.

As a start you might take a look on this Affinity article: https://affinityspotlight.com/article/display-colour-management-in-the-affinity-apps/

Or a view from the other, the printer's end: https://www.heidelberg.com/global/media/en/global_media/products___prinect/products___prinect_topics/pdf_1/color_quality.pdf

• MacBookPro Retina 15" |  macOS 10.14.6  | Eizo 27" | Affinity V1  
• iPad 10.Gen.  |  iOS 18.5.  |  Affinity V2.6

Posted
3 hours ago, lacerto said:

But the field is pretty large and complex and needs are highly varied so the views mentioned above might be quite irrelevant to many that use Affinity apps to get their ideas and creations produced.

That's a pretty impressive reply, thanks for taking the time to explain all that.

There are some attempts at pre-press functionality in Publisher (like the pre-flight section) which are fine for basic checks before sending to pre-press, but not powerful enough to provide all the checking and processing that a dedicated pre-press application provides. I took a look at the Packzview videos and it's insane! - So that seems like a grey area; where does the responsibility of the graphic designer end, and the pre-press person begin?

The graphic designer should at least send a 'printable' document to pre-press, but they might not necessarily have checked every single aspect of it. But on the other hand, you don't want the document going backwards and forwards between pre-press and the designer ad nauseum.

Affinity offers simplicity and guides you in a way that prevents errors (which I prefer, personally). But any errors that do creep in are then left to pre-press to discover and sort out.

Posted
2 hours ago, thomaso said:

I got about half-way through that document before I realised I'm going down another rabbit hole! The level of complexity behind the 4-colour process is crazy. Even the section on half tone dots was new to me. It just never occurred to me that CMYK percentages eventually end up as half tone dots like that.

Posted
52 minutes ago, jhonan said:

It just never occurred to me that CMYK percentages eventually end up as half tone dots like that.

Didn't you wonder that there is no ink for green? Here is a nice gallery of some enlarged details of raster prints: https://de.wikipedia.org/wiki/Druckraster#/media/Datei:Cyan-verlauf.jpg

Today designers don't need to understand or consider all of these aspects of the printing process. But an idea of the problems involved in the transition from digital to analog helps to understand the importance of color management. Before DTP, designers couldn't even be bothered with it; until the end of the 20th century, pre-press still had separate professions for typesetting, lithography (colours & images), and print film production.

This also touches your question about responsibilty. Today, different to the purely analog processes, there is no clear boundary but rather a matter of information, communication and agreement. The question gets more difficult if a print result fails. Then it can be hard to judge whose fault it was since both sides can or want to feel save with their experiences which "never" failed before.

That is why often a (paid) proof print gets produced by the printer. On a different machine, seldom on the final paper but with the final details. Then it is up the client to detect errors – and either ask the printer to fix it in their pre-press or deliver a new file. For large companies / print jobs then a second proof can be usual. – Some printer workflows offer digital proofs (PDF) only which at least show how the designers file made it through the printers pre-press. – Online printing services usually do not offer proofs but display a small preview only after the file was uploaded, especially if the pre-press process is fully automated.

• MacBookPro Retina 15" |  macOS 10.14.6  | Eizo 27" | Affinity V1  
• iPad 10.Gen.  |  iOS 18.5.  |  Affinity V2.6

  • 2 years later...
Posted (edited)
On 6/8/2022 at 12:21 AM, lacerto said:

Obsolete.

@lacerto why do you keep saying 'obsolete'? I still have this problem today. I am trying to File >>> Open PNG barcodes as, or make them, 0-0-0-100 CMYK black, but Affinity Publisher opens them as 72-68-67-88 CMYK. And when I try to Layer >>> New Adjustment >>> recolour to 0-0-0-100 CMYK I get 0-0-0-96 CMYK. I am unable to, or do not know how, to achieve 0-0-0-100 CMYK for my barcodes. Can anyone advise me on how to accomplish this?

I have set the spread to File >>> Document Setup >>> Colour >>> Colour format: CMYK/8 >>> Colour profile: U.S. Web Coated (SWOP v2)

Edited by Cedar
Giving more info
Posted
8 hours ago, Cedar said:

@lacerto why do you keep saying 'obsolete'?

I read ‘Obsolete’ as shorthand for ‘Obsolete content removed’, or in other words ‘I have removed the original post content because what I had written no longer applies’.

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.5.1 (iPad 7th gen)

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.