Image size and exported PDF size

[DJP]

I am typesetting a book in Affinity Publisher. The author provided me with photos that will go in the book. These were scanned at very high resolution (I believe 4800 dpi and 48-bit color) from her slides as TIFFs, with very large file sizes.

In Affinity Photo I resized them by changing the dpi to 300 (standard for printing) and then setting the horizontal size at 1900 pixels, with the vertical size calculated automatically. If my math is correct, 1900 pixels is the right size to fit properly across the page as I have designed it.  Then I exported the photos as PNG‘s.

The problem is that the PNG files are still very large, about 12 or 13 MB. If I put 40 of these into the book, the final PDF will be over the limit that the printer will accept. What is the best way in Affinity Photo to reduce the size further while maintaining the quality?  Or is there some way in Publisher to shrink the photos (again, maintaining the quality) when I export the final PDF? (The images are linked, not embedded, in Publisher.) I know that there is an option when exporting PDFs to reduce images that are over a certain resolution, but since I’ve already changed the photos to 300 dpi I don’t think that will address the issue.

[thomaso]

8 hours ago, DJP said:

PNG files are still very large, about 12 or 13 MB. If I put 40 of these into the book, the final PDF will be over the limit that the printer will accept.

You cant calculate with the PNG file sizes for the exported PDF. Not only Affinity PNG are relatively large (compared with other software) but also the JPG compression you can use for PDF export may result in a quite different file size.

Generally there is no need to resize the images before using them in APub, instead the downscaling and recompressing happens on export ( … unless you would deactivate any resampling & recompression in the export settings).

You have three choices to influence the output file size:

• If you don't tick the checkbox "Convert image colour spaces" the RGB images will be maintained in RGB and get their profile added for correct CMYK conversion in the printers pre-press process. This will result in about 20-25% smaller PDF file size compared to have all images converted to CMYK. – Check the expected / required profile and PDF version with your print service.

