Jump to content
AntiqueFlaneur

Is this discoloration an Affinity Publisher issue, or an Amazon KDP bug?

Recommended Posts

The book cover I'm trying to use for a print on demand book thorough Amazon KDP looks great in Publisher and when I view the exported PDF on my computer, but when I upload it to Amazon it appears discolored. 

Check out the back cover portion of "AmazonScreenshot.png" — it looks grey. But I made it black in Publisher, and it's still black when I view it as a PDF after export. This is shown in "PublisherScreenshot.png and PDFscreenshot.png".

Should I assume this is an amazon bug rather than an issue with Publisher?

 

AmazonScreenshot.png

PDFScreenshot.png

PublisherScreenshot.png

Share this post


Link to post
Share on other sites

I believe this is an Affinity issue. I recently published my first book done in Affinity (after losing my old CS2 product key) and have been having basically the same issue. My covers come out duller and more muted after uploading to KDP.

After spending weeks trying iterations of embedding ICC profiles, switching to CMYK, honoring spot colors, etc. I finally thought to try re-exporting an old CS2 file that had no prior issues with this via Affinity. Sure enough, the colors didn't come through correctly once I uploaded to KDP.

Affinity must be doing something different with color management, but it's way over my head to figure out what.

Examples from my book are attached for reference. I've been tearing my hair out trying to solve this one, so would love to hear what you come up with!

KDP Cover Preview.png

COVER_1_-_Press_Ready_-_8.5x11_bw_90.pdf

Edited by Spraypaintsensei
Added missing word

Share this post


Link to post
Share on other sites

Hi AntiqueFlaneur,

If you view the PDF in a different PDF viewer does this issue occur? If this problem was caused by Affinity I would expect to see it occur in the exported file.

Thanks

C


Please tag me using @ in your reply so I can be sure to respond ASAP.

Share this post


Link to post
Share on other sites
3 hours ago, Callum said:

Hi AntiqueFlaneur,

If you view the PDF in a different PDF viewer does this issue occur? If this problem was caused by Affinity I would expect to see it occur in the exported file.

Thanks

C

It doesn't seem to show up in Preview, or Adobe Acrobat Reader. 

Share this post


Link to post
Share on other sites
On 11/11/2020 at 6:18 PM, AntiqueFlaneur said:

The book cover I'm trying to use for a print on demand book thorough Amazon KDP looks great in Publisher and when I view the exported PDF on my computer, but when I upload it to Amazon it appears discolored. 

19 hours ago, AntiqueFlaneur said:

It doesn't seem to show up in Preview, or Adobe Acrobat Reader. 

To me the colors in all 3 pictures of your post look the same in my browser window, and if I download them they don't have a color profile (they may have been stripped by the forums software). This let me assume if you see different colors in your browser window vs. PDF and APub it might be caused by your browser when displaying the KDP website but doesn't show the 'true' KDP colors.

To detect whether your browser's color management is influencing the colors in your specific case you could open 3 browser windows + move each of the 2 screenshots (PDF / APub) onto a browser window + compare them with the KDP website.

Another test shows the profile support and color differences for your browsers, just view this site on different browsers:
https://cameratico.com/tools/web-browser-color-management-test/

EDIT: Sorry, I was focused before on the photo colours only, haven't noticed the hint "Check out the back cover portion". I also see the two different blacks in the background, they are not related to browser color management of cause.

Edited by thomaso

macOS 10.14.6, Macbook Pro Retina 15" + Eizo 24", Affinity in Separated Mode (documents merged)

Share this post


Link to post
Share on other sites
On 11/11/2020 at 7:18 PM, AntiqueFlaneur said:

Check out the back cover portion of "AmazonScreenshot.png" — it looks grey. But I made it black in Publisher, and it's still black when I view it as a PDF after export.

The back cover of the Amazon screenshot certainly looks different from the spine and front cover so it is likely that the delivered PDF has the blacks defined diffrently, as well. Can you post the PDF of the cover that was used in production?

Share this post


Link to post
Share on other sites
11 hours ago, Lagarto said:

The back cover of the Amazon screenshot certainly looks different from the spine and front cover so it is likely that the delivered PDF has the blacks defined diffrently, as well. Can you post the PDF of the cover that was used in production?

Here is the back part of the cover in PDF. 

BackCoverForum.pdf

