*.afphoto files are getting bigger and bigger

[Michail]

AP files are getting bigger and bigger. Each image processing step makes the file size larger. I do not create layers or channels, and the log history I do not store. After exporting to Tiff or PSD, the files are much smaller.

 

What does Affinity Photo actually save? Can I clean up the file? I do not want to have unpredictable filemonsters.

[brunzenstein]

Don't log the history and your getting smaller sizes.

I prefer to let it on and be on the save side..

[Michail]

Don't log the history and your getting smaller sizes.

 

I do not understand why a file should be smaller if I additionally save the history.

[brunzenstein]

I do not understand why a file should be smaller if I additionally save the history.

I said:

The file gets smaller if you DONT save the history

[Michail]

I said:

The file gets smaller if you DONT save the history

 

Excuse me for misunderstanding. I had already written that I did not save the history. Nevertheless, the files become disproportionately large.

[Michail]

How do I get the AP files smaller?
A file with 2000x1200px, without layers, without channels and without history, can not be more than 100 MB!!!

[Asser82]

Hm, interesting question. Is something missing if you reopen the TIFF compared to AFPhoto file? Maybe the TIFF uses compression and AFPhoto not?

[brunzenstein]

AP files are getting bigger and bigger. 

Have you checked your resolution settings?

[Michail]

Hm, interesting question. Is something missing if you reopen the TIFF compared to AFPhoto file? Maybe the TIFF uses compression and AFPhoto not?

I have now exported a 100MB AP file to TIFF. After storing the TIFF file in AFPHOTO format, the file size was only 7MB.

This is all very puzzling. And it is not acceptable!

 

 

Have you checked your resolution settings?

What do you mean with resolution settings?

A file is e.g. 2000x1200px large. So everything is said.

[James Ritson]

Michail, raster information in .afphoto documents is stored completely uncompressed. If you're working from raw files, those are developed to 16-bit. 16-bit uncompressed raster information is quite large!

 

If you don't need the extra precision, you can try converting to 8-bit via Document>Colour Format before saving your document. If you've already saved it, try Save As to create a fresh copy with no redundant data.

 

Additionally, when you develop or begin work on an image, an initial Snapshot is created so you can always revert to the original image. This takes up space too, so you may want to delete it. If you go to View>Studio>Snapshots to display the panel, you can then click on the Background snapshot and delete it (the bin icon).

 

Hope that helps.

[Asser82]

Michail, raster information in .afphoto documents is stored completely uncompressed. If you're working from raw files, those are developed to 16-bit. 16-bit uncompressed raster information is quite large!

 

If you don't need the extra precision, you can try converting to 8-bit via Document>Colour Format before saving your document. If you've already saved it, try Save As to create a fresh copy with no redundant data.

 

Additionally, when you develop or begin work on an image, an initial Snapshot is created so you can always revert to the original image. This takes up space too, so you may want to delete it. If you go to View>Studio>Snapshots to display the panel, you can then click on the Background snapshot and delete it (the bin icon).

 

Hope that helps.

 

Hi James,

 

after reading your suggestions, I have found a strange thing here:

 

uncompressed 16 Bit TIFF (102 MB) -> 16 Bit AFPhoto (102 MB) -> Document Colour Format to 8 Bit RGB -> 8 Bit AFPhoto (137 MB)

 

Tested with Release Build and latest Beta. History and snapshots are empty.

The only possible reason for such a behavior could be that the original 16 Bit image is in the TIFF container and the 8 Bit converted image also.

 

Now to a next step:

 

16 Bit AFPhoto from above -> Export to 16 Bit TIFF again (109 MB).

 

Looking into the file properties it can be seen that the LZW compression is used. This compression method has been dropped by Adobe for 16 Bit TIFFs, because in photos it often leads to file sizes that are larger than of non compressed TIFFs. Maybe someone could try to implement ZIP compression for TIFFs (84 MB) or uncompressed (102 MB) as they are produced by lightroom. Btw. Photo can open ZIP compressed TIFFs, so why is there no option to use it for export?

 

Here are some links for reference:

https://forums.adobe.com/message/1918848#1918848

https://forums.adobe.com/message/1402821#1402821

 

