Jump to content

Recommended Posts

I have been trying to publish the latest issue of my comic at Amazon Kindle. Usually, I just create the pages in Designer, then compile a PDF to create the comic, and send it to Kindle in RGB. Kindle then handles the RGB to CMYK conversion, and the printed result is always fine. 

But this time, I used Publisher. I cut and pasted the flattened Designer pages into a Publisher document, then exported the book to PDF, and sent it to Kindle. As I needed a black background for the pages, I created a black fill rectangle in the Master Page, and applied it to all the pages. As you can see in the sample page I added to this post, the black color looks right (to my eyes, at least). But actually, it isn't. There's a slight difference between the blacks of the Designer page I pasted in the Publisher document, and the black background I used for the fill rectangle. So I checked the colors of the fill rectangle, and the RGB sliders are all at 0, as they should be. Then, I chose CMYK Sliders and I have the following values: C: 72 M: 68 Y: 67 K: 88. To be sure, I created a new document, created a black fill rectangle and checked the values. These are the same default values. I suppose this is where the printing problem is coming from, and these CMYK default values might be a way to have the black color look better in offset printing, but why are these values displayed by default instead of being part of some kind of Color Conversion setting, and why are the RGB sliders all at 0 while the CMYK values are not at 100? Shouldn't the RGB values reflect the CMYK values in this case?

PDF Page Test.pdf

Share this post


Link to post
Share on other sites

I'm no expert, but it seems to be something to do with the "Colour Format" you choose when creating a new document.  If you set it to "CMYK", black has the CMY sliders at "0" and just the black (K) slider at 100%. If you create it as "RGB" then convert it to CMYK you get " C: 72 M: 68 Y: 67 K: 88".

I would assume, as you say, that it is connected to the fact that printing uses CMYK, while screen display uses RGB and that the values change when converting from one format to the other. (When printing you get a richer black if you use all the colours, not just black (K).)

(By the way, I really like your images.)

 

 

Share this post


Link to post
Share on other sites
4 minutes ago, PaulEC said:

I'm no expert, but it seems to be something to do with the "Colour Format" you choose when creating a new document.  If you set it to "CMYK", black has all the CMYK sliders at "0". If you create it as "RGB" then convert it to CMYK you get " C: 72 M: 68 Y: 67 K: 88".

I would assume, as you say, that it is connected to the fact that printing uses CMYK, while screen display uses RGB and that the values change when converting from one format to the other.

(By the way, I really like your images.)

 

 

Thanks:). The penciler is Alex Nascimento, and it's been colored by Dijjo Lima.

The color format is RGB/8, so I don't see any reason why the CMYK option shouldn't display 100 for each value in this case. Maybe this has to do with the color profile, but I can't be sure.

To check it, just create a new document, set it to RGB/8, then create a rectangle. Click the Fill color thumbnail on top of the document. In the Color Tab, set every slider to 0 in the RGB Sliders menu to fill the rectangle with black. Then click the RGB Sliders menu, and choose CMYK sliders. You'll see that the sliders have been automatically set to C: 72 M: 68 Y: 67 K: 88. I still don't understand why that is.

At this stage, having a way to change color values for all objects at once would be a great help.

Share this post


Link to post
Share on other sites
30 minutes ago, Glyphs said:

The color format is RGB/8, so I don't see any reason why the CMYK option shouldn't display 100 for each value in this case.

I think it’s to do with keeping Total Area Coverage (TAC) under 300 to avoid saturating the paper. The CMYK value (100,100,100,100) gives you a TAC of 400, but the CMYK value (72,68,67,88) yields a TAC of 295.


Alfred online2long.gif
Affinity Designer 1.7.0.367 • Affinity Photo 1.7.0.367 • Windows 10 Home (4th gen Core i3 CPU)
Affinity Photo for iPad 1.7.0.135 • Affinity Designer for iPad 1.7.0.9 • iOS 12.3.1 (iPad Air 2)

Share this post


Link to post
Share on other sites
40 minutes ago, Alfred said:

I think it’s to do with keeping Total Area Coverage (TAC) under 300 to avoid saturating the paper. The CMYK value (100,100,100,100) gives you a TAC of 400, but the CMYK value (72,68,67,88) yields a TAC of 295.