• Reducing the export resolution will reduce the output file size. Though 300 dpi are standard, depending on the image content also less may give sufficient results, e.g. 280 or 250 dpi. A test will show you the difference, for visual comparison on screen view the results at about 250 – 350 % (because a screen doesn't display with 300 dpi like print but rather about 72 – 144)

• Also reducing the export JPG compression quality leads to smaller file size. The most file size effect happens between 100 and 85 % quality, below the effect gets smaller and possible compression artefacts may get visible, again depending on the image content. An export with 100 – 95 % compression quality results in an obviously larger PDF than 85 %.

[lacerto]

As you mention 48-bit color (16-bits per channel), you can typically get file sizes that are about a quarter of the sizes (both PNG and final PDF) if you save the images as 24-bit (8 bits per channel). You do not gain anything in quality by printing with 48-bit images. Publisher seems to export placed 48-bit images variably as 24-bit RGB (e.g. PDF/X-3) and 48-bit RGB (e.g. PDF/X-4) so that CMYK versions (that are saved in PDF/X-1a:2003) that are 32-bit images can actually be smaller than RGB images. Obviously compression of 48-bit images is less effective.

The point is that by placing initially 24-bit images, you get much more effective packaging so without touching at all the DPI and JPEG compression quality settings (keeping them at defaults), but just using the default PDF 1.7, PDF/X-1a:2003, PDF/X-3 and PDF/X-4 export settings and using either 24-bit or 48-bit images, the PDF print file sizes of a publication with just two 1900x2688px images vary between 6,329MB to 54,169MB! And each such image would increase the file size practically linearly.

By optimizing the JPG compression quality you can gain extra saves in file sizes but unless your images are very homogenous so that you can use the same compression setting throughout the publication, I would leave the setting at default, or only drop it by maximum of 15% and see whether there is any seeable quality loss (in any image, as the setting is applied on all images exported per session), and any significant save in file sizes. Just for comparison: the test file I used (with 2 images) produced only 2.3MB PDF file sizes when exported from InDesign, where the default export setting at "Maximum" quality means using an as per image estimated best compression method. InDesign also always converts 48-bit images to 24-bit so it does not matter what kinds of files are placed in the document. You might be able to achieve pretty much the same in Publisher by using compression quality at somewhere around 70%, but you typically cannot afford using a setting this low because with some images it could produce clear artifacts.

Based on this, I would convert the original images to 24-bit RGB (PNG or TIFF), place them in the layout and export using any of the method (e.g. Press Ready 1.7, PDF/X-3 or PDF/X-4) that keeps the images as RGB images (if this is ok with the printer). I would touch the compression quality or DPI setting only if the filesizes are too big with 24-bit images and RGB output. 

[thomaso]

5 hours ago, lacerto said:

Obviously compression of 48-bit images is less effective.

Your 48 bit file sizes remind me of an issue reported in earlier* APub versions, where it appeared that images above 24 bit did not get compressed on PDF export. Also I vaguely remember that Affinity PDF export in macOS in certain circumstances can use another compression than JPG, ZIP or LZW which is not listed in the export options. – Have you read what compression was used in your larger PDF files?

*compare…:

[lacerto]

11 hours ago, thomaso said:

Your 48 bit file sizes remind me of an issue reported in earlier* APub versions, where it appeared that images above 24 bit did not get compressed on PDF export. Also I vaguely remember that Affinity PDF export in macOS in certain circumstances can use another compression than JPG, ZIP or LZW which is not listed in the export options. – Have you read what compression was used in your larger PDF files?

They use nominally "Zip/Flate compression (FlateDecode)" whatever that means. The total of raw file sizes without any compression at all would be 2 * 29,2MB so obviously some kind of packing is used as the total of PDF file sizes is around 54MB. But the file sizes of PNG files, both when saved from PS and Photo is around 22MB each, so the method Affinity apps use when exporting these files to PDF is less effective than used when initially saving those PNG files using lossless packing. As mentioned, InDesign converts 48-bit images to 24-bit and then uses (by default) optimized JPEG compression, and the effect on resulting filesize of PDF exports is huge: 2.3MB vs. 54.1MB, just for two images.

[DJP]

On 11/1/2022 at 12:38 AM, thomaso said:

• Also reducing the export JPG compression quality leads to smaller file size.

Thank you for the very helpful reply.  I'm using PNGs not JPGs, so I assume the compression you mention won't apply in my case (unless Publisher converts everything to JPG on export??).  The photos use the color profile that is specific to the Epson V850 scanner with which they were digitized--this gives noticeably better color than Epson RGB or sRGB.  I set the Publisher document to CYMK since that is what the printer prefers, although he can accept sRGB.  I'm not quite sure how all this fits together.  I assume that Publisher can convert the Epson-specific profile to CYMK properly when I generate the PDF for the printer.

[DJP]

On 11/1/2022 at 10:45 AM, lacerto said:

. . . you can typically get file sizes that are about a quarter of the sizes (both PNG and final PDF) if you save the images as 24-bit (8 bits per channel). You do not gain anything in quality by printing with 48-bit images.

Very useful info, thanks!  In Affinity Photo, if I choose Document>Convert Format>RGB8, that is 24-bit (since 8 x 3 channels = 24).

On 11/1/2022 at 10:45 AM, lacerto said:

I would convert the original images to 24-bit RGB (PNG or TIFF), place them in the layout and export using any of the method (e.g. Press Ready 1.7, PDF/X-3 or PDF/X-4) that keeps the images as RGB images

I set up the Publisher document as CYMK because that is what the printer prefers, but he will accept sRGB also.  Should I change the whole document to RGB/8, or do the photos stay as RGB if I choose one of the export options you mention?

[thomaso]

44 minutes ago, DJP said:

I'm using PNGs not JPGs, so I assume the compression you mention won't apply in my case (unless Publisher converts everything to JPG on export??)

About the PNG compression method see the recent reply of @Lacerto (right above your last response). Also consider that PNG isn't meant to use CMYK space, which may mean if you convert them on export to CMYK (again according @Lacerto's hints) they won't be PNG anymore – which would mean it can make sense to place JPG in the layout instead of PNG.

However, initially you asked about options to reduce the exported PDF file size, so possibly it doesn't work to stick with all quality parameters like file format and compression.

Just in case: the comparison on this website gives quite a good overview for various JPG compression rates shown with different types of image content (scroll down to an image and hover over the various compression rates …). Though it was done for JPGs exported from Lightroom it still may give an idea about the size / quality ratio:

