Jump to content
You must now use your email address to sign in [click for more info] ×

Recommended Posts

I am working with raw (Nikon NEF) images, which I develop using Affinity Photo.

The .afphoto files that are created upon saving, are really large, even when I only do minor editings.

I have followed some tips from this forum, e.g. setting the document color format to 16 or even 8 bit RGB, then rasterizing the pixel layers again.

This helps for all HDR merges (I usually use 3 NEF raw images for a HDR merge), the file size is reduced from 350MB down to about 40MB (using 8 bit RGB document color format).

But when I develop a single NEF raw image, the file sie is stying with 300MB and is even increasing with each file save. I have some, that are 500 MB.

I must be missing something very essential, can anyone give me a clue on what I am doing wrong when developing a single NEF image?

Handling such large files is extremely unhandy, because i am storing all my work in cloud storage. And uploading/downloading such monsters is not so nice.

Here is an example of a NEF and the resulting .afphoto:

https://1drv.ms/u/s!AhKM_ZAVkY67hrl4P1lP49trCDNNfA

https://1drv.ms/u/s!AhKM_ZAVkY67hrl5sOaRjO4at558bQ

I also attached my settings, when developing the raw image. Setting the output format to 16 bit does not make any difference.

Thank you!

 

MainauRawSettings.JPG

Link to comment
Share on other sites

2 hours ago, UdoK said:

300MB and is even increasing with each file save. I have some, that are 500 MB.

Sounds like you have File > Save History with Document checked. 

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

  • 7 months later...