OK if we create a document for offset printing, but we publish eBooks too nowadays. And then, there's Print-On-Demand services, who tell us to send them RGB files, and handle the CMYK conversions themselves. If it has to do with the TAC, I believe it should be part of a setting instead of being here by default.

Share this post


Link to post
Share on other sites
4 minutes ago, Glyphs said:

OK if we create a document for offset printing, but we publish eBooks too nowadays. And then, there's Print-On-Demand services, who tell us to send them RGB files, and handle the CMYK conversions themselves. If it has to do with the TAC, I believe it should be part of a setting instead of being here by default.

I'm curious about something: If you're still sending to KDP, why not simply setup your Publisher document in RGB, to match your Designer documents?

Just select the Print preset when creating the document, and you have RGB.


-- Walt

Windows 10 Home, version 1903 (18362.145), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.1.404 and 1.7.1.404 Beta   / Affinity Designer 1.7.1.404 and 1.7.1.404 Beta  / Affinity Publisher 1.7.1.404

Share this post


Link to post
Share on other sites
4 minutes ago, Glyphs said:

OK if we create a document for offset printing, but we publish eBooks too nowadays. And then, there's Print-On-Demand services, who tell us to send them RGB files, and handle the CMYK conversions themselves.

For eBooks you would be using RGB instead of CMYK anyway, and if you’re using a POD that asks for RGB files then you don’t need to concern yourself with the conversion process, so I don’t see why it should be an issue in either case.


Alfred online2long.gif
Affinity Designer 1.7.0.367 • Affinity Photo 1.7.0.367 • Windows 10 Home (4th gen Core i3 CPU)
Affinity Photo for iPad 1.7.0.135 • Affinity Designer for iPad 1.7.0.9 • iOS 12.3.1 (iPad Air 2)

Share this post


Link to post
Share on other sites
11 minutes ago, Alfred said:

For eBooks you would be using RGB instead of CMYK anyway, and if you’re using a POD that asks for RGB files then you don’t need to concern yourself with the conversion process, so I don’t see why it should be an issue in either case.

It shouldn't be an issue because I don't convert the files. The files are in RGB/8 and I let them as is.The only thing I do is exporting the document to PDF. 

What I find is wrong is this: Create a new document, choose the Print option in the Type menu, set the Colour Format to RGB/8 if it's not already set this way, click OK, then create a rectangle. Click the Fill color thumbnail on top of the document. In the Color Tab, set every slider to 0 in the RGB Sliders menu to fill the rectangle with black. Then click the RGB Sliders menu, and choose CMYK sliders. You'll see that the sliders have been automatically set to C: 72 M: 68 Y: 67 K: 88.

Choosing CMYK Sliders isn't like converting the whole document to CMYK. It would be more akin to checking if the CMYK values are right. I believe in this case, the values for Black should 100 for every slider.

Share this post


Link to post
Share on other sites
20 minutes ago, walt.farrell said:

I'm curious about something: If you're still sending to KDP, why not simply setup your Publisher document in RGB, to match your Designer documents?

Just select the Print preset when creating the document, and you have RGB.

Same reply as for Alfred: The files are in RGB/8 and I let them as is.The only thing I do is exporting the document to PDF. 

What I find is wrong is this: Create a new document, choose the Print option in the Type menu, set the Colour Format to RGB/8 if it's not already set this way, click OK, then create a rectangle. Click the Fill color thumbnail on top of the document. In the Color Tab, set every slider to 0 in the RGB Sliders menu to fill the rectangle with black. Then click the RGB Sliders menu, and choose CMYK sliders. You'll see that the sliders have been automatically set to C: 72 M: 68 Y: 67 K: 88.

Choosing CMYK Sliders isn't like converting the whole document to CMYK. It would be more akin to checking if the CMYK values are right. I believe in this case, the values for Black should 100 for every slider.

Share this post


Link to post
Share on other sites
4 minutes ago, Glyphs said:

Choosing CMYK Sliders isn't like converting the whole document to CMYK. It would be more akin to checking if the CMYK values are right. I believe in this case, the values for Black should 100 for every slider.

