File size

[AligaThor]

Hello, 

I recently purchased Affinity V2 as an architecture student. 

My documeny size is a 2A0 in 300dpi. Save history is not enabled.

My problem is the file size: 1.3gb. It continues to grow after each save. I don't know if it's a bug or if I'm doing something wrong but it becomes impossible to work on this file.

I tried deleting each layer leaving just a single pixel layer and it's still 800mb...

Any help? 

 

1125759935_Planmasse.afpub

[MikeTO]

Hi and welcome to the forum.

If you're not using linked images, you likely have embedded images in this document. Open the Resource Manager, select all the images, and switch them from embedded to linked. Save your document and it will get smaller.

If you are already using linked images (I didn't check, I didn't want to download a 1.3gb file), there is be an issue that formerly was restricted to M1 Macs that a couple people have now reported on Windows. Open the Resource Manager, select all the images, make them embedded (it will take a few moments), and then make them all linked again. Save your document and see if it gets smaller.

Good luck!

[AligaThor]

Thank you for the quick reply!

Unfortunately, I only use 2 images that are already linked. I tried your solution anyway but without success.

I just copied each layer to a new document. This document is therefore the SAME but only weighs 300mb...

I don't know why...

[MikeTO]

2 hours ago, AligaThor said:

Unfortunately, I only use 2 images that are already linked. I tried your solution anyway but without success.

I just copied each layer to a new document. This document is therefore the SAME but only weighs 300mb...

I don't know why...

A new document with 2 linked images is 300MB? It should be tiny so something is definitely wrong.

[4dimage]

@AligaThor

Sorry, but can‘t download a 1.2GB file…

Can you provide some screenshot of an overview of the drawing? Maybe you choosed the wrong aproach for your project. 300dpi pixel layer in 2xA0 is definetly not the way to go. Or is it a photorealistic drawing?

If you do architechtural line drawings or something similar it may be better to use only resolution independent vector elements.

Internal pixel layers and layer masks might be stored uncompressed within the Designer document. Therefore the file might be that big.

Always try to use pure vectors whenever possible.

[4dimage]

@AligaThor

Hi, i downloaded your big file and inspected the elements. There are a lot things to optimize here. The biggest issue is the use of pixel layers and masks with this high document resolution of 300dpi. In your drawing this isn't really needed because almost all areas are plain colored shapes - no photorealistic textures ore something like that.

Avoid redundant (non visual) pixel information. Means huge pixel layers that are masked out but stil contain pixel information

Chose a document resolution as low as posible that at least technically/visually fits the purpose

Avoid layer masks (pixel) - use clipping pathes (vector) whenever possible

Maybe document color mode RGB (3 color channels) would do it for this purpose (colored shapes). CMYK stores 1 additional color channel in every colored pixel layer!

 

Here some of my proposals/optimizations:

 

1) First of all: for this huge architectural plan the document resolution might me far to high. Precise lines and shapes are resolution independent vectors anyway.

 

2) The satelite pixel image is originaly totally lowres (maybe 72 dpi snapshot from Google). So the information in the original image is totally lowres anyway. To pump this up to a DIN A0 pixel layer with 300dpi is wasted pixel with no additional information stored in it. If you zoom in the satelite images is totally squished anyway.

Zoom in - no plus information:

I exported the map pixel layer as a simple JPG with only the 1/10 resolution. with almost the same amount of information in it -> satelite_lowres.jpg file now is 2.5MB.

I linked the satelite image JPG into a image frame and deleted the old internal 300dpi pixel layer.

 

 

3) There are several layers that should have been drawn as pure vector - of course they show only plain colored shapes. Deleting some of them instantanuosly drops the filesize. Especialy some of them are a compination of pixel layer with pixel layer mask (not clipping path). For this purpose this is wasted pixel infomation because the shapes are visually simple colored areas. Use simple pure vector forms for this.

Deleting e.g. this pixel layer group "Verdure" drops the filesize from 1.x GB down to about 130 MB !

