THE FIRST AND VERY OLDEST AFFINITY BUG, SINCE 2016, NEVER FIXED!

[vjsouza]

Please, before do your commentary, see the video til the end.

This is the very oldest Affinity BUG. Perhaps the first of hundreds. Outlived all Affinity updates since 2016. It was never fixed.

Unlike Photoshop, Affinity has no EDIT/PURGE menu. I know, because I've been working with Affinity since its launch in 2016. I've reported this BUG before, but nothing has been done.

Please, please, please, please, add a EDIT / PURGE menu in Affinity Photo, Designer and Publisher, like Photoshop do.

What is the problem?

Create any file with Affinity Photo, with several objects (bitmaps and vectors), save the file, close Affinity. Then open Affinity again and try making changes to the file, like deleting bitmap objects, for example. You will notice that the file size does not decrease even after deleting all the objects. Watch the video until the end.

I mentioned it to a friend, and he recommended that I post the video on YouTube, so the people at Serif take action. But I decided to give the people at Serif one more chance, to see if this time they fix the first Affinity BUG, which has survived undefeated for seven years until today.

01 Original file.afphoto

[herhey]

Even if you delete all the content and resize the document size to 1 x 1 px the file size will not decrease. This is ridiculous...

[Archangel]

Strictly speaking, this is not a bug, but a feature that hasn't been implemented.  It is a very good idea though, and I hope Serif take note and implements something that will provide a similar feature, We wait with bated breath.

[herhey]

I think it should be implemented as an automatic process when saving the file. I don't find any reason why the user should do it manually.

[walt.farrell]

22 minutes ago, herhey said:

I think it should be implemented as an automatic process when saving the file. I don't find any reason why the user should do it manually.

It is not done on every Save because of the design of the files, which are optimized for performance. Changes are written to the end of the file, and the entire file does not have to be read or written at the same time.

We are told that the space will be reclaimed during Save when a certain amount of space would be recovered, or it will be removed during a Save As to a new filename.

[4dimage]

Did you ever watch e.g. Photoshop saving an open file. No matter how big it is. PS creates a temp file, writes the actual RAM content to it and then - on success - replaces the existing file with the just created temp file and the same name. Writing the temp may even be faster because the old file structure has not to be reorganized. And if something goes wrong during the temp file write process, you still have the old original untouched. This is done on EACH save. By the way - this sounds like intrinsic defragmentation as a bonus on top.

There is no magic with this simple file logic - isn‘t it.

[Dan C]

Thanks for your report and our sincerest apologies for the delayed response here. We are exceptionally busy following the release of V2 and we thank you for your continued patience and understanding here.

As confirmed above, this is not a bug within the Affinity apps - and Walts description is correct, when using File > Save the file itself will not be 'trimmed' until more than 25% of the files data is redundant. This is further explained in the below posts from our devs:

I will however move this thread to the Feedback section of the forums, for our devs to consider adding an 'Edit/Purge' option in the future.

I hope this clears things up!

[affinian]

An "Edit/Purge" option is a good idea!

[vjsouza]

