PDF Images too light-Publisher

[GregoryOR]

I am exporting pages for a virtual book in both JPG and PDF formats.  The JPG's come out perfect.  The PDF images are so light they are unusable.  Please see the attached screenshot, with the PDF export on the left and the JPG export on the right. Can anyone explain how I can get the PDF exported images to look right?

[Old Bruce]

To my eye it appears that somehow you have exported only the K channel from a CMYK document for the PDF and all channels were used for the JPEG.

[GregoryOR]

Would you happen to know if there is a setting somewhere where I can confirm which channels are being exported and possibly change it?  Thanks!

[Callum]

Hi GregoryOR,

Please could you provide a copy of the document in question along with a screenshot of the export settings you are using when exporting to PDF? This will allow me to investigate this further with you.

Thanks
C

[GregoryOR]

Thanks @Callum

Here's a trimmed down version of the afpub file, screenshot of settings, and the comparative exports.  I have never touched the PDF export settings from installation.  It looks like only the embedded images are faded.  Text and curves all look the same between PDF and JPG exports.

SketchTest.afpub SketchTest.pdf

[lacerto]

You have mixed color space (RGB and CMYK) images placed in a CMYK document with the default US Web Coated target profile. All images however are relatively low res so it is unclear whether CMYK output is really wanted, but let us assume that CMYK was really intended. The PDF created is also mixed color space file, and retains the involved transparency of the topmost image so the color values have not been resolved. 

How the color values will be resolved when the image is ripped (and the transparencies flattened) at print time will depend on in which transparency blending color space flattening will happen. Affinity apps do not allow the user to explicitly specify this, but there are ways to resolve the problem so that you more or less get what you see and can reasonably expect.

One part of the problem is that whenever you use CMYK document color mode, everything in the document will be shown as if proofed to simulate the target CMYK profile, and this view is not necessarily realistic as regards the final output you will get. 

One way to resolve this is to explicitly export to CMYK color space and additionally use "Convert image color spaces" option:

This still leaves the file somewhat ambiguous, leaving the transparency blending color space in RGB mode, but the result on paper would already be pretty much what you expect based on what you see on the display:

SketchTest_master_forced_cmyk.pdf   

The safest choice is to flatten transparencies, either by merging the involved raster images before exporting, or at export time, using either PDF/X-1a or PDF/X-3 based exports, which both do the job. Using PDF/X-1a will make the exported file DeviceCMYK, while PDF/X-3 can optionally leave non-flattened images in RGB color space.

SketchTest_master_pdfx1.pdf

SketchTest_master_non_forced_pdfx3.pdf

Without having PDF preflight tool like Adobe Acrobat Pro, IMO it is safest to go with PDF/X-1a, but there are some serious flaws [within Affinity apps] with this production method whenever placed PDFs are involved, or when needing to flatten vector-based transparencies. Neither are involved in your job, so forcing flattening and going DeviceCMYK is a safe choice.

 

Edited December 10, 2023 by lacerto
Renamed attached PDF to better reflect the contents

[GregoryOR]

Wow, thanks for the thorough explanation on color space!  I have so much to learn about this stuff!  My PDF is meant to be viewed digitally, so the CMKY color mode choice was unintentional.  I thought I used a web template to create this booklet, but maybe I accidentally chose a print template instead.  I tried changing the export settings to RGB, with no change to the output, so then chose PDF/X-1a like you suggested, and it looks great!

I usually ignore preflight, because it flags a bunch of intentional stuff as warnings, and for this document, it was spelling mistake warnings for a bunch of latin words, and bleed hazards, which aren't an issue with my document, and non-proportional scaling, which is on purpose.

Thanks again, for not only a solution, but some learning as well!

[lacerto]

2 hours ago, GregoryOR said:

with no change to the output, so then chose PDF/X-1a like you suggested, and it looks great!

Ok. Since Affinity apps cannot automatically flatten transparencies without converting them to CMYK, I would probably switch the color mode of the document to RGB and take the background image from the Master page to the back of the first page and group it with the top image and then rasterize, to have the transparencies flattened, and then export to RGB. You could also rasterize the top image in the current CMYK color mode to convert it to CMYK color space (= document color space) and then export directly to RGB (e.g. using PDF - Digital preset)), to have transparency values cause the visual appearance that you see before exporting.