Keep in mind: with a document resolution of 300dpi and color mode set to CMYK you get a colored pixel layer (4 channels) at 300dpi + a grayscale mask pixel layer at 300dpi. Both about DIN A0 sized.

 

Of course drawing all the shapes by hand is more work, than use the bucket fill with the Photo persona.

A quick and dirty trick to solve your actual propblem might be to reasterize the resulting group after finshed work. This drops the document filesize from 1.x GB to about 290 MB - this layer group only! With rasterizing this masked layer pixels which where masked out are striped away from the resulting pixel layer. So after that there is less ununsed information in this layer -> file.

 

 

By the way: this is a typical example why an even basic vectorizing function would be a really helpfull addition to the Affinty products. Compare the efforts to draw all shapes by hand or instead use the bucket fill and then finaly vectorize the shapes ! This would help all users with simliar workflow - add new Elements to existing drawings, fill areas with colors to emphasize them...

I use this fast workflow for decades in Photoshop: magic wand selection -> create working path from selection -> have a rather precise vector path -> do whatever you want...

 

 

In the emeded Parcelles.afpub there are also some pixel masks instead of vector clipping pathes. Replace layer masks with clipping pathes whenever possible.

 

 

 

If you have to use pixel layers and bucket fill workflow to be more time efficient - consider this: maybe it's sufficient to lower the document resolution right from the start. Maybe 150dpi or even 72dpi is almost sufficient for filled shapes. Think of your computer display. It has some 72dpi resolution. Isn't this visualy sufficient for a huge DIN A0 plan that is not viewed from 10cm distance For this technical purpose some jagged line edges might be acceptable. If not - allways use the best alternative: pure resolution independent vectors...

 

Sum up

This is my file with some optimization - only the first quick steps. Can't fix all of your work

1125759935_Planmasse_modified_1-3.afpub

- Original filesize 1.35 GB - now only 208 MB - this is not the end

- I couldn't lower the document resolution because this resized all existing elements 🙄

- The satelite image is an external linked file

 

AND BY THE WAY - again finally ended up with trying to save file as -> crash -> file destroyed -> rebuild last steps from earlier version !!!

This v2 release is a complete mess 😤

 

[AligaThor]

Thank you very much for your answer!

I recently switched from hand to computer. Clearly don't know enough about it.

I will try your optimization solutions.

Nevertheless, I still don't understand how my file could go from 1.3gb to 300mb by copying exactly the same layers to a new file...

Thank you for your time!

[4dimage]

You're welcome. I do this stuff for almost 30 years now - should have learned some little things over the years

[François R]

11 minutes ago, AligaThor said:

Nevertheless, I still don't understand how my file could go from 1.3gb to 300mb by copying exactly the same layers to a new file...

This is most likely due to a design choice where all data is placed at the end of the file by default, even if there is space in the middle - or that there is no free contiguous space inside the file for new data. If data is stored in chunks separated from each other in the file - i.e. not contiguous - then the file as a whole is messy - fragmented. And that costs performance.

At some point, the file is so fragmented that it reaches a pain threshold (numerical value) set in the application for when the file MUST be defragmented. Then all the data is saved all over again in a coherent order. This is clearly what can be seen when selecting Save As. Obviously you assume that the customer is ok with a little extra waiting time.

I guess Serif has chosen the current file architecture for performance reasons, but as you can see, it's not a free lunch. And there's some problem going on, because the file sizes mentioned make it sound to me like there's something else wrong on top of what I've explained.

But as described, file sizes do not reflect 1:1 how much document data they contain. They merely reflect how much data the application has spent on storing that document data. There are many explanations for file sizes: document standards, compression or no compression, effective compression or light compression, binary data or text (XML for example), performance considerations, laziness, incompetence and bugs. And more.

Spending GB after GB in files in a cheap application occasionally run on expensive hardware (MacBooks etc.) has spawned some unhappy posts in here. It adds up, of course, when customers have multiple publisher documents stored.