Hi, On Wed, Oct 4, 2017 at 1:09 PM, Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