I have a similar question.  I am seeing the .afphoto file size increase with every save.  (Don't have save with history enabled.)

Reducing the image size increases the .afphoto file size.   Deleting layers increases the .afphoto file size.  Even if I make a change and then undo it, the the .afphoto file size increases when I save (ie- no real change was made).  Granted, there was no reason to save it, but still, by undoing the change and putting the document back to the state it was in when I opened the file, I would expect no change in file size, but, no, it did increase.  What gives here?  This doesn't make sense!

Link to comment
Share on other sites

Do a File > Save as to a new file name and let us know if the file is smaller (and if so, by how much) 

To save time I am currently using an automated AI to reply to some posts on this forum. If any of "my" posts are wrong or appear to be total b*ll*cks they are the ones generated by the AI. If correct they were probably mine. I apologise for any mistakes made by my AI - I'm sure it will improve with time.

Link to comment
Share on other sites

5 hours ago, craigleeus said:

... I would expect no change in file size, but, no, it did increase.  What gives here?  This doesn't make sense!

If Affinity document files were saved conventionally (rewriting the entire file on each save) then indeed it would not make sense. But they are not saved conventionally. Instead, they use a form of serialization that just writes changes to the previously saved file until some threshold is reached & the entire 'deserialized' file is rewritten on the next save. There are some advantages to this, like making most saves (& writing to the recovery file) a quick process that requires very little disk access time.

They have not explained the details of how this works (I think because it is considered a proprietary trade secret) but because of this the file size can increase or decrease for reasons that are not obvious to end users.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

carl123: 'Save-As' to a new name did not have any effect on file size.

R C-R:  Thanks for the explanation.  It makes sense in terms of describing why the file size increases, but makes no sense to me as a developmental approach to saving these files.  Why would anyone want to have continually increasing file sizes? 

Your explanation gave me an idea for a work-around, and it did work.  But it's manually intensive, especially when a lot of files are involved. 

1. Opened an AP file.  Size was 253,636 Kb (which is pretty darn big, but I have some even larger).
2. Then opened a new blank document with same size, dpi and ICC profile as doc opened in step 1. (both docs are now open)
3. Then copied all layers from original doc, pasted to new doc.  Saved the new doc and the size was greatly reduced to 73,552 Kb

I played around with Photoshop files and it does behave the way one would want.  Deleted a few layers and the file size got smaller (in AP, it got larger).  Not hyping PS, AP is a good app, but there is some room for improvement and this, to me, is definitely one area.  (PS- if I have save history enabled, then I would expect the file size to increase even if net-net nothing changed except added history (like making changes then making more changes to revert the previous changes back)).

I appreciate the comments.

Link to comment
Share on other sites

1 hour ago, craigleeus said:

. Opened an AP file.  Size was 253,636 Kb (which is pretty darn big, but I have some even larger).
2. Then opened a new blank document with same size, dpi and ICC profile as doc opened in step 1. (both docs are now open)
3. Then copied all layers from original doc, pasted to new doc.  Saved the new doc and the size was greatly reduced to 73,552 Kb

One thing that is not copied to a new file is the initial snapshot "layer" which can account for a big chunk of a file's size.

If you can upload the 256, 636Kb file we should be able to determine exactly how much of that file's size is down to the snapshot and maybe what else is contributing to the large file size.

This forum corrupts large uploads at times so you may want to provide a dropbox link to the file if you are willing to share it publically

 

To save time I am currently using an automated AI to reply to some posts on this forum. If any of "my" posts are wrong or appear to be total b*ll*cks they are the ones generated by the AI. If correct they were probably mine. I apologise for any mistakes made by my AI - I'm sure it will improve with time.

Link to comment
Share on other sites

I had already overwritten the file in question, but I did the same with another large file.  On dropbox is the "original" afphoto file (332,333 kb) and a new one created using the procedures I described (89,083 kb).

Also attached is the original RAW file brought into the Develop Persona (24,416 kb) for this project.

Link: https://www.dropbox.com/sh/b25mbzmaerehuxc/AAAILWwqa0whMGormQ1KEiPGa?dl=0

Really appreciate your interest in looking at it.

Craig

Link to comment
Share on other sites

In my opinion, one thing we would really need is the “Minimise File Size on Save” option alluded to by the developers some years ago:

https://forum.affinity.serif.com/index.php?/topic/19534-huge-file-size/&tab=comments#comment-90821

I must confess, it has become incredibly cumbersome to archive .aphoto files. I would be interested in how people are actually creating file archives using the current document format (all layers preserved, no history saved), other than buying ever new hard drives or getting new cloud storage plans. Hmm. :(

Link to comment
Share on other sites

That's what it comes down to for me, and what got me looking closer at this.  (Note, I have only been using Affinity Photo for about 4 months -- I still have an Adobe CC subscriptions for Photoshop/Lightroom.)   I noticed that my hard drive was filling up quickly.  I sorted my afphoto files by size (Windows) and was surprised at the file sizes.  Then I started to notice that every time I saved, even when I had deleted layers or reduced the image size, the file size continued to increase.  And, the larger the file size, the more Kbytes were added with each save.

To me this is a really negative issue for AP

I should add, then even though I have a Photoshop subscription, I would love to drop it, but Serif's Affinity Photo, as good as it is, and it is good, still doesn't have the meat to stack up to Photoshop.  (Then again, I readily admit that for the price, my expectations shouldn't be too high and I applaud the work Serif has done.)  :-)

Link to comment
Share on other sites

OK your original file when I download it from the dropbox link is 324MB

When I immediately do a "Save as..." (to a new file name) it is 269MB

This is normally the baseline I start with as doing a "Save as..." (to a new file name) is supposed to get rid of all the serialization in the file and save it as its lowest possible file size (fair enough)

Now when I delete the snapshot, (which is automatically created on opening a file),  the file size drops to 89MB. So it seems the snapshot is taking up an incredible 180MB of the 269MB file.

Now, according to previous statements from the Devs the file format is optimized for performance rather than file size which is why Affinity files are much larger than what we may have been used to when using something like Photoshop. And to their credit, they may well have indeed created a new, performance-based, file format that is light-years beyond what other players in the industry have today.

But it still leaves the problem of the humungous file sizes we are getting when using the apps and there are three things in particular that are puzzling to me.

1. Why don't we have an option (preferences setting) to not create an initial snapshot when opening a file? I don't think I have ever had to revert back to that snapshot and all it does is increase the size of every file I work on.

2. Why is it so complicated to delete the snapshot. Sure you can delete it in the app easily enough but if you do a "Save" or "Save as..." the file size does not decrease because the snapshot is still present in the file.

To actually delete the snapshot you have to...

Delete it in the app
"Save" or "Save as..." the file.
Close the document.
Reopen the document
Then do another "Save" or "Save as..."

Only then does the snapshot actually get deleted and the file size decreases.

3. Doing a "Save as.." is supposed to get rid of all the serialization in the file and save it as its lowest possible file size (fair enough, that seems to work) but it only works if you "Save as..." to a new file name. Why does it not work if you "Save as..." and just overwrite your original file name?

This means I am constantly having to do a "Save as..." (to a new file name) to ensure I am working with a document that is optimized to its smallest possible file size. 

Which means I get left with numerous versions of the document I am working on which are just taking up additional space on my hard drives (and cloud backups etc) which at some point I have to remember to go back to and to clean them up (i.e. delete them). 

It would be so much simpler if a "Save as..." to the same file name would also perform the file size optimization just like a "Save as..." to a new file name does.

 

So in my daily use of the Affinity apps I have to regularly be doing multiple "Save as..." (to a new file name) to optimize the file size and also remembering how to do that black-magic-ritualistic-procedure to get rid of a snapshot I did not create and never ever need.

 

Crazy stuff

To save time I am currently using an automated AI to reply to some posts on this forum. If any of "my" posts are wrong or appear to be total b*ll*cks they are the ones generated by the AI. If correct they were probably mine. I apologise for any mistakes made by my AI - I'm sure it will improve with time.

Link to comment
Share on other sites

6 hours ago, craigleeus said:

Why would anyone want to have continually increasing file sizes? 

It isn't continually increasing. Like I said, when a certain threshold is reached, the file is 'deserialized' automatically on the next save. We just don't know how that works or have any control over it, other than (at least in theory) using "Save as" to write a new, deserialized version of the file.

There are also other factors involved that contribute to fluctuating saved file sizes. As mentioned in one of the posts in the other topic, the Affinity native file format is optimized for fast loading of saved files. Again, we don't know the details of how that optimization is done, but we do know that unlike most other graphic apps the Affinity ones do not normally attempt to load the entire document file into memory at once, instead only loading parts of it as they are needed. (I have the impression this is sort of like how database apps implement random access to records in large db files, but that is just a guess.)

We also know from the other post that "multiple copies of images at successively smaller resolutions" (mipmaps) are stored in the file, & that they are somehow involved in providing fast screen renders at different zoom levels & when panning the view.

Add to that everything else that needs to be stored in a native format document file. For instance, in your 340 MB "Original_DSC2989.afphoto" file, you have 5 adjustment layers, two live clarity filters, several masks, & two copies of the photo (one of which is hidden & both of which are larger than the current canvas size & rotated slightly), & one snapshot. From the EXIF panel, it appears that the original photo was 2606 x 1629 px, but the document is somewhat larger at 3166 x 2111 px (& not quite the same aspect ratio), so I am guessing you scaled it up at some point before saving it.

So considering everything that .afphoto file includes & everything that has been done to it, it should not be too surprising that it is so large to begin with, or that its file size may increase by varying amounts depending on how it has been modified. One example of that is if I just change the locked background layer to visible, which has no visible effect & (I assume would not result in any change in the mipmaps), the file size does increase, but only by less than one MB.

Granted, this is many times larger than a "flat" single layer, original pixel size & unrotated version stored in the .afphoto format would be (about 32 MB on disk, including a snapshot, as in this flat copy of DSC2989.afphoto) but the real question is how much smaller could the multi-layer version be made without compromising fast loads & saves, smooth pans & zooms, non-destructive 'undoable' edits, or any of the other things that these large native format file sizes contribute to or depend on.

Without knowing much about how it all works I don't think we can do anything other than make wild guesses about that. :(

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

As a new user @UdoK may not be aware that afphoto files were made some 4 to 10 times larger with the introduction of version 1.7 in order to accommodate features in Affinity Publisher. Apparently the enormous file sizes were an unanticipated consequence of this accommodation.

https://forum.affinity.serif.com/index.php?/topic/87912-170380-huge-file-size-when-saving-16-image/&do=findComment&comment=527013

https://forum.affinity.serif.com/index.php?/topic/60854-why-is-afphoto-file-so-massive-when-saved/&do=findComment&comment=550689

I began using Affinity Photo about 2 years ago with version 1.6. I keep that version installed on my other computer. In version 1.6,  afphoto files were only slightly larger than the original jpg files being edited. Version 1.7 was something of a disaster for those of us thinking we would retain afphoto files indefinitely should our increasing skills or altered requirements inspire us to return to old work.

My impression is that Serif is far less concerned with making a robust photo editing software than with creating some kind of desktop publishing suite for the Mac. After two years of using Affinity Photo I have seen only a degradation in usefulness, not the kind of advances I had expected when I read the advertising hype about Affinity Photo being the future of photo editing. Serif seems to be falling further behind the innovations being introduced by its competition.

We are told that afphoto files are designed not for efficient storage but for rapid loading. I wonder how much smaller the afphoto files could be made if they loaded in 1 second instead of tenths of a second. I'd gladly settle for slower loading, which is a seldom used procedure, in favor of a return to the small file sizes that allow long term storage.

Some mention that allowing the file to grow enormously allows for faster saves. I have considerable experience with database software that implements rapid updates by simply moving entire modified records to the end of the physical data file and marking the original space as available for storing shorter records. Such systems have utilities for compacting the database from time to time. Serif might want to add a utility for compacting the enormous afphoto files for those of us who do not need rapid loading nor whatever kind of integration with Publisher that these enormous file sizes enable.

 

Affinity Photo 2.4.0 (MSI) and 1.10.6; Affinity Publisher 2.4.0 (MSI) and 1.10.6. Windows 10 Home x64 version 22H2.
Dell XPS 8940, 16 GB Ram, Intel Core i7-11700K @ 3.60 GHz, NVIDIA GeForce RTX 3060

Link to comment
Share on other sites

47 minutes ago, Granddaddy said:

Apparently the enormous file sizes were an unanticipated consequence of this accommodation.

Nope. As @walt.farrell mentioned in a reply in one of the other topics, that huge increase in file size is caused by saving a jpeg original (which uses lossy compression to significantly reduce file size at the expense of discarding a lot of detail) in the native Affinity file format, which among other things doesn't use lossy compression.

Following the trail of links eventually takes one to this followup post by @Mark Ingram which should clear up any confusion about that.

1 hour ago, Granddaddy said:

We are told that afphoto files are designed not for efficient storage but for rapid loading. I wonder how much smaller the afphoto files could be made if they loaded in 1 second instead of tenths of a second.

The format isn't designed just for rapid loading. It is also designed so that just the currently needed parts of files can be quickly & efficiently loaded into memory (similar I suspect to how database apps do not need to load an entire database into memory or sequentially read through the entire file to access a single record). This in turn contributes to unusually high memory efficiency, which among other things means fewer performance robbing swaps with VM & the capability of working on huge raster images without having to rely on dedicated scratch disks.

Besides, it isn't just about reducing load (or save) times. It is all part of the effort to optimize the Affinity apps to be as responsive as possible while documents are being edited. 

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

You guys have an impressive understanding of the weeds of AP.  

Question: What's the difference between the 'snapshot' and the background (original) layer?  Does AP place a second copy of the original image into memory and then pass that to the file when saving?


Correction: in a previous post, I mistakenly said that for the image in question, I opened a RAW file in Develop Persona. In fact, I edited it in Lightroom, exported to TIF and then imported that to AP.  [I just placed the TIF file in Dropbox (same link). 140,658 kb.]


Clarification: In AP when I originally worked on this image, I reduced the TIF/RAW dimension from 6000x4000, and along with some cropping ended up with 2606x1629.  I did increase the DPI from 240 to 300 in case want to print.  Overall, though, this is a significant decrease in total pixels.  Unlike Photoshop, this doesn't seem to have much effect on file size.

More testing today:   
Today, our of curiosity and considering what I've learned from your posts, I put that TIF file in AP again (like I'm starting over).  This time I immediately 'saved-as', without any adjustments.  AP file size on first save: 332,333kb (for an unadjusted 140,658 TIF file).  Wow!  Did it get so much larger because of what I asked previously in this post--AP stores the actual working file and a copy (snapshot) in memory?

Continuing my test today, I then, without any adjustments or even closing the file in AP, 'saved-as' again, this time to a new name.  AP file size now dropped from 332,333 to 181,259!

This is all very confusing.  We should not have to dig through a mass of forum posts and trial-and-error to understand this and how best to handle it.

 

Link to comment
Share on other sites

3 minutes ago, craigleeus said:

You guys have an impressive understanding of the weeds of AP.  

Not really. It is just that some of us have been following the forums for so long that we have accumulated a collection of a few tidbits of info about some of the 'under the hood' stuff that the staff have mentioned from time to time over the years. But since the details of how it all works are considered proprietary info, there is much that is still unknown & a fair amount of guesswork is involved in trying to put it all together into a reasonable "big picture" view.

So for example it is unclear exactly what data is stored in snapshots. But since they store a snapshot of some state of the entire document (thus the name), it almost certainly is not a complete 'linear' copy of every layer, "Background" or otherwise, that the document might contain. My best guess is they record some kind of incremental differences between document states (& that this is used to support both the History & Snapshot features) but I have no idea exactly how that data is stored in the file.

41 minutes ago, craigleeus said:

Today, our of curiosity and considering what I've learned from your posts, I put that TIF file in AP again (like I'm starting over).  This time I immediately 'saved-as', without any adjustments.  AP file size on first save: 332,333kb (for an unadjusted 140,658 TIF file).  Wow!  Did it get so much larger because of what I asked previously in this post--AP stores the actual working file and a copy (snapshot) in memory?

To begin with, TIFF supports various amounts of lossless compression so some of the difference could be due to that. As mentioned, AP also stores mipmaps in its native format files, so (again just guessing) files that include large raster images probably need proportionally more file space for them & for what (if any) supplemental mapping data might be included than would ones with smaller images. I also know from browsing through document files with a text editor that there is a considerable amount of (probably not directly image related) data that seems to be padded with zeros, presumably to facilitate reading chunks of the file into memory using fixed offsets or something like that.

So, take this for whatever it is worth. I think it is reasonably correct in a very broad sense, but nothing beyond that.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

Nonetheless, the file sizes are still too large. I appreciate the loading speed and the unrivalled snappiness of Affinity Photo, but as long as we can’t create a reasonably small .aphoto file for archival purposes, the file format remains cumbersome to work with in a long-term perspective. This is a real issue that cannot be discussed away, in my opinion – as well as in my experience (from which my opinion is derived, obviously). What about an option of exporting to some kind of .afarchive format, for instance? :)