I don't see why that should be the case. I might understand why you'd think that a pure black would be CMYK 0,0,0,100 but 100,100,100,100 makes no sense to me.

You'll see the same values, by the way, if you do the same operation in Designer or in Photo, or if you use the Info panel in Photo. And you'll probably see that with any other black in your Designer images, too.

I suggest not worrying about it, unless you have some blacks in your document that are behaving differently. But to comment further on that I would need one of the .afdesign pages that shows the difference.


-- Walt

Windows 10 Home, version 1903 (18362.145), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.1.404 and 1.7.1.404 Beta   / Affinity Designer 1.7.1.404 and 1.7.1.404 Beta  / Affinity Publisher 1.7.1.404

Share this post


Link to post
Share on other sites
4 minutes ago, walt.farrell said:

I don't see why that should be the case. I might understand why you'd think that a pure black would be CMYK 0,0,0,100 but 100,100,100,100 makes no sense to me.

You'll see the same values, by the way, if you do the same operation in Designer or in Photo, or if you use the Info panel in Photo. And you'll probably see that with any other black in your Designer images, too.

I suggest not worrying about it, unless you have some blacks in your document that are behaving differently. But to comment further on that I would need one of the .afdesign pages that shows the difference.

Sorry about the black values:)

You're right for the Designer and Photo values, so the problem might not come from it (which is kind of worrying)

Here are the images I sent to Amazon Kindle Support once I received the proofs of my books (photos of two of the book's pages). As you'll see, there's a difference between the black values, and I know for a fact that the differences are between the images I pasted into Publisher from Designer flattened files, and the Background rectangle I created in the Publisher Master Page of the book. I am trying to solve this, and am open to any idea.

2019-04-16 08.51.53.jpg

2019-04-16 08.51.45.jpg

Share this post


Link to post
Share on other sites

Please provide a .afdesign file, and a .afpub file into which you've copied the page. Note that it does not need to be one of your book pages, just something you create that demonstrates the problem.


-- Walt

Windows 10 Home, version 1903 (18362.145), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.1.404 and 1.7.1.404 Beta   / Affinity Designer 1.7.1.404 and 1.7.1.404 Beta  / Affinity Publisher 1.7.1.404

Share this post


Link to post
Share on other sites
2 minutes ago, walt.farrell said:

Please provide a .afdesign file, and a .afpub file into which you've copied the page. Note that it does not need to be one of your book pages, just something you create that demonstrates the problem.

It will be faster with the real pages, since they are already done. Sorry about the free publicity, I'm really trying to have this book released. Here is the flattened Designer document, with its associated Publisher Page. The designer Page has been cut and pasted onto the Publisher Page, and a black background has been created as a master for the Publisher Page.

Rage_Page_Designer_Sample.afphoto

Rage_Page_Publisher_Sample.afpub

Share this post


Link to post
Share on other sites
1 hour ago, Glyphs said:

What I find is wrong is this: Create a new document, choose the Print option in the Type menu, set the Colour Format to RGB/8 if it's not already set this way, click OK, then create a rectangle. Click the Fill color thumbnail on top of the document. In the Color Tab, set every slider to 0 in the RGB Sliders menu to fill the rectangle with black. Then click the RGB Sliders menu, and choose CMYK sliders. You'll see that the sliders have been automatically set to C: 72 M: 68 Y: 67 K: 88.

Choosing CMYK Sliders isn't like converting the whole document to CMYK. It would be more akin to checking if the CMYK values are right. I believe in this case, the values for Black should 100 for every slider.

No, your assumption is wrong.

First: Neither Photoshop, nor Illustrator, nor InDesign does this – or bette:r can do this. And Publisher can’t do it as well.

Why?

If you set RGB colours to 0/0/0, what leads you to the opinion, that the corresponding CMYK values should be 100/100/100/0?

There can’t be a simple correspondence between RGB and CMYK, because of the „K“. You would be right if we didn’t deal with CMYK, but with CMY. In this case there would exist an unambiguous conversion from RGB to CMY. Since print colours need to add the „K“, every RGB color now has literally thousands of „correct“ corresponding CMYK colours. Which is the „expected and needed“ correct one? This depends on many facts: printing paper colour and quality, ink consistence, printing speed and, and and. The correspondence between RGB and CMYK colours can’t be a simply mathematically conversion (because of the „over-determined“ ambiguous CMYK system), but follows complex conversion tables stored in the used colour profile, which have been established by evaluating thousands of sample print outs. These conversion tables are different for example for different printing papers of different ink coverage requirements in different printing scenarios.

Publisher has to use sort of an intern colour profiling to display corresponding RGB/CMYK values. Which ones are used is – as far as I know – not known.

That is, why I don’t think, your workflow is really streamlined and secure. The RGB black of the images (and the text within the images!!) has to be converted to CMYK, and since the black is RGB black, there will be no way at all to output a K=100 black as – for example –is required for black text. But that is a different subject … :)