Share this post


Link to post
Share on other sites
4 hours ago, AntiqueFlaneur said:

Here is the back part of the cover in PDF. 

Sorry, could not figure out based on just the back cover what could have happened. Basically there are two scenarios:

1) The back cover has rich black, and the front cover and spine K100, so when rendered similarly, the back cover becomes darker. As the opposite is true, this clearly has not happened, even if the back cover does have the black defined in CMYK (possibly RGB 0, 0, 0 converted to CMYK).

2) The K100 of the front cover (= a guess) has been rendered so that it becomes RGB 0, 0, 0, and the four-color-black of the back cover (= a fact) gets rendered in dark gray, and accordingly becomes lighter. This may have happened, but without seeing the front cover production PDF, this is just a guess. But this does not explain the difference in blackness between the front and back of the Amazon screenshot, since the rich black of the back cover would be rendered in much darker gray than shown in the screenshot, even if this scenario were true.

If the attached PDF was really used for creating the backcover of the Amazon screenshot, there must be something wrong with the production workflow. The PDF file itself is such that it should produce a good RGB screenshot with dark black. 

Share this post


Link to post
Share on other sites
36 minutes ago, Lagarto said:

Sorry, could not figure out based on just the back cover what could have happened. Basically there are two scenarios:

1) The back cover has rich black, and the front cover and spine K100, so when rendered similarly, the back cover becomes darker. As the opposite is true, this clearly has not happened, even it the back cover does have the black defined in CMYK (possibly RGB 0, 0, 0 converted to CMYK).

2) The K100 of the front cover (= a guess) has been rendered so that it becomes RGB 0, 0, 0, and the four-color-black of the back cover (= a fact) gets rendered in dark gray, and accordingly becomes lighter. This may have happened, but without seeing the front cover production PDF, this is just a guess. But this does not explain the difference in blackness between the front and back of the Amazon screenshot, since the rich black of the back cover would be rendered in much darker gray than shown in the screenshot, even if this scenario were true.

If the attached PDF was really used for creating the backcover of the Amazon screenshot, there must be something wrong with the production workflow. The PDF file itself is such that it should produce a good RGB screenshot with dark black. 

What sort of work flow error might do that? I've attached me afpub file. 

ForumFullCover.afpub

Share this post


Link to post
Share on other sites

You have a mix of RGB and CMYK embed documents making up the cover.


MacBook Pro (13-inch, Mid 2012) Mac OS 10.12.6 || Mac Pro (Late 2013) Mac OS 10.14.6

Affinity Designer 1.8.6 | Affinity Photo 1.8.6 | Affinity Publisher 1.8.6 | Beta versions as they appear.

Share this post


Link to post
Share on other sites

There is a mix, but one that does not explain the kind of big difference that shows in the Amazon screenshot. You have the front cover set in sRGB, the black of which is RGB 0, 0, 0. Then you have the backcover as a separate embedded Affinity Publisher file that (probably) has its initial RGB 0, 0, 0 black inadvertently converted into four color CMYK according to the default CMYK U.S. Web Coated profile so that it has become C72 M68 Y67 K88, the total ink coverage of which makes 295%.

Additionally the Publisher document that combines the front art (in sRGB) and backcover art (in CMYK) is itself an (s)RGB document, which then has finally been converted to CMYK using the underlying U.S. Web Coated target CMYK profile.  

While the mix is less than ideal (using a common workflow and color profiles throughout the project, and especially in cover, would guarantee coherent results), I cannot explain the great gray difference of the Amazon screenshot. The background has gray levels that do not seem possible without it being separately produced from the front cover and its tones manually adjusted.

The production file seems to have been produced using the default "PDF (press ready)" preset that is in many ways problematic because it is a kind of half-baked preset that on the other hand converts everything into CMYK but embeds (unnecessarily) the target profile, rendering the export file as an ICC-based PDF requiring interpretation when the file is RIPped at printer.  Yet it fails to include the rendering intent, and this leaves room for mistakes at rendering time. 

I suppose the book was also actually printed: can any difference be seen in the blackness of covers there? When I produced a print file using the default "PDF (press-ready)" without changing anything, the resulting file has the ambivalence described above but nothing that a competent printer could not handle. The black of the front and back should become identical despite the mixed source profiles.

