Affinity Publisher - File Size on Export / Effect of "Convert image color spaces"

[Gwar]

Hi all,

I created a Photo Book using Affinity Publisher. Naturally, it consists mainly out of images, approximately 6000x4000 Pixels. The document is setup as RGB/32 (HDR).
I export using Color Space RGB and Color Profile sRGB IEC61966-2.1.

When I export with "Convert image color spaces" unchecked, I get file Sizes of roughly 200MB, depending on the JPEG setting. If I check "Convert image color spaces" however, I get file sizes of roughly 1.5 GB. Obviously the document setup has some influence on this: if I change the color format from RGB/32 (HDR) to RGB/8 I can not observe the increase of the file sizes. However, I don't want to use this setting because I am afraid to lose image quality. 

As the printing agency requires Color Space RGB and Color Profile sRGB IEC61966-2.1 I thought it is a good idea to check "Convert image color spaces" upon export. But the 1.5GB are way too much.  

Is there a way to stay within the 200MB mark with "Convert image color spaces"? Or am I doing something wrong?

Best,

Gwar

[Hangman]

Hi @Gwar and welcome to the forums,

If the images used in your Photo Book are RGB/8 then you should set your document up as RGB/8 sRGB IEC61966-2.1, not RGB/32 (HDR)...

By setting your document up using RGB/32 (HDR) and selecting 'Convert image colour spaces' the images are converted from JPEG (or PNG) to TIFF files increasing the exported file size massively...

If the images used in the document are RGB/8 and your document is set to RGB/8 then there is no need to check the 'Convert image colour spaces' as it will not affect the images in any way since the colour space is the same...

[Gwar]

Dear @Hangman,

Thank you for the welcome and for having me. 

Quote

If the images used in your Photo Book are RGB/8

I opened a couple of the images (JPEG files) in Photoshop and you are right: they have 8 bits per channel. I used this information to do some research and obviously the jpeg format allows only 8 bit. I probably should have known this.

As the photo book uses JPEGs exclusively, your reply explains the behavior. So I will set the document setup to RGB/8.

Thank you a lot!

[Hangman]

Hi @Gwar,

That's no trouble at all, I wish you well with your photo book...

[Gwar]

Thank you, @Hangman.

Maybe you are also aware of the reason for a related follow-up question.

Document Setting RGB/8; sRGB IEC61966-2.1

Export settings:
Downsample Images: Disabled
JPEG Compression: Disabled

Assumed behavior:
With these settings, I would guess that Affinity Publisher simply takes the JPEG images "as they are" and creates a PDF.

Observed behaviour:
File Size again goes up to 1.5GB; indicating that TIFF files are being used.

Additional notes:
Enabling either Downsample Images, JPEG Compression or both, obviously reduces file size.

My question is: as disabling "Downsample Images" and "JPEG Compression" raises file size again, my assumption seems to wrong. But what's happening instead and how can I export "simply" the original images then?

 

[walt.farrell]

57 minutes ago, Gwar said:

My question is: as disabling "Downsample Images" and "JPEG Compression" raises file size again

If you disable both of those, then I think the file size must increase, as (if nothing else) the JPG files will no longer be compressed. I think something similar would happen if you don't downsample images, but that would (perhaps) depend on what DPI your images have already. The Resource Manager will show you that.

[Guest]

Hi @Gwar,

assuming that your photo book has a format of, say, A4 landscape (297x210 mm or 11.7 x 8.26 in.),
at a good print resolution (=document resolution) of 300 ppi, full page size images would have dimensions of 3,508 x 2,481 pixels.
If you prefer even higher print quality (depending on the used print technology), you could use a document resolution of 450 ppi,
so the resulting image dimensions would be 5,262 x 3,721 pixels.

Your source images are 6,000 x 4,000 pixels, so you have probably – even in full page size – cropped them and/or scaled them to fit in your pages.

At export, APub must as good as always recalculate the images to the given dimensions (resulting of the document resolution and source image size).

The options "Downsample Images" can be used for controlled reducing the image resolution in case of placing big images
in relatively small size in the document (if you would make an overview of all pictures in your book as a sort of table of contents with downscaled
versions of each picture, they would have a very high effective resolution of e.g. >1800 or even >3000 ppi, which gains no benefits while printing
and makes the file size enormous).
The effective resolution can be checked in the Ressource Manager as @walt.farrell said above.
With this option checked, APub will downsample all images above the set resolution and thus reduce the file size.

While "JPEG Compression" is disabled, all image data is stored with lossless compression (ZIP) which is far less effective on image data than JPEG.
Affinity Publisher help says:

Quote

If this option is off, rasterized design elements will be exported as uncompressed.

A quality setting of 98 for JPEG compression (recommended in the presets) stores images quite efficiently, almost without visible decreasing the image quality.
If the resulting file size is still too big, you can experiment with reducing the quality setting step by step and checking if the images still have the desired quality e.g by exporting a single page with the most significant image to PDF.

 

Best regards

[Gwar]

Dear @walt.farrell and @werfox,

Thank you for your very helpful replies. The resource manager indeed shows DPIs from 309dpi to 1021dpi. 
 

Quote

you have probably – even in full page size – cropped them and/or scaled them to fit in your pages.

That statement is absolutely correct. I scaled them indeed.

 

I probably need to correct myself regarding the file sizes after some more structured testing.

Total file size on hard disk: 676MB

Resulting export file sizes:
A JPEG Compression: No; Downsample Images: Disabled. File Size 415MB
B JPEG Compression: No; Downsample Images: Threshold of 375dpi to 300 dpi. File Size 415 MB 
C JPEG Compression: Yes, Quality 100; Downsample Images: Disabled. File Size: 860 MB
D JPEG Compression: Yes, Quality 100; Downsample Images: Threshold of 375dpi to 301 dpi. File Size 217,9 MB

I did this twice to ensure consistency. Both tests had the same results.

However, I find some aspects surprising/worth to mention:

1. Test B resulted in the same file size as Test A. Given that the resource manager definitely showed images with more than 375 dpi, I would expect B to be smaller than A. So obviously A did some downsampling. I assume this happened, because  @werfox wrote that APub will ALWAYS recalculate images, but the Downsampling section provides more control. Assumption: I accidentally used an internal default with 375 dpi to 300 dpi.
2. I would expect C to be smaller than B (and A), as A and B would result in uncompressed images (because of the corresponding statement in the help section). However, C is more than double the size of A and B. 
3. D is the smallest file size - this corresponds to my expectation.
4. No export is near the 676MB of the Hard Disk files. Probably also, because APub always recalculates images.

To verify the assumption in observation 1, I tested another export: Downsampling threshold of 300 dpi to 300dpi; no JPEG compression. That led to 416,9 MB. However, the resource manager showed me that only a single image resource was below 400dpi, so that explains why the difference is not huge. Still, I would have expected the file size to shrink and not to grow compared to A and B. 

Best wishes,
Gwar

PS: The 218 MB of the export, or even the 415 MB will be just fine for the printing agency. I am just trying to understand APub here, because I am intending to use it more often

Edit: Spelling and Grammar

Edited October 13, 2024 by Gwar

[Gwar]

@Hangman, @walt.farrell, @werfox

I just wanted to let you know, that the photo book turned out just fine. Thank you for your support. 

[Hangman]

Hi @Gwar,

That's really great to hear, many thanks for letting us know...