I think, if it would be possible to select ZIP compression for TIFFs and also have the option to compress AFPhoto files at the cost of opening times and if there would be a settings page to better control the contents of AFPhoto files (no snapshots, no history, ... with check boxes), most of the file size discussions would end. I think people understand the size vs speed issue and are happy when they have options to go the one or the other way.

[Michail]

If you don't need the extra precision, you can try converting to 8-bit via Document>Colour Format before saving your document. If you've already saved it, try Save As to create a fresh copy with no redundant data.

 

Additionally, when you develop or begin work on an image, an initial Snapshot is created so you can always revert to the original image. This takes up space too, so you may want to delete it. If you go to View>Studio>Snapshots to display the panel, you can then click on the Background snapshot and delete it (the bin icon).

 

1. It is the 8-bit image whose size is over 100MB.

2. I have neither snapshots nor a history in my pictures.

 

 

after reading youruncompressed 16 Bit TIFF (102 MB) -> 16 Bit AFPhoto (102 MB) -> Document Colour Format to 8 Bit RGB -> 8 Bit AFPhoto (137 MB)

 

I think, if it would be possible to select ZIP compression for TIFFs and also have the option to compress AFPhoto files at the cost of opening times and if there would be a settings page to better control the contents of AFPhoto files (no snapshots, no history, ... with check boxes), most of the file size discussions would end. I think people understand the size vs speed issue and are happy when they have options to go the one or the other way.

 

1. That's what I mean. It is completely unclear what AP does.

2. Yes exactly. The storage management of AP needs more transparency. The user must see what is stored. And there must be options to decide for themselves. So like now, it is not acceptable.

[R C-R]

I think, if it would be possible to select ZIP compression for TIFFs and also have the option to compress AFPhoto files at the cost of opening times and if there would be a settings page to better control the contents of AFPhoto files (no snapshots, no history, ... with check boxes), most of the file size discussions would end. I think people understand the size vs speed issue and are happy when they have options to go the one or the other way.

For what it is worth, I tried compressing a variety of .afphoto files with a separate ZIP compression utility. The result was a negligible savings in file space, at most a few tenths of a MB on 50+ MB files.

 

As for what would make most people happy, I think you are being a bit overoptimistic about that. Some won't be happy unless there is no compromise in speed even if the file sizes are reduced; others are already unhappy about all the options, which they find confusing; & regardless of how much file sizes could be reduced some will still think they are too large.

[Michail]

The options are for those who need them. For the others there are the default settings. In AP (also in AD) there are generally very few settings. I know this is always a balancing act.

But Affinity would like to be a software for professionals. And professionals want to adapt their programs to their needs. And they like it transparent. I want to know why my file size is getting bigger. And how I can influence that.

I'm also not quite sure if that is intended or maybe bugs. So I had the topic originally started in the bug thread.

[R C-R]

I understand you want as much control over file size as you can get. But a ZIP option isn't going to do anything useful because it has negligible effect on file size, as you test for yourself in the same way I did.

 

Also, like it or not, the developers have told us several times that the details of the Affinity file structure are considered proprietary, trade secrets they are not willing to reveal to their competitors. I think most professionals will understand the reasons for that -- after all, Adobe does the same thing. So like Adobe (among others) any options they provide will be at least partially opaque.

 

However, one thing we do know is the format is unique in that it is the same for all the Affinity apps -- Photo can open Designer files & visa versa, & neither will discard or damage any data the other app creates or needs to support its features. This probably contributes to increased file size & almost certainly would complicate providing any options that impact that hallmark feature -- imagine the support issues that would create if in effect there were several different file formats, not all of which were fully compatible with all the Affinity apps (including the ones not yet released).

 

Like you said, it is always a balancing act.

[Michail]

Also, like it or not, the developers have told us several times that the details of the Affinity file structure are considered proprietary, trade secrets they are not willing to reveal to their competitors. I think most professionals will understand the reasons for that -- after all, Adobe does the same thing. So like Adobe (among others) any options they provide will be at least partially opaque.

 

Normally the proprietary specifications are uninteresting for me. It was only on the topic, because the file size of AP files uncontrollably getting bigger and bigger. With other probiestary file formats it is not so.

 

One option would be if the user could use a command to free the file from the ballast. Currently I am converting the AP file into TIFF and back. Then the file has returned an expected size. But of course this is not very practical.

[Ben]