For a reference, below is PDF/X-1a:2003 export from the same source, with default settings. It is a DeviceCMYK production file that does not need any interpretation at printshop, and a better production file. As you can see, the cover black is coherent throughout.

As a general instruction I'd advise to use a coherent workflow. Mixed modes have somehow caused this error, but in competent hands they should not become a problem.

ForumFullCover_pdfx1a.pdf 

Share this post


Link to post
Share on other sites

One further note: I am not familiar with Amazon KDP production workflow, but if this is just a front cover sceenshot problem, isn't ii possible to updload a PNG screenshot separately? Does it need to be a PDF (leaving it vulnerable to possibly automatic rasterizations and profile stripping)? 

Share this post


Link to post
Share on other sites
13 minutes ago, Lagarto said:

One further note: I am not familiar with Amazon KDP production workflow, but if this is just a front cover sceenshot problem, isn't is possible to updload a PNG screenshot separately? Does it need to be a PDF (leaving it vulnerable to possibly automatic rasterizations and profile stripping)? 

Unfortunately, they want a "Print Ready PDF", and will not accept PNG.

Share this post


Link to post
Share on other sites
46 minutes ago, Lagarto said:

 

I suppose the book was also actually printed: can any difference be seen in the blackness of covers there? When I produced a print file using the default "PDF (press-ready)" without changing anything, the resulting file has the ambiguency described above but nothing that a competent printer could not handle. The black of the front and back should become identical despite the mixed profile sources.

 

The book has not been printed since it appeared to be discolored during the set up process. But maybe I'll just try printing it. 

Share this post


Link to post
Share on other sites
14 minutes ago, AntiqueFlaneur said:

Unfortunately, they want a "Print Ready PDF", and will not accept PNG.

Ok, but if you previously uploaded a print PDF, I'd export a PDF/X1-a:2003 based CMYK pdf, which is a DeviceCMYK file that has every element resolved and in coherent color space, and therefore would not be vulnerable to confused interpretations, and see if that makes a base for a better screenshot.

Share this post


Link to post
Share on other sites

In case it helps AntiqueFlaneur or anyone else having Affinity + KDP color issues, here's how I solved this:

I set the document to RGB and exported to PDF using the "Digital (High Quality)" preset. I set DPI to 400, rasterized everything, and set Embed ICC and Honor Spot Colors to no. The Amazon cover image now appears much truer to the source document, with brighter, less-washed-out colors (compare the cover attached here to the cover attached earlier in the thread).

It's still over my head as to why this worked, but it did. My best guess is that the KDP workflow simply does not expect documents prepared for professional printing.

Hope that helps!

 

1474396160_KDPCoverFixed.png.259cf6233598ca74e2240452468cd1e7.png

Share this post


Link to post
Share on other sites
15 hours ago, Spraypaintsensei said:

My best guess is that the KDP workflow simply does not expect documents prepared for professional printing.

I had a look on this on KDP site, and this is exactly how it is. The whole workflow is purely for non-professional publishing and RGB based and only production tools mentioned are Word and Pages (macOS hobbyist page layout app). This means that the best workflow is to create an RGB document and deliver it by using the "PDF (for print)". The text should be defined as RGB 0, 0, 0  which may be converted in the process as K100, but otherwise the whole workflow is non-color managed.

EDIT: What this means for color-managed CMYK-based jobs is that any print target color profile included is simply just ignored. In professional hands the conversion could be done so that a CMYK print job is properly converted to (s)RGB and the kind of anomalies shown in this post do not happen, but as it is, RGB 0, 0, 0 blacks that are tagged for CMYK targets get through and print properly but CMYK converted rich blacks (and possibly K100, as well) become dark gray.

Share this post


Link to post
Share on other sites
On 11/11/2020 at 7:18 PM, AntiqueFlaneur said:

Should I assume this is an amazon bug rather than an issue with Publisher?

In context of what is mentioned above, I think that what has happened with your cover is that you have probably produced the print PDF by using a "PDF (for print)" preset, which does not make conversions to document CMYK target so what it means is that sRGB based front cover with black defined as RGB 0, 0, 0 gets through as it is (just tagged for document CMYK target), and the CMYK based back cover will also get through but but shows dark gray in RGB context. It is difficult to say whether the difference in black would show in printed version, as well, as the CMYK conversion that will eventually be done does not produce a difference that is as radical as appears in the screenshot.