Link to comment
Share on other sites

1 hour ago, A_B_C said:

Nonetheless, the file sizes are still too large.

OK, but how large is too large for a file that still retains the complete parent/child layer structure, the masks, non-destructive adjustments & live filters, & so on of the native file format?

Or put another way, in some proposed .afarchive format, what could be stripped out that would reduce the file size substantially, yet still preserve everything that a regular .afphoto, .afdesign, or .afpub file includes, less mipmaps, snapshots, & whatever else might be considered overhead? If I were to open one of these archive files, could I still edit it in all the same ways I could with the regular version?

 

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

How could I answer this question, R C-R? As you had explained yourself somewhat earlier in this thread, we virtually don’t know anything about the common file format of the Affinity apps, other than what has been described by the developers. And this description almost exclusively detailed the goals and objectives that were followed in developing the file format, not so much the actual means by which these goals were attained. As Dave Harris and others had explained several times and again, the format was developed with loading and saving speed and efficient memory management in mind, not with a view to achieving the smallest file size possible.

Now, as I said, I cannot answer your question, but if it’s possible to optimise a file format for speed, why shouldn’t there be strategies to develop a translation into a file format that’s optimised for storage space efficiency? Why would Dave Harris have talked, in the post already linked, about a “Minimise Space” (file size) option that has “not happened yet,” if that was entirely impossible?