Share this post


Link to post
Share on other sites

OK, so this means that the software is fine, but the files have to be converted. All the book pages are RGB Designer files, and I need to send KDP an RGB PDF file. I suppose the fastest way to do this should be to paste each flattened RGB Designer file into an RGB Publisher file, and then export it into PDF. I thought that’s what I did, but obviously, I have it wrong. What would be the options to check in the Publisher file so that the pasted RGB Designer files, and the black background rectangle into the Publisher file have the exact same black values?

Share this post


Link to post
Share on other sites

Tag the images with sRGB, measure the colour values, create a RGB Publisher document with the same colour profile and use the exact same black value as used in the image.

Share this post


Link to post
Share on other sites
1 minute ago, mac_heibu said:

Tag the images with sRGB, measure the colour values, create a RGB Publisher document with the same colour profile and use the exact same black value as used in the image.

That's the problem. The Designer images and the Publisher file are both in sRGB/8 with the exact same profile, because I left the Default options as is in both apps. The black color is RGB = 0,0,0 in all the Designer files, and in the Publisher file. It's obvious in the printed book that the source of the problem is the difference between the black color in the Designer file and the black color in the Publisher file, but I don't know what option to change to make this right. At worst, I'll simply put a black fill background layer in each Designer file and paste the fill layer along with the image into each page. If the problem comes from pasting the Designer files, this solution might work, but it won't solve the overall problem. Is there some option to change in the Publisher and Designer files I posted to just make the Publisher file right?

Share this post


Link to post
Share on other sites

I’m not an expert, but preparing a document in RGB that is an light composing process (i.e. a projection, presentation), but a document that has to be printed should be prepared in CMYK that is a method of adding inks to obtain a colour. In CMYK a pure black has (in order to avoid an excess of ink that deteriorates paper) C0M0Y0K100, or a bit of C if texture should be cold, or a bit MY if texture should be warm. And black ink is frequently printed on top of the other inks. So a good practice is to see where your document will be used, and what for, and prepare it with the adequate procedure or colour space. Sure, techniques/colour spaces like LAB are general solutions, but if your product will be printed, is better to use CMYK whenever possible.

Share this post


Link to post
Share on other sites
2 minutes ago, eluengo said:

I’m not an expert, but preparing a document in RGB that is an light composing process (i.e. a projection, presentation), but a document that has to be printed should be prepared in CMYK that is a method of adding inks to obtain a colour. In CMYK a pure black has (in order to avoid an excess of ink that deteriorates paper) C0M0Y0K100, or a bit of C if texture should be cold, or a bit MY if texture should be warm. And black ink is frequently printed on top of the other inks. So a good practice is to see where your document will be used, and what for, and prepare it with the adequate procedure or colour space. Sure, techniques/colour spaces like LAB are general solutions, but if your product will be printed, is better to use CMYK whenever possible.

Actually Amazon Kindle Direct Publishing is OK for RGB files, especially since the books are primarily intended to be published digitally. The print-on-demand service is an option Amazon offers to KDP publishers. It allows us to create a printed version of the book with Amazon's digital printing service, but it's not offset printing, so there's no real need for a CMYK file. Amazon can handle any conversion necessary, so I've always sent them RGB files (and everything has been fine with this process, so far).

Share this post


Link to post
Share on other sites