There is something that I do not understand in the source Publisher file since if I rebuild it in Photo in sRGB color space (with the embedded RGB page background and main image, and the text and vector object group at the top), I get the expected RGB exports without merging the top and bottom images, and without any image conversions. Perhaps the file was somehow corrupted because of adjustment layers applied at the top group with gray values?

[lacerto]

I had another look on this, and there is something odd going on with handling of the PNG transparency of the top image that I cannot figure out. The transparency values behave erratically if the image is just passed through (e.g. exported using "PDF (Digital - high quality)":

but work fine if the image is downsampled (e.g., exported using "PDF (Digital - low quality)":

In both cases the transparent foreground PNG image is handled as a 24-bit RGB image containing RGB values and a device gray image containing the transparencies, but the non-downsampled image has sRGB2014 as an assigned color profile, which I do not get, because the embedded image has the standard sRGB2.1 color profile, as does the externalized linked image.

If I create the main image (sketch paper and and the foreground image with transparency) in InDesign and export to "interactive" PDF without resampling, I will get the following:

  

...so basically the same as in Publisher but with an indexed (paletted) RGB image with a device gray image telling the transparencies, but ICC based on standard sRGB2.1.

Somehow the error would appear to be related to using sRGB2014. I do have that profile installed on the system, and I thought that this might be Windows-only issue, but it appears that you are on macOS and seem to experience the same issue. I need to examine this on my mac to see if it is any different there...

[lacerto]

Checked this now on macOS (Sonoma 14.1.2 native M1 Publisher 2.3.0), and it is not different there:

a) Non-downsampled:

b) Downsampled:

So it appears that the inadvertently applied sRGB2014 would explain this, and that the issue would be automatically fixed when downsampling and sRGB2.1 is applied?

I say mysteriously because Resource Manager states this:

My guess is that this is partially an old issue related to Affinity apps not supporting indexed images so perhaps the original sketch and/or the paper background were paletted images originally and got converted to RGB images when placed, and were assigned with the app workplace RGB default sRGB2.1. For some reason sRGB2014 gets involved on export which I think is a later issue (somehow similar to an issue with renamed ISO Coated v2 CMYK profile)...

I am not sure if color management within Affinity apps is getting any better, but perhaps it is a good sign that it gets different 🙂

 

[GregoryOR]

This image has gone through a lot of conversions - starting as a jpg photo, then converted to png "sketch effect" using an online tool, then optimized using ImageOptim, but the final png before placing in AFPub is sRGB IEC61966-2.1 as you show in the resource manager screenshot.  The paper background image is a jpg, with the same color space and color profile as the sketch before placing into AFPub.  I just created a new AFPub document with the same color profile as the images, and placed them in the document. 

The I exported as digital-high quality PDF and again as X-1a:2003 PDF.  When I open both in AFPub and look at the resource manager, the transparent image has been exported differently between the two.  In the digital HQ pdf, the image is faded, and is a TIFF with RGB color space and no ICC profile.  In the X-1a pdf, the image is perfect, and is a JPG with CMKY color space, also no ICC profile.

What tool are you using to compare the downsampled and non-downsampled? Curious that it is showing RGB color profiles for the exported embedded images, but the resource manager in AFPub that I am using shows something very different.  But it does suggest that the export process is where the sRGB2014 profile is introduced, rather than the placement of the image in the document.

I find this fascinating, and am learning so much that I didn't know before!

[lacerto]

11 hours ago, GregoryOR said:

In the digital HQ pdf, the image is faded, and is a TIFF with RGB color space and no ICC profile. 

Yes, it is the one that is tagged as having the sRGB2014 color profile. The transparency values of downsampled and non-downsampled images are the same but the one that has sRGB2014 profile has significantly and systematically brighter RGB values.

I just rebuilt the file in Publisher 1.10.6.1665, and exported directly to PDF (Digital - high quality), and the issue does not happen there:

...so it is clear that this is an error introduced in versions 2.

BTW, I use Adobe Acrobat Pro 2020 (perpetual license) on Windows as a prepress tool, and on mac I have Packzview (exists also for Windows) which is a free (though the license is obviously only admitted for professional use), but more limited, yet very useful as a tool for getting print-pertinent information on PDFs.