Jump to content
You must now use your email address to sign in [click for more info] ×

Wrong black values while exporting to CMYK


Recommended Posts

This is a follow up question of my previous thread in case someone is wondering.

I have a bunch of qr codes as .png's. They only consist of two unique colors (Black and White).

As soon as I import them into my print layout in Affinity Publisher and change the color profile from RGB to CMYK/IsoCoated_v2_300(My print shop demanded this format) the colour black is not fully black anymore(cmyk(0%, 50%, 0%, 99%)) and my print shop says he can't deal with these colors, since the detail of the qr codes suffers badly from these mixed black values when ofset printing them.

What can I do to prevent the black from changing when swtiching colour profiles?

Link to comment
Share on other sites

You have PNGs, they are available in RGB only. Try converting them to TIFFs and convert the TIFFs to CMYK or Greyscale. Then place the CMYK or Greyscale TIFFs into the CMYK Publisher document.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

On 11/23/2022 at 11:54 PM, BofG said:

Not sure if it's available there.

It is in all three of them, whenever the document color mode is CMYK/8. Having the K-Only button turned on for PNGs (including 8-bit indexed), which will be interpreted as 8-bits/channel RGB when placed, should make the RGB black K100 (CMY 0) whenever exporting to CMYK PDFs. These kinds of PNGs should also work in Gray/8 documents (where K-only is not available but where RGB blacks, R=0 B=0 G=0, will be exported as DeviceGray black when exported to PDF using Grayscale color mode). 

Link to comment
Share on other sites

13 hours ago, lacerto said:

It is in all three of them, whenever the document color mode is CMYK/8. Having the K-Only button turned on for PNGs (including 8-bit indexed), which will be interpreted as 8-bit RGB when placed, should make the RGB black K100 (CMY 0) whenever exporting to CMYK PDFs. These kinds of PNGs should also work in Gray/8 documents (where K-only is not available but where RGB blacks, R=0 B=0 G=0, will be exported as DeviceGray black when exported to PDF using Grayscale color mode). 

I followed your suggestion in detail but still get a strange result. This time it's an other black value. There's progress, just don't know if that's good.😄

The screenshot is from the pdf after exporting the layout containing the qr-png with the K only option set exported inthe desired color profile ISO Coated v2 300.

image.thumb.png.183eb9eb6406e219ecf548a83bc31c42.png

 

EDIT:

Your tip was completely correct. I just forgot to uncheck the image compression in the export setup. This messed up the colours. Now colours are K Only. Thanks a ton!

Edited by Pbj
Link to comment
Share on other sites

Just now, Rodi said:

Can you curve them out? Click on the PNG, and go to curves, CMYK, and up the k and remove the others. I do this in Adobe products (Little more time consuming opening up programs  than StudioLink, LOL).

The K only option for png did the trick fortunately. Thanks anyway :)

Link to comment
Share on other sites

20 minutes ago, Pbj said:

Your tip was completely correct. I just forgot to uncheck the image compression in the export setup. This messed up the colours. Now colours are K Only. Thanks a ton!

You're welcome. The fix is actually not as straight forward as one could wish as when I tested it both with 24-bit and 8-bit (indexed) PNGs, both containing only black and white, I got different results in different situations. In one instance the resulting PNG was converted to CMYK, the black being a K value, and in another instance (in most situations) to DeviceGray. Both cases work, but when I subsequently tried this with another CMYK document, I got consistently DeviceGray values. It may depend on document history, e.g. whether a document was initially an RGB document when the PNGs were placed, or whether it was a CMYK document but using initially a different CMYK profile. Also, it may be dependent on the export method, whether an ICC profile is embedded, and whether the placed images are forced to be converted. But basically the "K-Only" feature should work, one way or another...

Link to comment
Share on other sites

14 hours ago, lacerto said:

Having the K-Only button turned on for PNGs (including 8-bit indexed), which will be interpreted as 8-bit RGB when placed, should make the RGB black K100 (CMY 0) whenever exporting to CMYK PDFs.

Just in case: whenever does not mean every export, e.g. when the export profile is different from the document profile. Then a conversion of 100 K will happen again on export – as long Affinity lacks in an export option to preserve colour values.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

31 minutes ago, thomaso said:

Just in case: whenever does not mean every export, e.g. when the export profile is different from the document profile. Then a conversion of 100 K will happen again on export – as long Affinity lacks in an export option to preserve colour values.