@Glyphs:

  1. Look at the attached sample files: 1 AffFoto file, 1 AffDesigner file, 1 AffPublisher file and the exported PDF.
    The black areas are defined as RGB 0/0/0 (document profile sRGB), placed in Publisher (RGB document, sRGB profile) and exported as sRGB PDF. The colour are and remain RGB 0/0/0.
  2. Your sample document is a publisher document, with placed pixel(!) layers. Exported as PDF and opened in Acrobat Pro, the blacks show RGB 0/0/0. Exported as a RGB TIF and opened in Photoshop the blacks  are RGB 0/0/07.

So: I can’t see a problem.

@eluengo: In most cases your approch is ok. But even if the export is a printsble PDF, it should be (and is!) possible to create the document in RGB and leave colour conversion to the output routines of Publisher. The biggest caveat is black text in images (as is in the initial posters document) will end up as multi-colour-black in the PDF output and that normally is unwanted.

Black_Test.zip

Share this post


Link to post
Share on other sites
11 minutes ago, mac_heibu said:

@Glyphs:

  1. Look at the attached sample files: 1 AffFoto file, 1 AffDesigner file, 1 AffPublisher file and the exported PDF.
    The black areas are defined as RGB 0/0/0 (document profile sRGB), placed in Publisher (RGB document, sRGB profile) and exported as sRGB PDF. The colour are and remain RGB 0/0/0.
  2. Your sample document is a publisher document, with placed pixel(!) layers. Exported as PDF and opened in Acrobat Pro, the blacks show RGB 0/0/0. Exported as a RGB TIF and opened in Photoshop the blacks  are RGB 0/0/07.

So: I can’t see a problem.

@eluengo: In most cases your approch is ok. But even if the export is a printsble PDF, it should be (and is!) possible to create the document in RGB and leave colour conversion to the output routines of Publisher. The biggest caveat is black text in images (as is in the initial posters document) will end up as multi-colour-black in the PDF output and that normally is unwanted.

Black_Test.zip

Yes, in my Publisher document, the pixel layers should be the Comic book Designer flattened file and the fill layer (that I copied from an Affinity Photo document). Fill layers help me create a resizable background for each of my documents, be it Designer, Photo or Publisher files. 

Kindle Support sent me the attached file about the PDF document I sent them. It shows that there really is a difference between the blacks. I did the same with the eyedropper in Affinity Publisher and didn't find any color difference in the blacks, so It looks like the difference appears only when the PDF is exported. I don't see any visible problem with the text. The colors are as they should be. The only problem is the background on which the pages have been pasted, but I can't seem to reproduce it. I even opened the original PDF in Affinity Photo. When I used the eyedropper on a page, there was no difference between the blacks either. I don't know how Amazon ended up with this result, but I do see that it has to do with the pasted images onto the black background.

I am at a loss of ideas, at this point. Maybe I should try to flatten the layers in the publisher file, and send them the resulting PDF, to check if it solves the problem. If anyone has an idea, suggestions are welcome.

2019-04-19_15-53-36.gif

Share this post


Link to post
Share on other sites

The values in your GIF are showing CMYK values, which are massively to high! Since your document is a RGB document, which you hopefully(!) exported correctly — and following your intentions — using the correct color space and colour profile, it is completely up to Kindle to convert correctly. An ink coverage of that height is definitely not correct, but this is not under your responsibility.

 

Before going on in this discussion, we should clear some thing up!

You are talking about a „Designer“ page, which is „cut and pasted“ into Publisher. Your sample file is no „Designer“ file but a „Photo“ file. And: Did you try not to copy and paste, but to place the image?

Didn’t we talk about RGB values (R=0/G=0/B=0) up to now? Didn’t you tell us, the CMYK values are not so important, because the book is published online? Why do you show us CMYK values? How were these values achieved? Which conversion profile was used?

In short: To investigate the „issue", it is necessary

  1. to have a look at the exact page, where the animated GIF was taken from.
  2. to know, which steps were undertaken and which colour profile was used to convert the RGB document to CMYK,

Otherwise, no valid statement is possible.

Share this post


Link to post
Share on other sites
5 hours ago, mac_heibu said:

