Bug: Initial "Save..." creates ~2x larger *.afphoto files than subsequent "Save as..."

[lphilpot]

Photo 2.0.0, Windows 11 Home

When I load an image in Photo and save it as an .afphoto file, it's always much larger than if I subsequently "save as" the .afphoto file to another .afphoto file name. Note I'm saving the second .afphoto from the first .afphoto, not again from the original TIFF.

For example:

1. Load a TIFF
2. Delete the background snapshot
3. Save it as an .afphoto (no edits)
4. Close the .afphoto file and reopen it
5. Make no edits and immediately "Save as..." to another .afphoto

Here's one example:

TIFF is 120MB, first afphoto ("Save") is 291MB, second .afphoto ("Save as") is 135MB. That's almost a 50% drop in file size.

So what's the problem with the first one? I've done this numerous times and they always look identical, but unless I save twice I'm wasting almost 2x drive space on Photo files. Restarting Photo in between makes no difference.

[NotMyFault]

The native file formats are not intended to optimize space, but flexibility and speed wrt Affinity apps. Affinity uses some kind of garbage collector, triggered by some thresholds. In the meantime, files can grow, as edits may use additional new storage instead of old but unused storage.

[lphilpot]

I understand, but there were no edits between the two saves -- Only the name / file change. However, I'm not interested in wasting nearly 2x the space for photos I'll edit "once and done." This isn't design where I'll be going back and revising them, I'm doing them once and they're done. If that's something that's controllable, it would be nice to have an option to optimize for disk space. If AP's macro facility was robust enough, that could suffice in a pinch.

[NotMyFault]

Well, „save as“ is one of the known recipes to reduce file size. 

Your feedback or feature requests are welcome in the „feedback“ section of the forum.

[lphilpot]

7 hours ago, NotMyFault said:

Well, „save as“ is one of the known recipes to reduce file size. 

That's why I posted this as a bug report. To my mind, a bug report should carry more weight than simple feedback and this (IMO) is a bug, even if by design. However, from a development POV I don't see it as being by design. While "Save as.." might be a workaround, it's not a fix. It does, however, prove the problem with the first save.

 

16 hours ago, NotMyFault said:

The native file formats are not intended to optimize space, but flexibility and speed wrt Affinity apps.

If this was video editing / playback / streaming I could maybe understand that, but there's not that kind of "near real-time" performance requirement for photo editing. We push a button, the app does X and we continue when it's done. Anything seriously resource-intensive should be handed off to the GPU anyway. Pre-allocating resources for such near-static operations (if indeed it happens) is wasteful and inefficient from a system viewpoint. For example, allocating memory is as simple as calling malloc() / realloc() / free() or for disk calling fopen() / fread() / fclose(), etc.* While it's possible the actual resources might be expensive on a constrained system, the act of allocating them isn't. The app makes the call and the OS responds (most likely based on what it got back from the hardware via the MMU).

*Here I suspect it's new() / delete() / open() / close(), etc., since Photo is probably written in C++

The point is, there are no significant gains in this context by pre- or over-allocating file resources. Besides, a file intentionally over-allocated at save time would presumably be designed to provide a benefit upon the next open. At that point, disk IO, CPU and other factors would swamp any potential over-allocation gains.

Plus it's just a pain to be forced to save every new file twice.  🙂

[DWright]

Is it possible for you to send me a copy of your TIFF file using the Dropbox link below as I have only been able to get my TIFF file to increase is size on save when I use the option to save back as a TIFF with Affinity layers and if I save as a .afphoto document I am seeing around a 20% size increase

https://www.dropbox.com/request/sAt6k58pLqhjcQIeSGpr

 

[lphilpot]

I just uploaded the most recent TIFF, but I've seen the same behavior in most instances.

Thanks.

[lphilpot]

Also -- Please note the after further investigation this appears to possibly (?) be related to behaviors following deletion of the Background snapshot. I can't say with 100% certainty but that, at least, appears to be a common factor. I have also seen the same file (afphoto) grow incrementally with each unedited save (not Save As...). For example, load the file and save it (it gets larger). Save it again (it gets larger). I didn't go on indefinitely but it happened at least three times. I've not tried to duplicate that behavior since.

It would be a huge help and clarifying change if we could simply disable the automatic creation of the Background snapshot in the first place. Just add a preference to disable it. I don't use snapshots and I have to remember to delete it then go through several saves (Save as...) in order to reclaim the storage space.

Ref:

Thanks.

[lphilpot]

Just another bit of file-saving-and-size strangeness: An example of an unchanged afphoto file getting bigger after I saved it under a new name (with no further edits):

1. Loaded autosave.tiff into Photo:
   2022-12-07  19:52       179,179,156 Autosave.tif
   170 MB
2. Did some edits, a few layers, etc., and saved it as autosave.afphoto:
   2022-12-07  20:17       256,467,384 autosave.afphoto
   244 MB
3. Closed autosave.afphoto, reopened it and immediately saved it as autosave2.afphoto (no edits, note the timestamp):
   2022-12-07  20:19       408,931,181 autosave2.afphoto
   390 MB

I've opened autosave.afphoto and autosave2.afphoto simultaneously and they're identical from every angle I can find (no snapshots, by the way). So why is the second -- apparently identical -- copy 60% larger?

Thanks.

[Affinity Info Bot]

The issue "Non Live Filters are prompting the app to ask if the user wants to save a TIFF with layers or flattened" (REF: AFP-5635) has been fixed by the developers in internal build "2.1.0.1742".
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us.