This is generally speaking true, but these are RGB images that are first interpreted as 24-bit RGB (if initially 8-bit indexed), and I think that K-Only actually forces the applied objects to gray values so they should be immune to export time CMYK-profile changes. It would be different if the objects were converted to CMYK, which, as I mentioned, indeed seems to be the case in some situations -- which I now cannot reproduce, of course ;-). It is not clear whether K-Only would actually avoid export time CMYK conversions anyway, meaning that objects tagged with "K-Only" could somehow be encapsulated and protected from such changes.

Link to comment
Share on other sites

19 hours ago, Pbj said:

I have a bunch of qr codes as .png's.

Be aware that on PDF export, those PNGs may become antialiased, convert to JPEG etc., especially if not aligned to your document pixel grid (known issue!).
For QR codes, I'm always using vector. Most online QR generators have a SVG or PDF option. There's no reason to use PNGs in layout context whatsoever.

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

12 hours ago, loukash said:

For QR codes, I'm always using vector. Most online QR generators have a SVG or PDF option. There's no reason to use PNGs in layout context whatsoever.

Perhaps users should be aware that SVG is by definition RGB and if you place them in Publisher document (CMYK or RGB) and export to CMYK PDF, you will get four-color black and there is no K-Only button available for SVGs that would help you.

Below, on top, heavily antialiased PNG, which my mobile phone could still read without much problems (I do not say that it could when this kind of mess would be printed, but it is nevertheless K-only). Below that, on left, Affinity "interpreted" SVG that uses clip-path-encoding from Adobe Express -- not a problem to any other app I use as it is SVG 1.0, Inkscape, CorelDRAW 2017, Illustrator CS6, but looks like this also when placed or opened in v2 Affinity apps. And to right of it, [a Corel-DRAW produced] SVG that is otherwise fine but will get exported in four-color-black in a press-targeted PDF. 

image.png.de4ae0d97f33ec24a9541d324b1495fe.png

If your PNGs are high-res enough to not get downsampled, they will not be antialiased. And even if they would be a bit blurred on paper, I am not sure which is worse: misaligned CMYK plates or slightly blurred K (would it even be much worse than mere dot gain?)

It seems that no matter which format you have your QR codes in, there is some fussing about them when they are placed in Affinity apps for production on commercial press. PNGs might actually be your best choice ;-) 

qr_svg_apub.pdf

 

Link to comment
Share on other sites

Very interesting information, thanks for that. Yeah I'm glad I got the qr codes to k only, I hope this will work fine after print. There are a lot of these qr codes and I got them as pngs so I will stick with it for now. The only option would be to import them as CMYK pdfs I guess, but I hope I can skip that step.

Link to comment
Share on other sites

1 hour ago, lacerto said:

Perhaps users should be aware that SVG is by definition RGB and if you place them in Publisher document (CMYK or RGB) and export to CMYK PDF, you will get four-color black and there is no K-Only button available for SVGs that would help you.

Of course. But it's vector, so changing an SVG QR to 0-0-0-100 is literally just a click away.

edit: I forgot to mention that I'm not placing SVG or PDF QR codes. I'm opening them natively and copying the curves to the layout. Then you can assign any color you need, scale them etc.

1 hour ago, lacerto said:

Below, on top heavily antialiased PNG, which my mobile phone could still read without much problems

I know that reading them is less an issue, but…

1 hour ago, lacerto said:

And even if they would be a bit blurred on paper, I am not sure which is worse: misaligned CMYK plates or slightly blurred K (would it even be worse than dot gain?)

… but personally, I find QR codes already ugly enough all by themselves. (I'm attempting to integrate one into a postcard design as we speak… :61_sob:)
And even uglier than QR codes are blurry pixelated QR codes.

Edited by loukash

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

19 minutes ago, Pbj said:

Very interesting information, thanks for that. Yeah I'm glad I got the qr codes to k only, I hope this will work fine after print. There are a lot of these qr codes and I got them as pngs so I will stick with it for now. The only option would be to import them as CMYK pdfs I guess, but I hope I can skip that step.

Just check the  placed PPI value of those QR codes. If they are anywhere near 300ppi, they won't be downsampled with default export values which would downsample only images that are over 375ppi or higher (if your document DPI is the standard 300).

Link to comment
Share on other sites

6 minutes ago, Pbj said:

The only option would be to import them as CMYK pdfs I guess

Not at all!
You can open the PDFs natively in Affinity, group the vectors, and then you copy them into your layout and set them all to CMYK 0-0-0-100. Then you can scale them as you see fit, without having to worry about anything ever again. Been there done that hundreds of times. :) (OK, perhaps not hundreds, but dozens of times for sure.)

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