For instance, Ben seems to say in this post, that embedded images are (a) stored in full resolution and (b) stored together with scaled previews for fast loading in an Affinity file. In an .afarchive file, I imagine you could entirely discard these preview versions. But you will surely agree that it doesn’t really make sense to suggest this, as there is no file format specification we could rely on for discussion. Such speculations could easily be beyond the point. From a user’s perspective, I can just point at the problem here, not make any suggestion towards a viable solution. :)

Link to comment
Share on other sites

4 hours ago, A_B_C said:

How could I answer this question, R C-R?

I wasn't really expecting anyone to do that, just sort of 'thinking out loud' about how much file space could be saved if, for example, everything was eliminated that had no other function than to facilitate faster loads & saves. 

4 hours ago, A_B_C said:

Why would Dave Harris have talked, in the post already linked, about a “Minimise Space” (file size) option that has “not happened yet,” if that was entirely impossible?

Part of what he said in that 2016 post was "I think we will have to do something before Publisher, because Publisher documents could be hundreds of pages and have a lot of images." Publisher has arrived & it looks like what they have settled on for that is file linking, so far fully supported only in Publisher but hopefully eventually in the other apps as well.

I don't think file linking is the way to go for an archival format -- for one thing it would be too easy to omit or delete some linked file & not notice that until months or years later. Regarding what Ben said in 2016, there is still the issue of embedded image files at different & possibly higher DPI values than the document, so even if the embedded scaled versions are omitted, there may not be much file space saved. Snapshots present a different problem: sometimes I create one or more snapshots as a reference for future work (& to use with AP's undo brush) so it may or may not be a good idea to omit them from an .afarchive file.

