How do I compress pictures in Affinity Designer?

[AmapThom]

Is there an option to compress pictures in Affinity Designer? I have a design that contains many images. The total size of my image assets on my hard drive is 500 MiB. Some images are duplicated multiple times in my design. Overall the design file is occupying 3 GiB on my hard disk. I suspect this may be the cause of some AD crashes, and I fear that a file that big may not be sustainable in the long-term as my design evolves.

[v_kyr]

Hmm, first of all you should then periodical make some backups of your whole work (the design file, assets etc.) to some external media, in order to be on the more secure side. Next you can try to save the design file under some new filename (save as...) to see if that will give you some slightly different or more compact resulting file size. If you don't need the asset images themselve in their maybe inside your design used higher resolution size, you can try to minimize their individual size seperately probably via image file format compression (JPGs, TIFFs, PNGs). Though you then will have to rework your actual design and to exchange already used embedded images. - Finally you can try to export your design in/as a hopefully more size compact PDF format and test afterwards, if it can be recreated (reimported) in a quite pleasing manner without being as huge as before. - Good luck!

[R C-R]

2 hours ago, AmapThom said:

Some images are duplicated multiple times in my design. Overall the design file is occupying 3 GiB on my hard disk.

Have you tried making one of the duplicates into a symbol & replacing the others with instances of that symbol?

[gdenby]

How are you using the images? If images are used nested as children inside of objects, even tho a small part of the image is visible, the whole of the image is in storage. So, if you use the same image many times over with different portions showing, all of the instances are repeated in full. If this is what you are doing, try cropping the images so only the portion you need to fit in specific objects.

[R C-R]

2 hours ago, gdenby said:

So, if you use the same image many times over with different portions showing, all of the instances are repeated in full. If this is what you are doing, try cropping the images so only the portion you need to fit in specific objects.

Since cropping is non-destructive by default, I doubt this would make much of a difference unless the additional step of rasterizing each image instance was also done (since that removes the out-of-crop part of the raster image).

 

But I still think using Symbols would be more effective ....

[AmapThom]

Thanks all for your updates. I have a few options to work on now.

 

However I really feel Serif should do something, either:

 

1. Detect that an image has been added multiple times, and point to the same embedded asset instead of duplicating it.

2. Add an option to compress images (even Pow*****nt has it!)

3. Add the possibility to link images instead of embedding them.

 

The options proposed on this thread could help a little, but they're far from being seamless in terms of workflow. And applying them manually on an existing design is going to be painful.

[gdenby]

AmapThom,

 

Perhaps just work with compressed files to begin with, and when satisfied w. the design, swap out the files? I agree, not a very elegant solution, but for the time being, perhaps not too clumsy.

 

It seems to me that the problem is not with the size of the stored files, both the assets and the work files, but the physical memory requirements and processor overhead. I don't know enough about the issue, but if the screen had to be redrawn every time a file was fetched from either memory of storage, and decompressed, and then drawn, it seems to me that at some point performance would be halting.

 

Nevertheless, make a feature request. This helps the developers allocate their time to items required by most users.

 

 

[gdenby]

"Since cropping is non-destructive by default, I doubt this would make much of a difference unless the additional step of rasterizing each image instance was also done (since that removes the out-of-crop part of the raster image).

 

But I still think using Symbols would be more effective ...."

 

I've used symbols too little to say, but it seems that if a symbol served the OP's needs, it would probably function as suggested, a repeated instance of a referenced file.

 

What I was talking about arose from a project I was working on. I found that if a composite form had a bitmap fill, and was then divided, the bitmap remained contained in the resulting individual objects. I was working on a jig saw puzzle. But I was also using the technique to make unusual compositions, transpositions/rotations/etc of tiles that made up a face image, or landscapes, etc.  What I noticed was that the resulting file size was immense. In the case of one of the jig-saw puzzles, the 600 Kb file that was used for the whole was replicated in all 80 puzzle pieces.  I found that if I went to the trouble of dividing the original file into 80 rectangles that extended just beyond the tile shapes, and nested those, the total file size was reduced dramatically.

 

 

[v_kyr]

1 hour ago, gdenby said:

...

Perhaps just work with compressed files to begin with, and when satisfied w. the design, swap out the files? I agree, not a very elegant solution, but for the time being, perhaps not too clumsy....

I vaguely recall that the Affinity file format already uses ZLib compression on raster data, so it shouldn't make that much difference then. - Have to see if I can find those former related posting about growing file sizes etc. here in the forum.

Ah yes, I think it was this thread here, were some of these size related things and storing had been discussed before, just take a look over there too:

• *.afphoto files are getting bigger and bigger

Since AD and AP share their file formats, things should also be applicable for AD here.

Quote

 

Without giving too much away, we optimise and remove duplicate data where possible.  That includes pixel data, and other stuff.

Our files grow in size after any change and save as the main structure of your document is saved every time you do a save.  At the very least, if no other data is changed, the main structure is written again.  Until a streamline happens, old versions of the structure will exist in the file.  When a streamline occurs, the old structure data is removed, leaving just the latest version.

The structure data is quite small, however, compared to pixel data, so changes in a document with lots of pixel data, you could make many saves before the amount of old structure data pushes you to the 33% streamlining threshold.  In this situation, the file would grow with each save.  A Save-As will still give a streamlined file.

 

 

[R C-R]

3 hours ago, AmapThom said:

However I really feel Serif should do something, either:

 

1. Detect that an image has been added multiple times, and point to the same embedded asset instead of duplicating it.

That is in effect what using Symbols does, although it is not limited to items in the Assets panel, if that is what you mean by "embedded asset." Asset panel items are not stored in document files unless they are added to individual documents, at which point they become independent of the Asset panel. Among other things that means if you delete an Asset panel item it does not affect any document that includes an item that came from the Assets.

 

A similar consideration applies for linking rather than embedding: if the linked file is deleted, altered, or not included if the document file is copied or moved to a different computer, it would affect every document that included the linked item. There are ways to deal with this but they add significant complexity to both the app & user management of their documents.

 

Basically, embedding means each file is independent of all others while linking means they share dependencies.