http://regex.info/blog/lightroom-goodies/jpeg-quality

[lacerto]

7 hours ago, DJP said:

Very useful info, thanks!  In Affinity Photo, if I choose Document>Convert Format>RGB8, that is 24-bit (since 8 x 3 channels = 24).

Yes, exactly.

7 hours ago, DJP said:

I set up the Publisher document as CYMK because that is what the printer prefers, but he will accept sRGB also.  Should I change the whole document to RGB/8, or do the photos stay as RGB if I choose one of the export options you mention?

No, just keep the current document color mode but ensure that the CMYK color profile is one recommended by the printer. If it is not, change it by choosing File > Document Setup > Color, then click "Assign" and choose the recommended profile. If you can do this right from the start before having placed any images in the document, that would be good. (Using "Assign" option instead of "Convert" keeps existing color values, which is normally just fine unless the old and new color profiles are significantly different.) 

When you export, you can choose a method that retains the color mode of the images (e.g. PDF/X-3 or PDF/X-4; or the plain "PDF (Press ready)" option) -- ask the printer if they have any preferences. The point of retaining the images in RGB color mode is in this case mainly to be able to create small enough PDF export file size (as RGB images will take less space, having typically 3 channels instead of 4).

[thomaso]

5 hours ago, lacerto said:

choose the recommended profile. If you can do this before right from the start before having placed any images in the document, that would be good.

By the way, do you have an idea or knowledge about the use or speciality of "generic" colour icc profiles like those in macOS, "Generic CMYK", "Generic XYZ"…?

I got aware of them when my default PSO_coated_v3 or ISO v2 profiles started annoying me in a bunch of simple, small CMYK test .afpubs because of increasing the file size. Do you know if it can make sense to use such a "generic profile" as Affinity default, either for test files that don't get produced or especially as long a finally required export profile by the printer or client is known?

[lacerto]

11 hours ago, thomaso said:

By the way, do you have an idea or knowledge about the use or speciality of "generic" colour icc profiles like those in macOS, "Generic CMYK", "Generic XYZ"…?

Not really. Our workflows are typically CMYK based and most printers that we use use the same or very similar profiles, so after knowing which kind of media will be used for any specific job, we choose the correct target CMYK profile very early in the project. If there is need to change the target at a later stage, I have not been afraid of doing so in InDesign, where the text black is nailed with [Black] and the swatch values are converted so if there is need for that, we always convert rather than just assign; any placed CMYK content will not be affected as they are by default assigned to be using document target, and that also happens without needing to worry about whether the change in CMYK document color space will actually "take". In that kind of workflow it would not be a problem to switch between CMYK profiles as these are basically just changes in meta data and swatch definitions etc. and accordingly do not require much manual work afterwards (typically none at all), and most importantly, do not cause destructive, pixel-based changes. Images stay always in RGB color mode so they would not be affected no matter what. It would of course be totally different if actual pixel data would be involved: here, I think, there can basically be only one-time conversion.

In respect of CMYK profile switch, I find Affinity environment problematic, not only because conversions do not change swatch values but because I have noticed that switch of profile does not always seem to properly have effect in placed images (assigned with document color profiles), so that old assignments might stay, and eventually cause color translations at export time. In addition there can be pixel layers involved that would be directly affected, and complex adjustments which I am not sure how well they would work in the first place in CMYK color mode (and/or CMYK color definitions used in native objects like text and shapes), let alone when the working color profile is changed. For me the apparent easyness and non-destructiveness adds complexity at production time so I feel that I save time by using mostly desctructive methods, instead.

But to return to the question, there has not really been need for using "generic" CMYK profiles (or any other "generic" color modes) in our workflows. Most modern CMYK profiles have TAC around 300%, and this seems to be true for "Generic CMYK Profile", as well. So in that respect it would work, but there are several other things to consider, and I would not use it in a workflow that is meant to be delivered DeviceCMYK. But perhaps it would be useful similarly as any common CMYK profile that is somewhere "in the midddle" as an initial CMYK profile if the final target is not known so that if there are changes, they could be made just by assignment, not touching the current color values.