There is a "workaround" (in Brazilian Portuguese: "GAMBIARRA") to avoid this BUG (yes, as much as they insist on saying no, this is a BUG!"

1. Group everything in the "unpurgeable" file

2. Copy the group

3. Do "File / New From Clipboard"

4. In the new fresh file, ungroup

5. Save as other name.

 

Although not an elegant solution, it has worked for me, because the "phantom information" is not copy/paste possible.

But it is extremely tedious to have to do this every time you save a final file in Affinity. The EDIT/PURGE command is extremely necessary to implement.

[max1josef]

On 12/8/2022 at 3:47 PM, vjsouza said:

There is a "workaround" (in Brazilian Portuguese: "GAMBIARRA") to avoid this BUG (yes, as much as they insist on saying no, this is a BUG!"

[...]

It does work, but is there a way to also copy the guides to the new document?

Edit: removed observation of almost empty file being saved with 116000 kB. Tried to recreate this from scratch and it worked as preferred. Will examine this further before posting again.

[deeds]

Another tacky way to solve this:

 

Copy a SUPER HUGE bitmap image to your clipboard from finder/explorer

* it must be massive, at least 4096x4096, preferably double that.

 

Paste it into your Affinity document.

Save the file

Delete the pasted massive image.

Save the file... 

 

--- this triggers the flushing. 

[Dan C]

On 12/8/2022 at 2:47 PM, vjsouza said:

There is a "workaround" (in Brazilian Portuguese: "GAMBIARRA") to avoid this BUG (yes, as much as they insist on saying no, this is a BUG!"

1. Group everything in the "unpurgeable" file

2. Copy the group

3. Do "File / New From Clipboard"

4. In the new fresh file, ungroup

5. Save as other name.

 

&

On 12/10/2022 at 9:54 AM, deeds said:

Another tacky way to solve this:

 

Copy a SUPER HUGE bitmap image to your clipboard from finder/explorer

* it must be massive, at least 4096x4096, preferably double that.

 

Paste it into your Affinity document.

Save the file

Delete the pasted massive image.

Save the file... 

 

--- this triggers the flushing.

File > Save As should always create a file which has been 'purged', removing any of the left over data that has not yet been cleared when using File > Save - there should be no need to copy to a new file or force the 25% delta manually

[Napkin6534]

19 minutes ago, Dan C said:

File > Save As should always create a file which has been 'purged', removing any of the left over data that has not yet been cleared when using File > Save - there should be no need to copy to a new file or force the 25% delta manually

👍 great, thanks for the tip. I was also having problems regarding this.

[vjsouza]

On 12/10/2022 at 6:51 AM, max1josef said:

It does work, but is there a way to also copy the guides to the new document?

 

Unfortunately, there is no way to copy guides into the new document. In CorelDRAW the guides are on an exclusive layer, but I also don't know if it's possible to copy them to another document.

[vjsouza]

32 minutes ago, Dan C said:

File > Save As should always create a file which has been 'purged', removing any of the left over data that has not yet been cleared when using File > Save - there should be no need to copy to a new file or force the 25% delta manually

Unfortunately, SAVE AS doesn't work either! I tried to do this with the sample document in this post, but, unfortunately, the resulting file with Save as is still huge. I just eliminated the bitmap and left the two vectors.

[Napkin6534]

5 minutes ago, vjsouza said:

Unfortunately, SAVE AS doesn't work either! I tried to do this with the sample document in this post

Strange, it worked for me.

[Dazmondo77]

6 minutes ago, vjsouza said:

Unfortunately, there is no way to copy guides into the new document. In CorelDRAW the guides are on an exclusive layer, but I also don't know if it's possible to copy them to another document.

Also a super handy, really missed feature from Quark and InDesign - the first thing I used to setup in Quark (back in the day) was master page bleed guides via the transform panel just took a few seconds, and remember it was mind-blowing to have proper bleed guides in InDesign 2 but it was taken for granted that you could use the transform panel and copy paste to quickly and precisely position guides on the page - never been a fan of the horrible guide manager panel and all the guesswork involved on pages with lots of guides, I've even resorted to making physical guides layers in publisher using strokes and snapping, works really well but just a workaround 

[Dan C]

47 minutes ago, vjsouza said:

Unfortunately, SAVE AS doesn't work either! I tried to do this with the sample document in this post, but, unfortunately, the resulting file with Save as is still huge

Thanks for letting me know and I'm sorry to hear this - I've tested this with other files and it appears to be working correctly for me - however I'm able to replicate this issue with your file, indicating a bug with this specific document rather than with the app. 

I'll be logging this file directly with our developers now for further investigation.

In the meantime, you can use Snapshots as a workaround to this bug - I've included a quick screen recording of these steps below, and the resulting file was 8.82MB:

I hope this helps 

[carl123]

@vjsouza

It's the same old snapshot problem...

Open the (70MB) file you uploaded to the forum
Delete the snapshot
Save the file (Not save as...)
Close the file (Important)
Open the file
Make a small change (e.g. add a 1" rectangle)
Save the file (Not Save as...)

File is now 8MB

 

[Dan C]

Many thanks @carl123 and my apologies @vjsouza! 

As I was testing with snapshots myself I had not realised the document created a user generated Snapshot, which is the reason the file is retaining the larger size when performing a save as - and as you've mentioned removing the snapshot significantly reduces the file size - much appreciated

[Pšenda]

On 11/29/2022 at 2:42 AM, 4dimage said:

This is done on EACH save.

So every time you save, say 10GB of data is written over and over again? To a slow external drive? It probably won't be very fast.

[4dimage]

Yes, that may be slower on an external drive. But first, each 1GB LAN to a NAS or USB 3 media have an enormous data rate. Second, and most important, PS does this in an extra asynchronous task. You start saving and are able to continue your work in the open document while PS is saving the data in the background!

The most important thing is, that you have the smallest possible file on your local or network drive. Don‘t forget that all files have to be backuped e.g. typically over night. Depending on your amount of data, filesizes and technique this may take hours. And the more „dead“ redundant data you have in your files the more precious space on your backup media and time is wasted - for nothing.

Or simply think about sharing your design with a colleague or customer. It‘s a big difference if a file is 10 MB or 500 MB…

By the way, if you have one single file of 10 GB you are in trouble anyway. This would be the equivalent of a Hollywood blockbuster media.

[vjsouza]

12 hours ago, carl123 said:

@vjsouza

It's the same old snapshot problem...

What kind of witchcraft is this? It doesn't make any sense, but it works!

[carl123]

The snapshot problem comes up all the time when investigating file size issues

Here's one from last month

https://forum.affinity.serif.com/index.php?/topic/173157-huge-difference-in-file-sizes-with-no-edits-photo/

 

 

1 hour ago, vjsouza said:

What kind of witchcraft is this?

Wow, that's spooky, I actually called it a "black-magic-ritualistic-procedure"  back in this post from almost 3 years ago

https://forum.affinity.serif.com/index.php?/topic/86287-huge-file-size/&do=findComment&comment=572357

 

[Pšenda]

10 hours ago, 4dimage said:

By the way, if you have one single file of 10 GB you are in trouble anyway.

Of course, working with large/huge files is always problematic (high demands on available memory and computing power), but if someone creates high-resolution stacked images, he has no other choice, and therefore it is not advisable to make it even more difficult for him with an inappropriate way of storing data. The technique used by Serif is a completely standard way of working with large data volumes, but it's a shame that it still hasn't heard requests for manual file compression, which is useful, for example, before sharing files or making backups.