Filesize: Suggestion

[Fritz_H]

It has been asked several times, why the Photo-Files are so big.
The general answer was/is, that Affinity adds some Data to the files for performance improvement.
OK.

But how about a "compressed" file-format without all this "performance improvement-Data" ?
Esp. since I guess, this extra-Data is redundant and can be re-generated at any time later.

A smaller file size would be useful for file transfer and archiving.

[fde101]

Also, saving files with history will also increase their size over time.

You may sometimes be able to reduce the size of an existing file by saving it using "Save As" if you have been working with that file for long enough.

For file transfer/archiving, consider zipping the file.

[Fritz_H]

@fde101

Thanks for the hints, but ...

1.) I never save with history and
2.) zipping an Image-File? honestly?

I am talking about this:

The same file, no editing, no layers, nothing. Just opened in Photo and saved as Photo-File.

I do understand, that the file is bigger since Photo uses a lossless-format (of course).
But for this example: using TIFF (LZW) would result in a 87 MB File = much smaller.

I think, there is room for improvement.

[fde101]

LZW is still compressed.

If my hunch is correct about how they are working with these files, it is likely that pixel layers are completely uncompressed (except the preview image buried in the file).

For example, I randomly pulled a file I happened to have sitting around which is a RAW file taken from my old Canon EOS 30D.  That is an 8.2 MPix camera with a resolution of 3522x2348.

If you consider 16 bits per component with 4 components (r, g, b, alpha) at that resolution, the bare image data for a developed image would be 3522*2348*4*2 = 66,157,248 bytes = about 63 MB.

If I save that as an .afphoto file without making any changes other than developing it, it is 70.3 MB, which in the grand scheme of things isn't that huge of a leap (it does have the preview image in addition to the image data, to begin with).

Curiously, creating a similar document in Publisher and pasting the pixel layer into it results in a file which is 56.2 MB.  Not sure where that difference is coming from...  it is possible that the Photo document is storing additional RAW data or metadata of some sort along with the image data where Publisher is not, but 56.2 MB is less than the size of the pixel data itself...

In the Publisher 1.9 beta a pixel layer can be converted to an image layer; that doesn't currently make the file any smaller, but if Serif were to store the image layers as PNG data or some similar lossless compressed format instead of keeping it in whatever format they are using now, that in theory would make the files smaller without losing anything?

Sadly, I agree that compressing these files using a general-purpose compression tool doesn't save much.

[Fritz_H]

@fde101

LZW offers lossless compression.
According to Wikipedia, there are several lossless compression-formats available: https://en.wikipedia.org/wiki/Lossless_compression
Perhaps Serif manages to use one of them (or any other..) for a new, compressed Fileformat?
I don´t care, if such a compressed file takes longer to open since the fast, uncompressed format should remain available for daily work.

[fde101]

2 hours ago, Fritz_H said:

LZW offers lossless compression.

Of this I am aware.

My point is that with an uncompressed format, the software might be written in such a way that it does not need to rewrite the entire pixel layer to the file if only a portion of it changes.  If you only paint in a small area then it could directly update just that area.

If the image is compressed this is not possible - the entire layer needs to be rewritten to the file.

 

2 hours ago, Fritz_H said:

I don´t care, if such a compressed file takes longer to open since the fast, uncompressed format should remain available for daily work.

Something like this should be possible, thus my hint about the image layer (as opposed to the pixel layer).  Image layers are not directly editable as pixel layers are, so it would make more sense for the software to compress those when storing them - particularly since compressing it means less I/O which can actually be faster in many cases, as the CPU can typically compress/decompress the data faster than the data of the larger size could have been read/written if the whole thing needs to be.

 

In the meantime, another possible organization has occurred to me: the data in the file may actually be organized for progressive reading/writing.  In that case, the software could get a lower-resolution image first, then fill in the additional data needed for sections of the image when zooming in to a larger size.  That would kind of make sense as photos increase in resolution to sizes that are many times too large to display on a monitor: until you start editing part of an image why waste time reading the entire image if you are only going to display a smaller version of it then zoom in to a smaller section of it at a time?

Just speculation...  but many of the lossless compression formats typically used for images would not be supportive of that, though I'm sure it could be done.

 

In any case, I think an image layer is the best place to offer this added compression, and add the option to Photo that Publisher is getting now in 1.9 to convert a pixel layer to an image layer.