But I really do not know. Common CMYK profiles like ISO Coated V2, ISO Coated 300%, PSO Coated v3, and profiles for uncoated media like Uncoated Fogra 29, Uncoated Forgra 47, PSO Uncoated v3, as well as ISO Newspaper profiles have normally worked well in DeviceCMYK based workflows. There are also large-gamut 360% TAC CMYK exchange ISO profiles and specific conversion CMYK profiles from e.g. ISO Coated v2 to PSO Coated v3 and vice versa, which I have no experience of. Years ago we could achieve excellent results with paper specific profiles, but I suppose the ISO based standards have now superseded these workflows. I do not know but I have a feeling that printers still make adjustments to whatever is given them so if there is a common starting point in some ISO standard that works well with printer-specific workflows, that is the safest choice. I have no idea what would not get translated if such generic profiles were used, but perhaps the size does matter in this context ;-).

I have seen so much problems with RGB based workflows and PDF/X-4 and anything that just piles in profiles and leaves things to be resolved at the printer that we now try to avoid these kinds of workflows. This might seem backwards but most of the printers we use here in Finland also seem to prefer work this "old-fashioned" way. I suppose it means more predictability and less complaints. To me It seems that (at least within offset print) the aim at generic and "easy" workflows that do not require print-specific knowledge from "clients" has backfired. Sometimes I feel that the "client-side" is not the only part who lacks exact knowledge about printing processes so I think there has been general degradation in this business.  

 

[thomaso]

4 hours ago, lacerto said:

I have no idea what would not get translated if such generic profiles were used, but perhaps the size does matter in this context ;-).

Yes, and size was the reason to make it interesting to me ;-). I wonder if the small size would mean they do nearly nothing with colours (like NO profile ?). It appears that especially linear or wide-gamut RGB profiles have a small file size (below 1 Kb) whereas the size of CMYK profiles varies a lot (~ 0.5 kB – 3 MB).

It feels odd that I am unable find any info about "Generic…icc" profiles, even the Authors of the "PDF-Bible" (600 pg., by Merz @ PDFlib / Drümmer @ Callas software) didn't mention "generic" .icc as specific profiles in their German book from 2002 – which might mean they have no use at all, and/or just that Apple did create it later. Whereas the paper supplier Canson has its own (odd) understanding of "Generic profile": https://www.canson-infinity.com/en/what-generic-icc-profile

Have you ever seen "Generic…icc" profiles in Windows, or are they some Apple speciality?

Apple mentions "generic" for colour spaces and it appears to be used as synonym for "device independent":

https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_color/dq_color.html

Their use of "specific" + "device independent" sounds confusing, to me independent wouldn't be specific and vice versa, while "leave to the system" sounds like no change / influence at all. (but this is about spaces, not profiles …?)

[lacerto]

11 hours ago, thomaso said:

Have you ever seen "Generic…icc" profiles in Windows, or are they some Apple speciality?

No, but I have generic profiles on Windows because of installation of QuarkXPress, but the CMYK one is a bit larger than the rest:

 

@MikeW could probably shed some light on this, but I suppose the description by Apple above said enough.

Another approach to "generic" would be using large-gamut, large-TAC exchange CMYK profiles:

http://www.eci.org/doku.php?id=en:colourstandards:workingcolorspaces

...but this is really beyond my knowledge and experience. As mentioned, my experience has been the opposite: exceptionally good results achieved with paper specific profiles e.g. for Munken and other yellowish special papers. And now that I checked, these profiles are by no means obsolete:

https://www.arcticpaper.com/services/icc-profiles/

Just checking the file sizes, they are big, as are the common profiles for uncoated stock like 

Uncoated_Fogra47L_VIGC_260 and
Uncoated_Fogra47L_VIGC_300

for 260% and 300% TAC which are both over 8MB.

So for me, device-dependency means attention to specific and individual = quality. Aiming at device-independency means versatility and flexibility, but I suppose this is something that is needed when converting between CMYK spaces. As graphic designer this is not my concern as I want to convert just once, and using the correct profile. I do not want anyone to touch the color values later (if they do it anyway, I do not complain as long as the result is what I expected, and what they actually do, does not much interest me).