For what it is worth, I tried compressing a variety of .afphoto files with a separate ZIP compression utility. The result was a negligible savings in file space, at most a few tenths of a MB on 50+ MB files.

 

As for what would make most people happy, I think you are being a bit overoptimistic about that. Some won't be happy unless there is no compromise in speed even if the file sizes are reduced; others are already unhappy about all the options, which they find confusing; & regardless of how much file sizes could be reduced some will still think they are too large.

 

Since we use ZLib compression on raster data in an afphoto file, running the file through an additional ZIP compression will most likely achieve nothing.  At most then additional file structures may achieve a small amount of compression, but it will be negligible.

 

I am looking into further optimisations for the data before compression, but this is a very inexact science as different images will have very different data properties, and that impacts on how well ZLib compression will work.

 

We have balanced the ZLib compression ratio for performance (I spent ages plotting graphs against numerous sample images).  We could squeeze out a few more %, but the time taken to compression will be more than double.  Not worth the processing time on average.

[Ben]

Normally the proprietary specifications are uninteresting for me. It was only on the topic, because the file size of AP files uncontrollably getting bigger and bigger. With other probiestary file formats it is not so.

 

One option would be if the user could use a command to free the file from the ballast. Currently I am converting the AP file into TIFF and back. Then the file has returned an expected size. But of course this is not very practical.

 

No need to convert to a TIFF - just do a Save-As to a new file, and the new file will be a streamlined version of your current one.

 

As has been stated, I have commented on many threads already to explain what we store in afphoto files, and how that benefits better performance for opening and iterative saves.

[anon1]

No need to convert to a TIFF - just do a Save-As to a new file, and the new file will be a streamlined version of your current one.

 

As has been stated, I have commented on many threads already to explain what we store in afphoto files, and how that benefits better performance for opening and iterative saves.

maybe add a preference that one can toggle so that AP always saves this streamlined version automatically when doing the normal save, the additional processing time might be acceptable on a fast computer 

 

cheers

[Michail]

No need to convert to a TIFF - just do a Save-As to a new file, and the new file will be a streamlined version of your current one.

 

As has been stated, I have commented on many threads already to explain what we store in afphoto files, and how that benefits better performance for opening and iterative saves.

 

For me it makes no difference - save or save as. Even saving under a new name does not change the file size. Only TIFF brings something (without levels).

[R C-R]

No need to convert to a TIFF - just do a Save-As to a new file, and the new file will be a streamlined version of your current one.

At least on my system, sometimes this reduces file size but often it does not -- in fact, there are times when the file size increases by 5 to 10% or occasionally more.

 

This really does not bother me. I use large spinning hard drives for document storage, not SSD's, & I much prefer that the files are optimized for fast loads & saves.

 

One thing I have noticed: for some of my AD & AP documents, just hiding layers before saving can significantly reduce the file size. I don't know if this has something to do with mipmaps being saved based on visibility or what, but I would like to know if anybody else has noticed the same thing.

[Ben]

Really?  The file size should never increase with a Save-As - unless you have some unsaved changes.

[R C-R]

Really?  The file size should never increase with a Save-As - unless you have some unsaved changes.

It is quite possible that unsaved changes account for the increases I sometimes see. But it is still true that using Save As almost never results in any decrease in file size -- even if I check the actual byte count in Get Info windows the change is rarely more than a few bytes.

 

The exception is if I do nothing besides open a previously saved native format file, hide some of its layers, & then immediately do a regular save, I sometimes get a significant reduction in the file's size.

[Ben]

The reason for that, as I said, will be that your file is already fairly optimal.

 

The way we structure our files means that the bits that change are localised.  So, redundancy only happens where you replace or delete pixel data, and that is also localised to segments within a pixel layer.  In real world situations, and depending upon how you work, it may be that you mainly add to rather than change pixel data.  So, streamlining won't remove much.

[R C-R]

The reason for that, as I said, will be that your file is already fairly optimal.

But does that somehow explain the bit about just hiding some layers sometimes resulting in a significant reduction in the file's size? For the files that display that behavior, it is repeatable -- open the file, do nothing besides hide some layers & save it. Result: smaller file. Open it again & do nothing besides unhide those layers & save it. Result: bigger file.

 

(At the moment, I do not remember which files show this behavior but if I run across one & will be happy to send it to you if requested.)