Basically, I am just wondering if a reduced file size version intended for archival purposes would be practical enough to justify developing it, or if it would see much use unless that version was consistently much smaller than the normal one. I suspect very few users would bother with it unless it could average at least a 30% reduction, & most would not unless it could do far better than that.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

This has been an interesting discussion (for a newbie).  Last couple days I played around with different scenarios to understand it all a little better.

I am now fairly convinced that faster file saving is the primary driver for saving incremental changes in AP, much like doing incremental backup for you computer speeds that process.  And I can attest that saving Photoshop PSD files is quite a bit slower than saving afphoto files.

I have a feeling that the reason 'save-as' new files are smaller is that the process uses just the incremental changes needed to create the new file and discards the rest.  A layer is added then later deleted.  It created incremental increases in file size, but for the new file, it's not needed.  If there's enough of those, it could amount to a pretty big decrease in file size.

There was a comment on snapshots being a possible factor, so I dug into that, learning what they are and all.  I found adding snapshots adds very little to the file size.  If I save the file to a new name, all the snapshots came over just fine.  (I'm glad i learned about those -- that's a nice feature!)  I don't see snapshots as a factor in file size.

There were some comments about maintaining a full resolution image being a contributor to added file size.  This is probably valid.  Unlike AP, keeping a full resolution image in Photoshop is optional.  By default the image layer is destructive.  To maintain the original resolution image content, one must convert the image layer to a 'Smart Object'.  When that is done, the PSD file size increases significantly.

