This is just more curiosity rather than anything else, I noticed that if I look at the properties of an XCF it shows the size as 2.9mb but when I open with Gimp the bottom information bar shows a size of 320mb, just wondered what is the cause of such a huge difference in the values.

I allways have noticed the same difference.

@he4rty. I have an XCF I just made. saved it to desktop, in properties it says it is 72.3 KB When I look at the bottom of the opened XCF, it says 2.6 MB. This is strange, but must have a logical explanation from some of these techies out there.

The data for all of an image's drawables (i.e., its layers, channels, and layermasks) is divided into 64x64 pixels "tiles". Each of these tiles requires 4096 bytes of memory per component -- for example, a single tile of RGB pixels with an alpha channel requires 16KB of memory in the computer.

However, when these tiles are saved to the XCF file, "run length encoding" is used to reduce the number of bytes that are written to the file. Simply described, run length encoding works by providing a "count" byte followed by a "value" byte; when the file is read, the "value" is repeated "count" number of times. So, for example, if you have a row of black pixels in a tile then instead 64 zeroes being written to the file, only two bytes are written (a "64" followed by a "0"). For longer "runs" of identical values, GIMP allows for the data to be encoded in just four bytes.

At the extreme, a solid-colored layer or channel which occupies several kilobytes in memory only takes up a handful of bytes in the XCF file. Even for layers and channels that contain varying data, run length encoding will typically result in great savings in file space.

You guys sure know your techie stuff.

Thanks for that, I think I've got the gist of what your saying, I guessed it was to do with compression of some kind but wasn't sure how it was compressed so much.

Compression does not equal lossless. For example, zip files are compressed but are still lossless.

Thank you all anyway for the techie stuff, I'm not going to get into a disagreement over my bad choice of words, I'm just not techie minded or just cannot remember all these words and meanings.

That answers why my XCF's are always huge, thanks.

I think I may have to move all my old xcf's to a memory stick, my hard drive isn't even 1 TB.

You can always use gzip or bzip2 to cut the size of your XCFs roughly in half. GIMP is able to handle .xcf.gz and .xcf.bz2 files directly, both in saving and in loading (it just takes longer than using .xcf).

gzip and bzip2 are included in all GNU/Linux distributions. I don't know if Microsoft includes it with Windows, but the 7-zip program handles compression and decompression using both protocols.

GIMP on Windows includes bzip2.dll (or bz2-1.dll) and zlib1.dll so handles .xcf.gz .xcfgz .xcf.bz2 .xcfbz2 automatically.

Kevin

True, yet one of the nice things about GIMP using these freely-implemented standard compression methods is that dedicated tools can be used to compress or decompress multiple files at once (for example, all of the .xcf files in a folder, or all of the original frames from a GAP animation).


@Mokonofan
Roughly speaking gzipping reduces file size by about 40% and takes 3 times as long to load or save, whereas bzip2ing reduces the file size by about 60% and takes 10 times as long to load or save. This is all dependent upon how fast your processor is versus how fast your disk drive is -- if your processor were fast enough then you could compress a file as fast as you save the data and have compression actually improve the transfer speed (saving to a USB pendrive would be a good example of this situation).

Despite the better compression bzip2 offers, you might prefer gzip because decompression can start while the file is transferring (one of the reasons it is so much faster than bzip2). With bzip2 the entire file needs to be loaded before decompression can start. This is especially significant when uploading a file to the Internet because the downloader can start decompressing while the file is downloading. This means that a downloaded gzip file can be ready as soon as the download is complete (whereas at this point a downloaded bzip2 file would just be starting the decompression and a plain .xcf file would still be downloading). In other words, when opening a URL from within GIMP, an .xcf.gz will typically be available for editing much quicker than either an .xcf or an .xcf.bz2

All things considered, my recommendation is to always use .xcf.gz to save your images, except for long-term archiving or when making GAP animations.

I only has 1.6 GB hardisk space left and I don't worry...

BTW, is using 'blend' tools seems somehow make .XCF files bigger in size?
I test using default image size a5 300dpi 1754x2480

Black without transparency=18KB (file size on disk)
White without transparency=18KB
Empty Transparency=23KB
Transparency filled with black=23KB
Transparency with 'normal' 50% blend using black color=1708KB
Grey with 'divide' 50% blend=4257KB
Gradient used: FG to transparent

Using example above, after I clear the layer and just transparency left, I notice the file size still at 4266KB (it's an empty layer, just transparency)?
And after I fill it with black, the size become 33KB.
I think 'something' is left untouched by the program, but I'm not sure what...

Thanks for all the info, I never knew this thread would yield so much discussion and advice.

When you clear a layer, its alpha channel is filled with zero (black) so that it is visibly transparent however, the values in the red, green, and blue channels are left unchanged. Why waste time changing something that isn't going to be seen anyway?

You can verify that this is what is happening by performing a "Colors->Components->Decompose" to RGBA after clearing your layer.