GIMP does not compress GIF files - Mandriva

This is a discussion on GIMP does not compress GIF files - Mandriva ; Here's a 573x573 pixel PNG image that is just 415 bytes in size: http://i37.tinypic.com/6icpqp.png But if I load it into the GIMP and save it in GIF format, then it becomes 120 times larger, 50068 bytes, which is presumably uncompressed. ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: GIMP does not compress GIF files

  1. GIMP does not compress GIF files

    Here's a 573x573 pixel PNG image that is just 415 bytes in size:
    http://i37.tinypic.com/6icpqp.png

    But if I load it into the GIMP and save it in GIF format, then it becomes
    120 times larger, 50068 bytes, which is presumably uncompressed.
    http://i36.tinypic.com/9jkt3k.gif

    I asked about this in uk.comp.os.linux, and was told that the GIMP in
    Debian and Fedora saved the GIF in 4593 bytes, only 11 times larger.

    So I've just upgraded GIMP to version 2.4.7 from the Mandriva backports
    repository, but it still saves GIFs uncompressed. This might be related
    to the former patent issues with the GIF compression algorithm.

    I wonder if there's some extra package for GIF compression that I should
    install, but I don't see anything obvious in the package manager.

    (BTW, the reason that I want to use the GIF format is for an animation,
    and unfortunately PNG animations only work in the very latest browsers.)

    --
    Dave Farrance

  2. Re: GIMP does not compress GIF files

    Dave Farrance wrote:

    > (BTW, the reason that I want to use the GIF format is for an animation,
    > and unfortunately PNG animations only work in the very latest browsers.)


    I don't know much about how to use gimp, and/but I use irfanview under
    wine.

    With IV, I decrease the color depth to 8, and it saves as as 4634 byte
    ..gif file.

    IV also gives me the options to save the graphic as a .png with
    compression options of 0-9, (0 is none, 9 is most/best) which the default
    configuration is 6 which makes a 2232 byte 8 bit .png file (compare to
    your 415 byte 1 bit .png).

    There are also (unpopular and poorly supported compared to .gif) .png
    formats which support animation.



    --
    Mike Easter


  3. Re: GIMP does not compress GIF files

    On 2008-09-22, Dave Farrance wrote:
    > Here's a 573x573 pixel PNG image that is just 415 bytes in size:
    > http://i37.tinypic.com/6icpqp.png
    >
    > But if I load it into the GIMP and save it in GIF format, then it becomes
    > 120 times larger, 50068 bytes, which is presumably uncompressed.
    > http://i36.tinypic.com/9jkt3k.gif
    >
    > I asked about this in uk.comp.os.linux, and was told that the GIMP in
    > Debian and Fedora saved the GIF in 4593 bytes, only 11 times larger.
    >
    > So I've just upgraded GIMP to version 2.4.7 from the Mandriva backports
    > repository, but it still saves GIFs uncompressed. This might be related
    > to the former patent issues with the GIF compression algorithm.
    >
    > I wonder if there's some extra package for GIF compression that I should
    > install, but I don't see anything obvious in the package manager.
    >
    > (BTW, the reason that I want to use the GIF format is for an animation,
    > and unfortunately PNG animations only work in the very latest browsers.)


    Use ImageMagick's convert:

    $ convert 6icpqp.png 6icpqp.gif
    $ ls -l 6icpqp.png 6icpqp.gif
    -rw-rw-r-- 1 chris chris 4601 Sep 22 17:43 6icpqp.gif
    -rw-rw-r-- 1 chris chris 415 Sep 22 12:10 6icpqp.png

    --
    Chris F.A. Johnson, author |
    Shell Scripting Recipes: | My code in this post, if any,
    A Problem-Solution Approach | is released under the
    2005, Apress | GNU General Public Licence

  4. Re: GIMP does not compress GIF files

    "Chris F.A. Johnson" wrote:

    > Use ImageMagick's convert:
    >
    >$ convert 6icpqp.png 6icpqp.gif
    >$ ls -l 6icpqp.png 6icpqp.gif
    >-rw-rw-r-- 1 chris chris 4601 Sep 22 17:43 6icpqp.gif
    >-rw-rw-r-- 1 chris chris 415 Sep 22 12:10 6icpqp.png


    Thanks, that works. And I find that it can convert a GIMP-made
    uncompressed GIF animation into a compressed GIF animation.

    --
    Dave Farrance

  5. Re: GIMP does not compress GIF files

    On Mon, 22 Sep 2008 19:48:30 +0000, Dave Farrance wrote:

    > Here's a 573x573 pixel PNG image that is just 415 bytes in size:
    > http://i37.tinypic.com/6icpqp.png
    >
    > But if I load it into the GIMP and save it in GIF format, then it
    > becomes 120 times larger, 50068 bytes, which is presumably uncompressed.
    > http://i36.tinypic.com/9jkt3k.gif
    >
    > I asked about this in uk.comp.os.linux, and was told that the GIMP in
    > Debian and Fedora saved the GIF in 4593 bytes, only 11 times larger.
    >
    > So I've just upgraded GIMP to version 2.4.7 from the Mandriva backports
    > repository, but it still saves GIFs uncompressed. This might be related
    > to the former patent issues with the GIF compression algorithm.
    >
    > I wonder if there's some extra package for GIF compression that I should
    > install, but I don't see anything obvious in the package manager.
    >
    > (BTW, the reason that I want to use the GIF format is for an animation,
    > and unfortunately PNG animations only work in the very latest browsers.)


    Looks compressed to me. 573*573 = 328329.


  6. Re: GIMP does not compress GIF files

    ray wrote:

    >On Mon, 22 Sep 2008 19:48:30 +0000, Dave Farrance wrote:
    >
    >> Here's a 573x573 pixel PNG image that is just 415 bytes in size:
    >> http://i37.tinypic.com/6icpqp.png
    >>
    >> But if I load it into the GIMP and save it in GIF format, then it
    >> becomes 120 times larger, 50068 bytes, which is presumably uncompressed.
    >> http://i36.tinypic.com/9jkt3k.gif

    >
    >Looks compressed to me. 573*573 = 328329.


    328329 bits not bytes. It's a 2 colour image.

    --
    Dave Farrance

  7. Re: GIMP does not compress GIF files

    On Tue, 23 Sep 2008 16:35:40 +0000, Dave Farrance wrote:

    > ray wrote:
    >
    >>On Mon, 22 Sep 2008 19:48:30 +0000, Dave Farrance wrote:
    >>
    >>> Here's a 573x573 pixel PNG image that is just 415 bytes in size:
    >>> http://i37.tinypic.com/6icpqp.png
    >>>
    >>> But if I load it into the GIMP and save it in GIF format, then it
    >>> becomes 120 times larger, 50068 bytes, which is presumably
    >>> uncompressed. http://i36.tinypic.com/9jkt3k.gif

    >>
    >>Looks compressed to me. 573*573 = 328329.

    >
    > 328329 bits not bytes. It's a 2 colour image.


    Actually, 328329 PIXELS. How it is mapped out would determine whether it
    would take one bit per pixel or three bytes per pixel or somewhere in
    between.

  8. Re: GIMP does not compress GIF files

    ray wrote:

    >On Tue, 23 Sep 2008 16:35:40 +0000, Dave Farrance wrote:
    >
    >> ray wrote:
    >>
    >>>On Mon, 22 Sep 2008 19:48:30 +0000, Dave Farrance wrote:
    >>>
    >>>> Here's a 573x573 pixel PNG image that is just 415 bytes in size:
    >>>> http://i37.tinypic.com/6icpqp.png
    >>>>
    >>>> But if I load it into the GIMP and save it in GIF format, then it
    >>>> becomes 120 times larger, 50068 bytes, which is presumably
    >>>> uncompressed. http://i36.tinypic.com/9jkt3k.gif
    >>>
    >>>Looks compressed to me. 573*573 = 328329.

    >>
    >> 328329 bits not bytes. It's a 2 colour image.

    >
    >Actually, 328329 PIXELS. How it is mapped out would determine whether it
    >would take one bit per pixel or three bytes per pixel or somewhere in
    >between.


    Did you read the next bit where I said that it was a 2 colour image?

    --
    Dave Farrance

  9. Re: GIMP does not compress GIF files

    On Tue, 23 Sep 2008 19:01:57 +0000, Dave Farrance wrote:

    > ray wrote:
    >
    >>On Tue, 23 Sep 2008 16:35:40 +0000, Dave Farrance wrote:
    >>
    >>> ray wrote:
    >>>
    >>>>On Mon, 22 Sep 2008 19:48:30 +0000, Dave Farrance wrote:
    >>>>
    >>>>> Here's a 573x573 pixel PNG image that is just 415 bytes in size:
    >>>>> http://i37.tinypic.com/6icpqp.png
    >>>>>
    >>>>> But if I load it into the GIMP and save it in GIF format, then it
    >>>>> becomes 120 times larger, 50068 bytes, which is presumably
    >>>>> uncompressed. http://i36.tinypic.com/9jkt3k.gif
    >>>>
    >>>>Looks compressed to me. 573*573 = 328329.
    >>>
    >>> 328329 bits not bytes. It's a 2 colour image.

    >>
    >>Actually, 328329 PIXELS. How it is mapped out would determine whether
    >>it would take one bit per pixel or three bytes per pixel or somewhere in
    >>between.

    >
    > Did you read the next bit where I said that it was a 2 colour image?


    I certainly did. That does not necessarily mean it is being stored at one
    bit per pixel.

  10. Re: GIMP does not compress GIF files

    ray wrote:

    >On Tue, 23 Sep 2008 19:01:57 +0000, Dave Farrance wrote:
    >
    >> ray wrote:
    >>
    >>>On Tue, 23 Sep 2008 16:35:40 +0000, Dave Farrance wrote:
    >>>
    >>>> ray wrote:
    >>>>
    >>>>>On Mon, 22 Sep 2008 19:48:30 +0000, Dave Farrance wrote:
    >>>>>
    >>>>>> Here's a 573x573 pixel PNG image that is just 415 bytes in size:
    >>>>>> http://i37.tinypic.com/6icpqp.png
    >>>>>>
    >>>>>> But if I load it into the GIMP and save it in GIF format, then it
    >>>>>> becomes 120 times larger, 50068 bytes, which is presumably
    >>>>>> uncompressed. http://i36.tinypic.com/9jkt3k.gif
    >>>>>
    >>>>>Looks compressed to me. 573*573 = 328329.
    >>>>
    >>>> 328329 bits not bytes. It's a 2 colour image.
    >>>
    >>>Actually, 328329 PIXELS. How it is mapped out would determine whether
    >>>it would take one bit per pixel or three bytes per pixel or somewhere in
    >>>between.

    >>
    >> Did you read the next bit where I said that it was a 2 colour image?

    >
    >I certainly did. That does not necessarily mean it is being stored at one
    >bit per pixel.


    So given the stuff that I put in the OP about the GIF files generated by
    the Debian and Fedora builds of GIMP being 11 times smaller than the GIF
    files generated by the Mandriva build of GIMP and about the known patent
    issues that previously affected the compression algorithm, what is your
    explanation for this huge difference in size (other than the bleeding
    obvious, that is)?

    --
    Dave Farrance

  11. Re: GIMP does not compress GIF files

    I see a relevant post in the thread that I started in uk.comp.os.linux.
    Apparently, the GIMP has a compile-time configuration option:

    --with-gif-compression=lzw|rle|none

    RLE being simple run-length-encoding, which I presume can be formatted as
    a subset of the formerly-patented LZW compression.

    A hex dump of the large Mandriva-GIMP-created GIF contains stuff like:

    >00006b10 01 27 c0 01 27 c0 01 27 c0 01 27 c0 01 27 c0 01 |.'.'.'.'.'.|
    >00006b20 27 c0 01 27 c0 01 27 c0 01 27 c0 01 27 c0 01 27 |'.'.'.'.'.'|
    >00006b30 c0 01 27 c0 01 27 c0 01 27 c0 01 27 c0 01 27 c0 |.'.'.'.'.'|
    >00006b40 01 27 c0 01 27 c0 01 27 c0 01 27 c0 01 27 c0 01 |.'.'.'.'.'.|


    .... which does look like inefficient use of the colour space followed by
    RLE. So, Ray, I agree that it does seem to be (poorly) compressed.

    In a few days, I'll raise a bug report asking that Mandriva restore LZW
    compression to the GIMP, unless somebody disagrees with the above.

    --
    Dave Farrance










  12. Re: GIMP does not compress GIF files

    On Wed, 24 Sep 2008 13:17:48 +0000, Dave Farrance wrote:

    > I see a relevant post in the thread that I started in uk.comp.os.linux.
    > Apparently, the GIMP has a compile-time configuration option:
    >
    > --with-gif-compression=lzw|rle|none
    >
    > RLE being simple run-length-encoding, which I presume can be formatted
    > as a subset of the formerly-patented LZW compression.
    >
    > A hex dump of the large Mandriva-GIMP-created GIF contains stuff like:
    >
    >>00006b10 01 27 c0 01 27 c0 01 27 c0 01 27 c0 01 27 c0 01
    >>|.'À.'À.'À.'À.'À.| 00006b20 27 c0 01 27 c0 01 27 c0 01 27 c0 01 27 c0
    >>01 27 |'À.'À.'À.'À.'À.'| 00006b30 c0 01 27 c0 01 27 c0 01 27 c0 01 27
    >>c0 01 27 c0 |À.'À.'À.'À.'À.'À| 00006b40 01 27 c0 01 27 c0 01 27 c0 01
    >>27 c0 01 27 c0 01 |.'À.'À.'À.'À.'À.|

    >
    > ... which does look like inefficient use of the colour space followed by
    > RLE. So, Ray, I agree that it does seem to be (poorly) compressed.
    >
    > In a few days, I'll raise a bug report asking that Mandriva restore LZW
    > compression to the GIMP, unless somebody disagrees with the above.


    FWIW - I think there is an additional clue in your original figures:
    573*573/8 = 41041+ - so if it were being stored properly, one bit per
    pixel, an uncompressed image should be close to 41041 (always a little
    overhead), but I'd certainly expect it to be smaller that 50000. This
    leads me to suspect it's not being store as 1 bit per pixel, but more
    than that and then compressed down to 50k.

  13. Re: GIMP does not compress GIF files

    On Wed, 24 Sep 2008 13:17:48 +0000, Dave Farrance wrote:

    > I see a relevant post in the thread that I started in uk.comp.os.linux.
    > Apparently, the GIMP has a compile-time configuration option:
    >
    > --with-gif-compression=lzw|rle|none
    >
    > RLE being simple run-length-encoding, which I presume can be formatted
    > as a subset of the formerly-patented LZW compression.


    Run-length encoding is not a subset of LZW, and is much older, starting
    at least with Huffman.

  14. Re: GIMP does not compress GIF files

    Mark Madsen wrote:

    >On Wed, 24 Sep 2008 13:17:48 +0000, Dave Farrance wrote:
    >
    >> I see a relevant post in the thread that I started in uk.comp.os.linux.
    >> Apparently, the GIMP has a compile-time configuration option:
    >>
    >> --with-gif-compression=lzw|rle|none
    >>
    >> RLE being simple run-length-encoding, which I presume can be formatted
    >> as a subset of the formerly-patented LZW compression.

    >
    >Run-length encoding is not a subset of LZW, and is much older, starting
    >at least with Huffman.


    I'd assumed that Compuserve only specified LZW for GIF compression, and
    this RLE encoding was the best compression that could be found that
    avoided the patent and yet was still accepted by the LZW decompression in
    the GIF display applications. Are you saying that Compuserve specified
    an incompatible alternative compression for GIFs right from the start?

    --
    Dave Farrance

  15. Re: GIMP does not compress GIF files

    On Wed, 24 Sep 2008 17:10:24 +0000, Dave Farrance wrote:

    >>> RLE being simple run-length-encoding, which I presume can be formatted
    >>> as a subset of the formerly-patented LZW compression.

    >>
    >>Run-length encoding is not a subset of LZW, and is much older, starting
    >>at least with Huffman.

    >
    > I'd assumed that Compuserve only specified LZW for GIF compression, and
    > this RLE encoding was the best compression that could be found that
    > avoided the patent and yet was still accepted by the LZW decompression
    > in the GIF display applications. Are you saying that Compuserve
    > specified an incompatible alternative compression for GIFs right from
    > the start?


    I'm pretty sure I didn't say any of that. I specifically said that run-
    length encoding and LZW are different, and that's all I said. Entropy
    coding and dictionary coding are considered to be different classes of
    code algorithm.

  16. Re: GIMP does not compress GIF files

    Mark Madsen wrote:

    >On Wed, 24 Sep 2008 17:10:24 +0000, Dave Farrance wrote:
    >
    >>>> RLE being simple run-length-encoding, which I presume can be formatted
    >>>> as a subset of the formerly-patented LZW compression.
    >>>
    >>>Run-length encoding is not a subset of LZW, and is much older, starting
    >>>at least with Huffman.

    >>
    >> I'd assumed that Compuserve only specified LZW for GIF compression, and
    >> this RLE encoding was the best compression that could be found that
    >> avoided the patent and yet was still accepted by the LZW decompression
    >> in the GIF display applications. Are you saying that Compuserve
    >> specified an incompatible alternative compression for GIFs right from
    >> the start?

    >
    >I'm pretty sure I didn't say any of that. I specifically said that run-
    >length encoding and LZW are different, and that's all I said. Entropy
    >coding and dictionary coding are considered to be different classes of
    >code algorithm.


    So how does RLE work with GIFs then?

    --
    Dave Farrance

  17. Re: GIMP does not compress GIF files

    Mark Madsen writes:

    >On Wed, 24 Sep 2008 17:10:24 +0000, Dave Farrance wrote:


    >>>> RLE being simple run-length-encoding, which I presume can be formatted
    >>>> as a subset of the formerly-patented LZW compression.
    >>>
    >>>Run-length encoding is not a subset of LZW, and is much older, starting
    >>>at least with Huffman.

    >>
    >> I'd assumed that Compuserve only specified LZW for GIF compression, and
    >> this RLE encoding was the best compression that could be found that
    >> avoided the patent and yet was still accepted by the LZW decompression
    >> in the GIF display applications. Are you saying that Compuserve
    >> specified an incompatible alternative compression for GIFs right from
    >> the start?


    >I'm pretty sure I didn't say any of that. I specifically said that run-
    >length encoding and LZW are different, and that's all I said. Entropy


    No. Your quote is above. "run-length-encoding, which I presume can be
    formatted as a subset of the formerly-patented LZW compressiona"

    You explicitly make a link between run length encoding and LZW with the
    former as a subset of the latter. Exactly what kind of subset is modified
    by the term "formatted" which makes little sense in this context, since LZW
    is not a formatting procedure, so it is not clear what "formatted as a
    subset" means, but the primary statement is that rle and lsw are related.
    You did not say they are different. You said one was a subset of the other.
    To say that women are a subset of humanity does not mean that women are
    different from humanity.


    >coding and dictionary coding are considered to be different classes of
    >code algorithm.


  18. Re: GIMP does not compress GIF files

    Unruh wrote:

    >Mark Madsen writes:
    >
    >>On Wed, 24 Sep 2008 17:10:24 +0000, Dave Farrance wrote:

    >
    >>>>> RLE being simple run-length-encoding, which I presume can be formatted
    >>>>> as a subset of the formerly-patented LZW compression.
    >>>>
    >>>>Run-length encoding is not a subset of LZW, and is much older, starting
    >>>>at least with Huffman.
    >>>
    >>> I'd assumed that Compuserve only specified LZW for GIF compression, and
    >>> this RLE encoding was the best compression that could be found that
    >>> avoided the patent and yet was still accepted by the LZW decompression
    >>> in the GIF display applications. Are you saying that Compuserve
    >>> specified an incompatible alternative compression for GIFs right from
    >>> the start?

    >
    >>I'm pretty sure I didn't say any of that. I specifically said that run-
    >>length encoding and LZW are different, and that's all I said. Entropy

    >
    >No. Your quote is above. "run-length-encoding, which I presume can be
    >formatted as a subset of the formerly-patented LZW compressiona"
    >
    >You explicitly make a link between run length encoding and LZW with the
    >former as a subset of the latter. Exactly what kind of subset is modified
    >by the term "formatted" which makes little sense in this context, since LZW
    >is not a formatting procedure, so it is not clear what "formatted as a
    >subset" means, but the primary statement is that rle and lsw are related.
    >You did not say they are different. You said one was a subset of the other.
    >To say that women are a subset of humanity does not mean that women are
    >different from humanity.


    I'm not sure which person you're talking to here. The "subset" comment
    was mine, meaning that I presumed that an RLE format had been found that
    could be decompressed by the LZW decoders in standard GIF apps, to evade
    the patent problem. If that is *not* the case, then since we know that
    GIF apps *can* handle RLE, then Compuserve must have specified RLE as an
    alternative to LZW for GIFs from the start. See what I'm getting at now?

    --
    Dave Farrance

  19. Re: GIMP does not compress GIF files

    On Wed, 24 Sep 2008 20:45:23 +0000, Unruh wrote:

    > Mark Madsen writes:
    >
    >>On Wed, 24 Sep 2008 17:10:24 +0000, Dave Farrance wrote:

    >
    >>>>> RLE being simple run-length-encoding, which I presume can be
    >>>>> formatted as a subset of the formerly-patented LZW compression.
    >>>>
    >>>>Run-length encoding is not a subset of LZW, and is much older,
    >>>>starting at least with Huffman.
    >>>
    >>> I'd assumed that Compuserve only specified LZW for GIF compression,
    >>> and this RLE encoding was the best compression that could be found
    >>> that avoided the patent and yet was still accepted by the LZW
    >>> decompression in the GIF display applications. Are you saying that
    >>> Compuserve specified an incompatible alternative compression for GIFs
    >>> right from the start?

    >
    >>I'm pretty sure I didn't say any of that. I specifically said that run-
    >>length encoding and LZW are different, and that's all I said. Entropy

    >
    > No. Your quote is above. "run-length-encoding, which I presume can be
    > formatted as a subset of the formerly-patented LZW compressiona"


    Really no. That is not my quote, and examination of the postings
    upthread will show you who said what. Not mine.

    > You explicitly make a link between run length encoding and LZW with the
    > former as a subset of the latter. Exactly what kind of subset is
    > modified by the term "formatted" which makes little sense in this
    > context, since LZW is not a formatting procedure, so it is not clear
    > what "formatted as a subset" means, but the primary statement is that
    > rle and lsw are related. You did not say they are different. You said
    > one was a subset of the other. To say that women are a subset of
    > humanity does not mean that women are different from humanity.


    Someone does, but not I. Take it up with them.

    >>coding and dictionary coding are considered to be different classes of
    >>code algorithm.


    Like I said. Twice now.

  20. Re: GIMP does not compress GIF files

    Dave Farrance wrote:
    > If that is *not* the case, then since we know that
    > GIF apps *can* handle RLE, then Compuserve must have specified RLE as an
    > alternative to LZW for GIFs from the start. See what I'm getting at now?


    CompuServe was using .rle format for graphics even before the GIF format
    was announced, IIRC. Perhaps the GIF spec included RLE for backwards
    compatibility?

    Adam

+ Reply to Thread