Huge file sizes with repeated Saves - Photo v2.5.6 Mac

[Ldina]

I'm working on a MacBook Pro M4, Sequoia, Photo v2.5.6.

I opened a 24 MP HEIC file taken with an iPhone 16 Pro camera (launched from the Apple Photos App, right-click > Edit With). It opens as a 16 bit, sRGB file, even though the original iPhone image has a P3 color space, and my RGB Affinity Photo settings are also P3. (I'm curious about that, but that's not the main issue.)

The iPhone file opened originally as a single Pixel Layer. In AfPhoto, I added Live DeNoise, Curve and Sharpening layers, and nothing else. Then I saved it as a native AfPhoto file. The saved file was huge, about 180 MB. So, I converted the still open file to 8 bit to reduce file size and resaved, using Save As and overwriting the original file name. The file size ballooned to over 230 MB! Huh? What? It should have gotten smaller, being an 8 bit file instead of 16 bit. I tried a few more times, trying both Save and Save As, and the file size kept getting BIGGER, no matter what I did. I closed down Photo and reopened it, but I that didn't help. I have NO Snapshots, and do NOT have History being saved with the file. I finally tried Flattening the file, so there was only a single background layer. Repeated Saves or Save As either make the file larger or keep the same large file size. The current file size is now 283 MB, which is insanely large, and this file has only a Background pixel layer, with no other layers.

Out of curiosity, I tried saving the same exact 8-bit, flattened file using a new file name, and the saved file size was 50MB, which is reasonable since it's a fairly big file with pixel dimensions of 5712 x 4284 px (24 MP). Exporting to standard JPEG format, resizing to 1600 px on the long edge, at 85% Quality gives me a file size of 427KB, which is in line with other files of the same size. 

Has anybody else seen this? Any idea what's going on? Or how to fix this?

Thanks.

[lacerto]

I have MacBook Air M3, Sequoia, Photo v2.5.6, and iPhone 16 Pro, and 16-bit HEIC RGB images with Display P3 internal color profile open in e.g. CorelPHOTO-PAINT 2023, Photoshop CC 2025 and PixelMator, when opened for editing from within Apple Photos context menu, in 16-bit RGB TIFF format with "Apple Wide Color Sharing profile", and when opening in Acorn, with Display P3, so I am seeing restricting to sRGB only when opening in Affinity Photo.

As for the file size, an original HEIC file(2316 x 2088px) that took 1.7MB as a HEIC image takes e.g. in PSD format about 43MB, and in TIFF format with ZIP packing about 28MB, and would increase in size significantly with adjustment layers saved, but flattening and saving (without needing to save as) would return to previous sizes, so I do not seem to be able to reproduce the size issue with other apps. But when trying with APhoto, the initial .aphoto size of the test photo was 57MB. It did not increase in size when adding an adjustment layer and saving, but when rasterizing (flattening to a single pixel layer), the size increased to 106MB, and stayed the same even if saving as. Even saving as with a different name does not result in expected decrease of file size: 102MB. This is, indeed, odd behavior.

[carl123]

3 hours ago, Ldina said:

Out of curiosity, I tried saving the same exact 8-bit, flattened file using a new file name,

If you were previously using Save as... without changing the file name, that does not work

You have to Save as... to a new file name to trigger the discarding of any redundant data in the file

[lacerto]

3 minutes ago, carl123 said:

You have to Save as... to a new file name to trigger the discarding of any redundant data in the file

I did exactly that, but without expected discard.

[carl123]

Yes I saw your post

If you could upload that (final) Affinity file, we may be able to analyse it

[Pšenda]

5 hours ago, Ldina said:

I added Live DeNoise, Curve and Sharpening layers, and nothing else.

The problem with huge file sizes is that Affinity uses its files as a kind of working cache, i.e. it stores partial image information in them (of course uncompressed) to speed up work and display. In your case, the information - here is "Live DeNoise", which could only take up a few bytes in the file, is supplemented by a complete image interpretation of the given layer/filter (in full color range and uncompressed). So the file size of the original image data gradually increases.

Plus uses a technique of saving without "cleaning" the file, so when editing and deleting, there are certain fragments of leftovers/clutter left behind, which are cleaned up (and thus the file is smaller) only when a certain limit is exceeded and a SaveAs is performed.

[lacerto]

Here is capture of what happens basically with whatever I have tested. This is a shot saved in HEIC format using iPhoto 16 Pro of a random stock photo, which is then picked from Apple Photos in latest Sequoia for editing (this is deliberate, instead of extracting the original and opening the file, which is currently not possible because Affinity apps do not support the HEIC (HEIF) format Apple uses.

As can be seen, the colors are first truncated to sRGB (instead using embedded wider color gamut like any other app I have tried) and then, when saving, filesize is 96MB, and after applying an effect and merging it, and saved as, 142MB. The image might of course have become more "complex" as a result of adjustment but the theoretical file size required to record the color information of an image of this size and color depth is about half of what was used. I ran the same test in Photoshop and saved in .PSD format and the image size stayed the same, 73,2MB, before adding a Vibrance adjustment, and after having merged the effect and saved as using different filename (and keeping it .PSD). It stays the same whatever is done within one pixel layer (canvas), even if it is just one color, as long as no compression is used. That is the space that it theoretically takes, then there can be extras like embedding a color profile, history, etc. But taking a double what is needed, and more, takes an Affinity aficionado to understand / explain. Anyway, considering that the original takes 1,73MB (and pretty much the same no matter what is photographed), I understand the concern, and the temptation to let Apple Photos do its editing magic, rather than using dedicated "professional" editors 🙂  

 

 

[walt.farrell]

10 hours ago, Ldina said:

It opens as a 16 bit, sRGB file, even though the original iPhone image has a P3 color space, and my RGB Affinity Photo settings are also P3. (I'm curious about that, but that's not the main issue.)

 

3 hours ago, lacerto said:

the colors are first truncated to sRGB (instead using embedded wider color gamut like any other app I have tried

It sounds like the Photos app is converting your image to another format before transferring the image to Affinity Photo. I think that is a common issue with RAW files, and may happen with HEIC, too.

Regarding the file size: as has been mentioned, native Affinity files grow with successive edits until either you do a Save As with a new name, or there is enough "wasted" space for the application to decide to discard/compress it during a normal Save operation. 

[lacerto]

1 hour ago, walt.farrell said:

It sounds like the Photos app is converting your image to another format before transferring the image to Affinity Photo. I think that is a common issue with RAW files, and may happen with HEIC, too.

Yes, it is Apple Photos that does the conversion. It does it whenever a HEIC file (at least in condition of opening a LIVE photo using iPhoto 16 Pro; I have not tested what happens if LIVE is turned off). All other apps that I have tested, however, retain the embedded wide color gamut, and only Affinity Photo has sRGB as the assigned (truncated) profile.

UPDATE: Oddly, if I export "Unchanged original" from Apple Photos, the image has the Display P3 profile embedded, but it is an 8-bit per channel RGB, not 16-bit, as when opening for editing as a TIFF conversion! Not much appears to be documented in what Apple does here, but the size and color issues experienced with Affinity Photo are a separate thing.

1 hour ago, walt.farrell said:

native Affinity files grow with successive edits until either you do a Save As with a new name

I do this on the video, and I think that OP mentions having done so, as well (but also having done at times successive saves using the same filename). 

EDIT: To make it clear, the size issue is ony related to saving as (merged, single pixel layer) data to native .aphoto format. I can e.g. export to 16-bit per channel TIFF and get expected file sizes. Similarly as @Ldina, I can go on adding complexity on the image, e.g. adding multiple adjustment layers, mixing them, but when I merge everything to one pixel layer, and save as to a new .aphoto file, the file size appears to keep on increasing, or stays the same. UPDATE: History is not saved, but something else appears to be accumulating.

EDIT2: Just for information, v2.5.7 has no change to this behavior.

[Ldina]

21 minutes ago, lacerto said:

Yes, it is Apple Photos that does the conversion. It does it whenever a HEIC file (at least in condition of opening a LIVE photo using iPhoto 16; I have not tested what happens if LIVE is turned off). All other apps that I have tested, however, retain the embedded wide color gamut, and only Affinity Photo has sRGB as the assigned (truncated) profile.

With Live Photos turned OFF, it does the same conversions. Depending on what one does to create an "openable HEIC file" in AP, you can end up with 8, 16 or 32 bit, sRGB or Display P3 profiles. The only way I have found (so far) to open a 32 bit linear Display P3 file from an iPhone 16 HEIC is to Export a Full Sized PNG from Apple Photos, Then open the exported PNG in AP. That opens fine as 32 bit Display P3, but is way too bright compared to the original. To correct that, I have to use a Procedural Texture filter for a "Linear to 2.2 Gamma Transform", which then matches the original iPhone 16 HEIC.

As it currently stands, AP isn't a very good option for editing Apple HEIC Photos taken with an iPhone 16. They need to be able to read and write HEIC files properly. Until that is fixed Apple Photo's built in editor is a better option, at least easier, and avoids massive file sizes and a bunch of workarounds.

1 hour ago, walt.farrell said:

Regarding the file size: as has been mentioned, native Affinity files grow with successive edits until either you do a Save As with a new name, or there is enough "wasted" space for the application to decide to discard/compress it during a normal Save operation. 

Thanks to all for the feedback on saved file sizes. Perhaps AP needs a "Strip/Discard and Save" option (or something like that) to save ONLY what one would normally expect to be saved in the layers panel, without that extra "cache". I don't want 283MB file sizes saved to my hard drive for a single layer, 8 bit, 24MP file. I can save to a new filename, delete the original bloated file, rename the smaller 'Save As' version, etc, but again, a lot of silly, unnecessary steps. The only reason I originally used Save As was to save into a new file folder, instead of saving an AP file in the Apple Photos repository.

I'm still not entirely sure how to easily save an "unbloated" AP file.

 

[Pšenda]

19 minutes ago, Ldina said:

Perhaps AP needs a "Strip/Discard and Save" option

I suggested to Serif the addition of this command to remove ballast a long time ago:

 

Although we will never see this, Serif could offer users a choice of two formats (storage methods):
- "file size preference", in which only the necessary data for the reconstruction of its content would be stored, which would of course be slower, and
- "processing speed preference", where the file would also contain accelerating intermediate products, making it several times larger than necessary.

[Ldina]

6 hours ago, Pšenda said:

I suggested to Serif the addition of this command to remove ballast a long time ago:

Thanks. Agreed.

I'm fine with the "currently open" AP file containing whatever cache or speedup routines they require for better performance, but when the file is saved, I'd think it should be saved as intended with only the edits made in the file. If a user does repeated Saves or Save As while working on a file (for safety purposes to avoid unexpected crashes, etc), I'm still fine with the currently opened file being somewhat bloated if that improves performance significantly. But user-initiated saved files (ie, File > Save/Save As) should always strip that "bloat". Perhaps I'm missing something important.

[Pšenda]

2 hours ago, Ldina said:

But saved should always strip that "bloat".

When using these techniques, only a small (necessary) part of the file is saved/overwritten with a record of new modifications, i.e. Save does not save the entire file, but only a small part of it. Therefore, ballast remains in the file, which is removed only when the entire file is written, i.e. when SaveAs. Imagine that you have a file of 100GB, and every time you Save (Ctrl+S) the entire file would be written to the external disk over and over again.

[Ldina]

@Pšenda Thanks, I appreciate your knowledgeable feedback, and that of Carl, Walt, Lacerto and others. At least I have a better understanding of what's happening during the Save/Save As process.

I usually open a DNG and save my AfPhoto file and Exports from AP to the same folder, so I haven't really run into this much before. Now that I am testing and experimenting with iPhone 16 camera captures, and saving to a completely different folder (instead of back into Apple Photos), I'm seeing more of these bloated file sizes. 

Seems to me that "Autosave" could do incremental "saves" while working for speed, but a Save or Save As chosen by the user should probably do a complete file overwrite to eliminate any additional bloat. Like I mentioned, perhaps there are other consequences or downsides to doing it this way. Anyway, I appreciate all the great feedback, folks!! Thanks! 😁👍

[R C-R]

4 hours ago, Pšenda said:

Imagine that you have a file of 100GB, and every time you Save (Ctrl+S) the entire file would be written to the external disk over and over again.

As I understand it, this is one of the main reasons they decided to 'serialize' the native format -- not only does it improve the responsiveness of the app (because a lot of stuff doesn't need to be recreated every time the file is opened) it also dramatically reduces how long it takes to save a file after editing it. And while it should not be a major concern, with modern SSD's it does reduce the wear on them.

But the downside is that the files can get very large before being purged.

[Pšenda]

5 minutes ago, R C-R said:

And while it should not be a major concern, with modern SSD

Be aware that image files can be huge, so even a fast SSD will store such a file for a long time if it is "entirely" overwritten. These techniques are used, for example, in the case of databases, where TB files are no exception.

[R C-R]

1 hour ago, Pšenda said:

Be aware that image files can be huge, so even a fast SSD will store such a file for a long time if it is "entirely" overwritten. These techniques are used, for example, in the case of databases, where TB files are no exception.

Not sure what you mean. It has nothing to do with how fast the SSD is, just how many times data is written to it before it cannot store something to cells that have worn out. When very large files have to be rewritten in their entirety on each save, wear increases because more data has to be written on each save.

[Pšenda]

7 hours ago, R C-R said:

Not sure what you mean.

I apparently misunderstood the context between your two sentences, where in the first you talk about long file storage and in the second you say that this is not a problem with modern SSDs, so I assumed you were referring to the speed of these drives.

8 hours ago, R C-R said:

how long it takes to save a file after editing it. And while it should not be a major concern, with modern SSD's

 

[walt.farrell]

20 hours ago, Ldina said:

I'm still not entirely sure how to easily save an "unbloated" AP file.

"Save As" to a new file name or new directory is the easiest. But there will still potentially be some data you might consider bloat. For example, you may or may not want the initial Snapshot that is sometimes saved in the file, which can be significant. But at least it doesn't grow. And then there is the History, if you've enabled saving that, which can become huge as (I think) each operation may need to save huge chunks of data.

[lacerto]

1 hour ago, walt.farrell said:

"Save As" to a new file name or new directory is the easiest.

I do not understand why people keep on repeating this. I have now tested this with numerous 16-bit per channel images opened for editing from Apple Photos in TIFF format, and saved as .aphoto files. As mentioned, e.g. a file that theoretically takes about 73MB to save its pixel data uncompressed, typically takes about 30% more when initially saved in .aphoto format. When an adjustment layer is applied and merged and the image is flattened to a single pixel layer (clipped to canvas size), it might increase to take double the size that is required to save the data, even if each time saving as with a new filename, in .aphoto format. And this can be continued to further increase the file size. There might be a moment (or even a logical trigger), when purging happens, but I have not found it so far.

I have not tested if this is specifically an issue related just to 16-bit per channel files, but I have not previously noticed these kinds of issues with regular 8-bit per channel images, and it may well be that save as (using a new filename) works consistently there, and purges the file from old stuff. 

Also, as mentioned, when exporting to e.g. TIFF or PSD format, there is no wasted space issue.

The tested files have of course no saved history.

Is nobody else able to reproduce this behavior? (The tests I have done so far have been performed solely on macOS, editing HEIC files saved by iPhone 16 Pro, but I cannot see this significant, other than perhaps in producing 16-bit per channel images for editing.)

[lacerto]

UPDATE: Now I tested this by creating an empty 16-bit per channel RGB image (3000x4000px), then filled it with a stock photo, and applied adjustment layers, merged and saved as an .aphoto file, and cannot reproduce the kind increase in file size as with images initially opened for editing from iPhoto Pro 16 HEIC images (from Apple Photos) -- even if doing this process repeatedly So perhaps there is something involved in these images that causes the file increase...even if I cannot reproduce this in e.g. Photoshop. 

@Ldina, can you see the same, the growth in filesize only happening with the HEIC images converted to 16-bit TIFF by Apple Photos?

Here's the latest edition, a nice iPhoto HEIC shot of our sofa fabric, with initial save, then Vibrance adjustment layer applied (no change), finally merged to one pixel layer and saved as, and puff, double the file size (technically about 70MB is required to save uncompressed this kind of pixel data):  

[Ldina]

1 hour ago, lacerto said:

when exporting to e.g. TIFF or PSD format, there is no wasted space issue.

I developed a 28MB Canon 5Dmk2 DNG file in the Develop Persona using RAW Layer Linked (my standard workflow to reduce file size). No Snapshots, No Saved History. Here are some file sizes saving different configurations:

AfPhoto file sizes
979KB - 16 bit, No Adjustments in AP, saved with Linked RAW file 
1MB -      Added a Curves Adjustment Layer, and used SAVE
1MB -       Added a Curves Adjustment Layer, and used SAVE AS to new filename
281MB - 16 bit, Set DNG to Embedded in Resource Manager - no adjustment layers (Save As to new filename)
154MB - 16 bit, Rasterized DNG - no adjustment layers (Save As to new filename)
154MB - 16 bit, Rasterized DNG plus 1 Curves Adjustment Layer

Exported TIFFs - no compression
121MB - 16 bit TIFF - No Adjustments in AP, Exported with Linked DNG RAW file
61MB. - 8 bit TIFF -  No Adjustments in AP, Exported with Linked DNG RAW file
267MB - 16 bit TIFF - Rasterized embedded DNG, Flattened file
207MB - 8 bit TIFF - Rasterized embedded DNG, Flattened file

It's clear why I used RAW Layer Linked when developing RAW DNG files. Embedded or Rasterizing the DNG results in massive files. I'd expect all 16 bit TIFFs to be about the same size if it is just a single layer. Same with 8 bit TIFFs. 

I was also wondering about working with Apple HEIC or DNG files. The HEIC format, as I understand it, is a container and can hold multiple versions and/or sizes of a file. I wonder if that results in extra bloat. Then again, I'm guessing AP only opens a single format (exported by Apple Photos, Preview or ColorSync). Apple saves their iPhone 16 DNG RAW files using JPEG Lossless, JPEG-XL Lossless, or JPEG-XL Lossy formats. Saving iPhone RAW images using either JPEG-XL compression method always opens in Affinity as a Pixel layer (RAW layer linked or embedded are not available as options). Using standard JPEG Lossless compression (the original DNG specification) will allow you to open a DNG as RAW Layer Linked or Embedded, but the original Apple DNG file is very large. 

For DNG RAW files from my DSLR, Raw layer linked keeps file sizes small. I keep my AfPhoto, DNG, and all exported file formats in the same folder to make sure the linked original is always available. Apple iPhone images are massive when brought into AP as pixel layers. Apple's built-in Photos App Editor works pretty well for iPhone images and keeps file sizes extremely compact, especially if using JPEG-XL Lossy compression (which is still very high quality). Unfortunately, this makes AP a less attractive option for routine editing, unless one is doing special compositing or effects. 

[R C-R]

5 hours ago, Pšenda said:

so I assumed you were referring to the speed of these drives.

No, it was about wear leveling methods & how resistant memory cells are to wearing out.

[R C-R]

1 hour ago, lacerto said:

I do not understand why people keep on repeating this. I have now tested this with numerous 16-bit per channel images opened for editing from Apple Photos in TIFF format, and saved as .aphoto files.

I may have misunderstood what you are referring to but here "Save As..." refers to resaving a native Affinity format file that has been edited & has extra serialized info in it using File > Save as... to remove that excess. For me, it does not always result in smaller file sizes but it is supposed to do the auto-pruning & consolidating of the file.

[Ldina]

38 minutes ago, lacerto said:

can you see the same, the growth in filesize only happening with the HEIC images converted to 16-bit TIFF by Apple Photos?

To me, it's pretty quirky.

I opened a RAW Pro Max image. launched from within Apple Photos (Edit with). It opens as a Pixel Layer with pixel dimensions of 7725 x 5793px, and it opened in AP as an 8 bit P3 file. 

Immediate SAVE AS (to a new file folder, not to Apple Photos) = 26MB
No changes to file, and Save AS to overwrite the same file name = 26 MB
Added a Curve Layer, SAVE AS to a new file name = 26.1 MB
Edited the above Curve (to made a change) and used SAVE = 26.5

All reasonable so far...

Flattened the above file to merge the pixel and curve layers into a single background layer. Save As (over original filename_ = 90 MB
Added, then deleted a Levels adjustment (just to make it a 'modified file') then used SAVE = 90.4 MB

These were all 8 bit files. I haven't tried 16 bit yet. The above makes no sense to me.