Re: [Gimp-developer] Size on disk vs size reported on status bar


On Wed, Oct 4, 2017 at 1:09 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
On 10/03/2017 09:40 PM, Jehan Pagès wrote:

Hi again!

On Tue, Oct 3, 2017 at 8:18 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:

On 10/03/2017 01:21 PM, Simon Budig wrote:

The current generation XCF files can contain compressed image data.

When I save XCF files I don't use the option in the Save dialog to
the data. Is there some other compression going on automatically?

Yes, XCF historically uses RLE compression, which is basic hence not
great, but still enough for a very simple image with a lot of
identical (i.e. same color) adjacent pixels (as I understand your
image is).

The option in the save dialog is about activating the newer zlib
compression instead, which is much more sophisticated and should
therefore result in even smaller files. But on very simple files,
simple compression can work great too (sometimes even better than
complex compression, that's rare but it may happen).

Hi Jehan,

Thanks! for this information. I didn't realize any compression was being
used if the option in the save dialog wasn't selected.

Saving large files can take a long time. Does anyone know how much time
percent-wise is literally writing the file out (well, I suppose this would
partly depend on the type of disk and the file system type), versus how much
time is spent doing the compression before the file is written?

No but that would be easy to time it by timing the code if you really
wanted to. :-)
In any case, RLE is much faster than zlib which is why it is still
disabled by default because it takes too much time, though it also
compresses better.

How large
would the XCF file would be if there were no compression at all before
writing the file to disk, compared to the compressed size?

If there were no compression at all, the size would be the size in
memory (well minus the history, which takes space in memory as you
noted, but which we don't save in the XCF). There is no "generic"
percentage for the compressed size. It all depends on the file

Removing all operations from the Undo history brought the %m value down to 2.9 GB. Saved to disk, the size 
is 1.6 GB. I guess random noise also compresses?

I assume you meant with the default compression (RLE)? If so, of
course, though it will be very limited for random noise. RLE is an
extremely simple compression which will compress repeated *sequential*
pixels. For instance if the pixel stream is C1 C2 C2 C2 C2 C2 C1 C2,
RLE would compress as: C1 5 C2 C1 C2. This works much better on real
life images which would have color areas and even better on drawn
images which have a lot more and bigger perfectly flat colors. But on
a perfectly noisy images where each pixel is different to the previous
one, RLE would just compress absolutely nothing. In your generated
noisy image though, there may be some repeatition here and there. But
zlib should perform much better in such a case.



ZeMarmot open animation film

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]