But the problem could be avoided either by keeping the whole job (s)RGB based and then creating a "PDF (for print)" print PDF (which would stay pure RGB), or using e.g. PDF/X-a1:2003 export method, which would create a pure CMYK document so that mixed color spaces get resolved and would be handled similarly in print process.

Share this post


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

This means that the best workflow is to create an RGB document and deliver it by using the "PDF (for print)".

I haven't experienced uploading a sample PDF to see what happens but, at least theoretically, they recommend CMYK (and accept RGB, too). Excerpt from KPD's "Getting started" PDF, linked on "File Formats and Specifications":

Quote

General specifications
• We support PDF v1.4 and lower.

Color interior requirements
Color pages
• We recommend using CMYK color space, though we also accept RGB.
(...)

Page 14 + 18 in  https://m.media-amazon.com/images/G/01/kindle-publication/KEP/KEP_POD_Getting_Started_EN._CB1570193013_.pdf

PDF v1.4 means that PDF/X-1 and X-3 are suitable – but X-4 is not. (APub's default preset "for print" creates a PDF in v1.7)

Also, to avoid embedded color profiles getting ignored in case of a not color-managed print workflow, APub's preset for X-3 may get manually (additionally) activated the "Convert..." option and force this way any assigned-only profile to be respected. APub's X-1 preset has this option ticked by default.


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 24", Affinity in Separated Mode (documents merged)

Share this post


Link to post
Share on other sites
On 11/18/2020 at 1:05 PM, thomaso said:

I haven't experienced uploading a sample PDF to see what happens but, at least theoretically, they recommend CMYK (and accept RGB, too). Excerpt from KPD's "Getting started" PDF, linked on "File Formats and Specifications":

What they basically mean is that send pure sRGB, but you can send CMYK if you know what you do. Their workflow is basically non-colormanaged (https://kdp.amazon.com/en_US/help/topic/G201953020) :

Quote

Color requirements

  • Color profiles. Color management added to an image or file. We don't recommend including color profiles in your file. Color profiles can produce unexpected results. They are automatically removed before publishing.
  • Spot colors. Color generated from ink chosen from a color system (such as Pantone Matching System). Spot colors are used in offset printing and aren't compatible with KDP's print-on-demand model, so please don't include spot colors in your files. We recommend converting spot colors to RGB or CMYK.
  • Color spaces. Describes color numerically, such as RGB (digital cameras and computer monitors), CMYK (full-color printing), and grayscale (black and white printing). We don't recommend using multiple color spaces in a file because it can cause color variance and unexpected results when your book is printed.
  • Color Variance. With our print on demand model, we have acceptable levels of color tolerance. Most color variance happens as a result of environmental and mechanical factors. We always strive for the best quality when printing your title. Color variance occurs for many reasons that are not related to your file, however, taking all the steps you can to perfect your file will reduce the chances of it occurring.

As mentioned above, they strip color profiles. If you have created a CMYK file, it is better to be pure CMYK (e,g, PDF/X-1a:2003, which forces CMYK-only), or "PDF (for press)" without a profile. Mixing color spaces in a non-color managed workflow where color profiles get discarded causes problems shown in this thread. 

EDIT: Also, if you print on uncoated paper, I'd send sRGB in a situation where a specific CMYK profile for uncoated stock is not given.

Share this post


Link to post
Share on other sites
On 11/17/2020 at 8:06 AM, Spraypaintsensei said:

In case it helps AntiqueFlaneur or anyone else having Affinity + KDP color issues, here's how I solved this:

I set the document to RGB and exported to PDF using the "Digital (High Quality)" preset. I set DPI to 400, rasterized everything, and set Embed ICC and Honor Spot Colors to no. The Amazon cover image now appears much truer to the source document, with brighter, less-washed-out colors (compare the cover attached here to the cover attached earlier in the thread).

It's still over my head as to why this worked, but it did. My best guess is that the KDP workflow simply does not expect documents prepared for professional printing.

Hope that helps!

 

1474396160_KDPCoverFixed.png.259cf6233598ca74e2240452468cd1e7.png

 

Thanks for this. Following your suggestion did get that weird back cover color to go away. The print edition is still looking a lot more washed out than the ebook, though, and I don't know why it has a random black border around it. 

Share this post


Link to post
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

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.