1 minute ago, loukash said:

… but personally, I find QR codes already ugly enough all by themselves. (I'm attempting to integrate one into a postcard design as we speak… :61_sob:)
And even uglier than QR codes are blurry pixelated QR codes.

I share that view. I was recently asked to add them in posters, and the consequence was that when people tried to take selfies, their mobiles by default autofocused and scanned the QR-codes :51_scream:

Link to comment
Share on other sites

Really, thanks to you guys. Your help is really appreciated. I was pretty lost. 

Printing exports are quite no to me and it got overwhelming very quickly.

Maybe this is a bit off but somehow fits the topic and you got some tips regarding this for me as well:

I have black font in the layout too, but even if I can export the qr codes now as K only black the font won't be black no matter what I try. I set the color to CMYK(0/0/0/100) and grey scale black from the color picker, but I always get mixed CMYK color font. I wish there was a k only button for my text :D.

Link to comment
Share on other sites

11 minutes ago, lacerto said:

Just check the  placed PPI value of those QR codes. If they are anywhere new 300ppi, they won't be downsampled with default export values which would downsample only images that over 375ppi or higher (if your document DPI is the standard 300).

Why haven't I thought of this myself. And I wondered why I get this unclear edges with these high dpi qr codes. Should have checked what the software does on default when exporting..

Link to comment
Share on other sites

3 minutes ago, Pbj said:

Why haven't I thought of this myself. And I wondered why I get this unclear edges with these high dpi qr codes. Should have checked what the software does on default when exporting..

Depending on what other image content you have, you might end up getting pretty large production PDFs. But if they are not insanely high-density you might get away simply by increasing the default downsample trigger PPI value from the PDF export settings. Otherwise you could resample the QR codes in a batch using Affinity Photo for resizing and using the nearest neighbor resampling method.

Link to comment
Share on other sites

33 minutes ago, Pbj said:

I always get mixed CMYK color font

Which preset are you using for export?

Also, looking at your 1st post:

22 hours ago, Pbj said:

change the color profile from RGB to CMYK/IsoCoated_v2_300

If text was assigned RGB black at first, it won't change to 100K automatically. You may need to double check all your black objects before exporting.
If your text has text styles assigned, then it can be just a matter of fixing the color in styles.
Or use "Select Same Color" in Publisher 2. If you're using v1, you will need to switch to the Designer persona for the Select Same commands

41 minutes ago, Pbj said:

grey scale black from the color picker

… is RGB = CMY gray!
Same for the Affinity Grays swatches!

For print, always use K in the CMYK sliders for shades of gray. Unless you intentionally want to use composite gray, of course.

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

On 11/23/2022 at 9:18 PM, Pbj said:

What can I do to prevent the black from changing when swtiching colour profiles?

Related to what @loukash mentioned above, I was also a bit puzzled about significance of this.

Changing of the color mode, or changing of color profiles within the same color mode, might actually result in changes in exported PDFs since placed files might be tagged (assigned) with color profiles that were active at place-time, but might actually not be updated whenever the originally active RGB or CMYK document color profile is changed. This might e.g. explain what I initially experienced when testing black and white only containing PNGs (8 and 24-bit) and exporting them to CMYK PDFs, as I used variably RGB started and CMYK started documents, then switching CMYK profiles variably by using the assign option (which does not change color values), and convert option (which does change values of all native CMYK objects, but not ones in placed content).

Anyway, I managed to produce from RGB PNGs (which are always interpreted as non-indexed 8-bit per channel RGBs within Affinity apps), with K-Only choice applied, both K100 (CMY 0) and DeviceGray images in exported PDFs, and precisely because of this, I began to wonder if changing the CMYK profiles, while having K-Only already applied, might actually result in K-Only failing and producing four-color black in some specific situation.

This is of course very confusing, and most of the time, I'd imagine, things do not get this complicated.

But as a reply to your initial question: to avoid changing (translation) of color values when changing from one profile to another within the same color mode, you'd need to use the "Assign" option (in File > Document Setup > Color). This means of course that the visual appearance of colors may change, but often it does not matter as changes are small if color profiles do not differ much from each other. If color profiles are significantly different, you should use the "Convert" option, but this will always also change K-only based color definitions (that is, blacks and grays with zero CMY) to four-color black values, and you'd need to change them back. The same also applies to significant RGB profile changes, so e.g. switching from sRGB to Adobe RGB or vice versa, just assigning color values would result in overly saturated or desaturated color values, depending on direction of conversion, i.e., in clear difference in appearance of colors. It all depends, one cannot give general instructions that work in every situation.

Link to comment
Share on other sites

slice2.png.cb7417e51279952dd5c1adc42860264d.pngpRiNt! mOnKeY! 🖨️🙊
💻Lenovo Legion 5 Pro*, Intel(R) Core(TM) i7-12700H, 2300 Mhz, 14 Core, 32GB DDR5-4800, nVidia RTX 3070 Ti 8GB, Windoze 11 💻
*Sometimes gets used for something other than games.

 

Link to comment
Share on other sites

14 hours ago, loukash said:

Which preset are you using for export?

Also, looking at your 1st post:

If text was assigned RGB black at first, it won't change to 100K automatically. You may need to double check all your black objects before exporting.
If your text has text styles assigned, then it can be just a matter of fixing the color in styles.
Or use "Select Same Color" in Publisher 2. If you're using v1, you will need to switch to the Designer persona for the Select Same commands

… is RGB = CMY gray!
Same for the Affinity Grays swatches!

For print, always use K in the CMYK sliders for shades of gray. Unless you intentionally want to use composite gray, of course.

14 hours ago, lacerto said:

Related to what @loukash mentioned above, I was also a bit puzzled about significance of this.

Changing of the color mode, or changing of color profiles within the same color mode, might actually result in changes in exported PDFs since placed files might be tagged (assigned) with color profiles that were active at place-time, but might actually not be updated whenever the originally active RGB or CMYK document color profile is changed. This might e.g. explain what I initially experienced when testing black and white only containing PNGs (8 and 24-bit) and exporting them to CMYK PDFs, as I used variably RGB started and CMYK started documents, then switching CMYK profiles variably by using the assign option (which does not change color values), and convert option (which does change values of all native CMYK objects, but not ones in placed content).

Anyway, I managed to produce from RGB PNGs (which are always interpreted as non-indexed 8-bit per channel RGBs within Affinity apps), with K-Only choice applied, both K100 (CMY 0) and DeviceGray images in exported PDFs, and precisely because of this, I began to wonder if changing the CMYK profiles, while having K-Only already applied, might actually result in K-Only failing and producing four-color black in some specific situation.

This is of course very confusing, and most of the time, I'd imagine, things do not get this complicated.

But as a reply to your initial question: to avoid changing (translation) of color values when changing from one profile to another within the same color mode, you'd need to use the "Assign" option (in File > Document Setup > Color). This means of course that the visual appearance of colors may change, but often it does not matter as changes are small if color profiles do not differ much from each other. If color profiles are significantly different, you should use the "Convert" option, but this will always also change K-only based color definitions (that is, blacks and grays with zero CMY) to four-color black values, and you'd need to change them back. The same also applies to significant RGB profile changes, so e.g. switching from sRGB to Adobe RGB or vice versa, just assigning color values would result in overly saturated or desaturated color values, depending on direction of conversion, i.e., in clear difference in appearance of colors. It all depends, one cannot give general instructions that work in every situation.

Thanks again !

I am not using a preset. These are my export options:

image.png.8e4bf8129ed8bead1f954138a01eb6e6.png

The document settings was set to US Web Coated (SWOP) v2 initially, but I changed that as soon the printer told what he wants. 

Now I can imagine - like lacerto said - that there are some problems changing from one profile to another, so I checked assign in the colour settings of the document. I even created a new text element with the desired color profile set to test the outcome. Strange enough I don't get a black only colour for the text even pre export:

image.thumb.png.a6b2685a70845c312a0badb6ef9e7a74.png

And after export the text has yet another colour. Yay:

image.png.a46bc4727db0ba173c4480d41dab1544.png

This is next level confusing for me, as I'm quite new to this. Did I overlook something in your advices?😶

 

1 hour ago, Print Monkey said:

This doesn't seem to be the problem here, since I never get the values of rich black after exporting. The problem persist, even if I don't have RGB values assigned to the elements I want to export.

 

Edited by Pbj
Link to comment
Share on other sites

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.