I dropped my 141MB TIF file in PS-   (1) just saved as a PSD (no smart object): 141 MB;    (2) converted background layer to smart object and saved: 379MB;    then (3) put TIF in AP and saved to afphoto file: 181MB.  Advantage:  AP.

 

 

Link to comment
Share on other sites

6 hours ago, R C-R said:

Basically, I am just wondering if a reduced file size version intended for archival purposes would be practical enough to justify developing it.

It is not just about the current suite of Affinity apps, R C-R. Just think of the Affinity DAM envisioned some years ago. How could this work when simply developing a RAW file results in an .aphoto file that has seven times the file size of the original RAW? :/

Compare.png.ef03161d5f498306e69bf099bd081e8e.png

Link to comment
Share on other sites

1 hour ago, A_B_C said:

It is not just about the current suite of Affinity apps, R C-R. Just think of the Affinity DAM envisioned some years ago. How could this work when simply developing a RAW file results in an .aphoto file that has seven times the file size of the original RAW? :/

I'm sorry but I do not see how that is relevant to what is being discussed here.

To begin with, if all you are going to do is develop a RAW file, you can export it to 8 bit or 16 bit TIFF for future or archival use & never save the .afphoto version to begin with. Depending on the compression used it is still may be larger than the RAW file, but that is because RAW files generally contain no more than 12 or 14 bits of color data.

But more to the point, it still reduces to how much smaller any native Affinity format file can actually be made for archival purposes without sacrificing any feature that format supports that is not there exclusively to provide faster loads & saves. For example, we know that snapshots do not require a lot of additional file space, & there are reasons retaining them in an archived version may be desirable. Retaining full resolution versions of "(Image)" layers does add significantly to file size, but do we really want to sacrifice the ability to resize them non-destructively in an archived version of the file?

There are already a few things we can do to reduce file size, like merging layers & then using "Save as" to create a smaller version, or (at least in Publisher) linking instead of embedding images, but there are reasons they would not be the most desirable approach for archival purposes.

So it really can't  just be about accepting longer load & save times, or just about poorer memory efficiency, or manual control of if & when files are deserialized, or living with slower pans & zooms if the mipmaps that accelerate that are purged from the archival versions. It has to be about how much of everything the native file format makes possible taken together that we are willing to give up to get smaller files, & how much smaller they have to be to make that worth doing.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.