The values in your GIF are showing CMYK values, which are massively to high! Since your document is a RGB document, which you hopefully(!) exported correctly — and following your intentions — using the correct color space and colour profile, it is completely up to Kindle to convert correctly. An ink coverage of that height is definitely not correct, but this is not under your responsibility.

 

Before going on in this discussion, we should clear some thing up!

You are talking about a „Designer“ page, which is „cut and pasted“ into Publisher. Your sample file is no „Designer“ file but a „Photo“ file. And: Did you try not to copy and paste, but to place the image?

Didn’t we talk about RGB values (R=0/G=0/B=0) up to now? Didn’t you tell us, the CMYK values are not so important, because the book is published online? Why do you show us CMYK values? How were these values achieved? Which conversion profile was used?

In short: To investigate the „issue", it is necessary

  1. to have a look at the exact page, where the animated GIF was taken from.
  2. to know, which steps were undertaken and which colour profile was used to convert the RGB document to CMYK,

Otherwise, no valid statement is possible.

I kept the default values for the Publisher document and the PDF export, so there shouldn't be any problem with the RGB file or the color profile.

I copy files from Photo files. I select all the layers, then choose Merge Visible, and copy and paste the merged layer into a Publisher page.

I am showing you the result of Amazon KDP conversion. The GIF image is what they sent me. I don't know anything else yet. I don't think I could ask Amazon to send me the converted file, but I could try anyway, adding to my request a link to this thread. 

I remembered yesterday that they sometime have a problem with what they call "Transparency" in a PDF. Maybe this whole thing actually comes from their process, so what I did is flatten all the pages layers, and send them a new PDF. I should receive a new proof in a few days.

Share this post


Link to post
Share on other sites

As I said, no answer possible.

Please decide in first place, what you want us to answer. As I told you, you changed your question very often during the discussion (RGB values, corresponding CMYK values, CMYK important or not — and if: why asking about RGB values and show us CMYK values without saying/know, how they were achieved?

As I said: We would need at least(!) the Publisher page, which contains the element you showed in your last GIF. Otherwise, as I said, no answer possible.

Share this post


Link to post
Share on other sites
On 4/23/2019 at 10:26 AM, mac_heibu said:

As I said, no answer possible.

Please decide in first place, what you want us to answer. As I told you, you changed your question very often during the discussion (RGB values, corresponding CMYK values, CMYK important or not — and if: why asking about RGB values and show us CMYK values without saying/know, how they were achieved?

As I said: We would need at least(!) the Publisher page, which contains the element you showed in your last GIF. Otherwise, as I said, no answer possible.

Sincerely sorry for all this. What happened is that Kindle Tech support told me there was a problem with the black values, and I thought it came from… the black values. I have received my new proofs today, and everything is now fine. Here is what I did, and what (I think) happened: as the black values seemed to be fine in the original files, but seeing that Kindle's software had created a color difference between the layers, I thought the problem might come for the layers, so I flattened every layers on every page, so that each page actually contains only an image, and it worked. 

Now, of course, I have a new question since flattening the whole file page by page is time consuming, but I'm not sure if this question should be part of a new thread or not. Obviously, at first, I had exported a PDF with some kind of layers in it (or transparencies, as Kindle Tech Support seems to call it). I don't know how PDF conversion works, but it's obvious Kindle's software recognizes the same layers in the PDF file as in my original file. I have looked at Publisher's PDF export options, and don't know what option I should have checked to not have this layers problem, so my question is: is there a way to export a PDF with flattened layers, instead of flattening the layers in the Publisher's file itself, or if not, is there a way to add such an option? 

I understand that you couldn't answer questions about the files generated by Kindle's software without having a look at these files, but I can't ask Amazon to send me the files they use, and a lot of us are going to use Kindle's services to publish printed books, so this problem is bound to happen again. I think the simplest way to do this would be to add an option to have Publisher flatten the layers in the PDF only when exporting the file. Should I start a new thread with this question?

UPDATE: Finally found out you can do this by exporting in PDF/X-1a: 2003. I didn't try the PDF (flatten) option yet, but I'll make a few tests with Amazon Kindle. Sorry for the trouble.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×