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

[Jehan Pagès <jehan marmottard gmail com>]

Hi,

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
> > > compress
> > > 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
contents.

> 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.

Jehan

> Best,
> Elle



-- 
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot