Reduce file size with Imager

[Eamon Daly]

Hi, all. I'm using Imager to create gifs, but the resultant
file sizes are /huge/. I'm writing the files out like so:

$img->write(type => 'gif',
max_colors => 16,
gif_eliminate_unused => 1,
data => \$data) or die $img->errstr;

I've verified that the resulting color table /is/ only 16
colors. Even so, I've opened the resulting files in several
different graphic editors and saved, and those files are an
order of magnitude smaller than the ones Imager produces.

I've tried defining a color map and used several different
variations on make_colors and translate, but the files still
seem abnormally large. Is this just a limitation in libgif?
Any suggestions?

__________________________________________________ __________
Eamon Daly

[R. Joseph Newton]

Eamon Daly wrote:

> Hi, all. I'm using Imager to create gifs, but the resultant
> file sizes are /huge/. I'm writing the files out like so:

Are you doing animations? If not, skip the GIFs. You can get much
better depth [16 million] in a lot less space with JPEG files.
Some of the compression algorithms avaiable are loss-free, too. No
matter how small the color table, each pixel is still going to take
its one byte when using GIF. I see that you set a
gif_eliminate_unused flag, but I am sort of sceptical about how
effective this will really be. I have never heard of a GIF making
such optimizations.

Joseph

[Kevin Goodsell]

R. Joseph Newton wrote:

> Eamon Daly wrote:
>
>

>>Hi, all. I'm using Imager to create gifs, but the resultant
>>file sizes are /huge/. I'm writing the files out like so:

>
>
> Are you doing animations? If not, skip the GIFs. You can get much
> better depth [16 million] in a lot less space with JPEG files.
> Some of the compression algorithms avaiable are loss-free, too. No
> matter how small the color table, each pixel is still going to take
> its one byte when using GIF. I see that you set a
> gif_eliminate_unused flag, but I am sort of sceptical about how
> effective this will really be. I have never heard of a GIF making
> such optimizations.
>
> Joseph
>

I'm sorry, but there are numerous errors here.

First of all, I know nothing about this Imager package (and indeed, very
little about Perl), but I suspect the other reply was correct. Check the
documentation and you will probably find that the package simply does
not do compression of GIF images. It will write uncompressed GIFs, but
not compressed ones. The reason is that GIF uses the LZW compression
algorithm, which is patented in some countries (the patent only recently
expired in the US), and threats of royalty fees and legal action have
caused MANY free software packages to stop supporting GIF compression.

Second, JPEG (actually JFIF) is a very poor replacement for GIF. JPEG
compression is good for photographs and other realistic images, but not
for icons, cartoons, and other things that GIF works well for (things
that have relatively few colors and/or large blocks of the same color).
When attempting to compress a cartoon, for example, you'll find that
JPEG/JFIF will give *lower* quality and a *larger* file size than GIF.
For this type of image, PNG-8 would be a better choice than GIF, and a
much better choice than JPEG/JFIF.

Third, only in relatively bad cases will GIF require a byte for every
pixel. For example, I just created a solid white 200 by 200 image.
That's 40,000 pixels. The file size is 345 bytes. One byte per pixel is
what you would get if no compression was used at all (probably what
happened in this case, but not what happens in general), or if the
compression performed so badly that it might as well have not been used
(which is rare for typical images).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[R. Joseph Newton]

Kevin Goodsell wrote:

> Third, only in relatively bad cases will GIF require a byte for every
> pixel. For example, I just created a solid white 200 by 200 image.
> That's 40,000 pixels. The file size is 345 bytes. One byte per pixel is
> what you would get if no compression was used at all (probably what
> happened in this case, but not what happens in general), or if the
> compression performed so badly that it might as well have not been used
> (which is rare for typical images).
>
> -Kevin

Seriously? I guess I was going by what I have seen in full-color images. I
may have dismissed the GIF protocol too quickly, when I was doing a lot of
graphics work. I'll take another look at it. I notice now that I can
easily raise information on the format through Google, which wasn't really
the case when I last looked for background on graphics encoding.

Joseph

[R. Joseph Newton]

Kevin Goodsell wrote:

> Third, only in relatively bad cases will GIF require a byte for every
> pixel. For example, I just created a solid white 200 by 200 image.
> That's 40,000 pixels. The file size is 345 bytes. One byte per pixel is
> what you would get if no compression was used at all (probably what
> happened in this case, but not what happens in general), or if the
> compression performed so badly that it might as well have not been used
> (which is rare for typical images).
>
> -Kevin

Thanks again for the correction. It has spurred some new exploration. I've
been looking at the published standard on the format, and it is not at all
like I had assumed. I'm afraid I was lumping it in with BMP and TIFF.
Anyway, I am starting to untangle the coding:

Greetings! E:\d_drive\perlStuff>perl -w
open IN, 'fullhead.gif';
binmode IN;
local $/;
my $img = <IN>;
my @bytes = split //, $img;
my $gif_type;
for (1..6) {
$gif_type .= shift @bytes;
}
print "$gif_type\n";
my $width = ord(shift @bytes);
$width += 256 * ord(shift @bytes);
my $height = ord(shift @bytes);
$height += 256 * ord(shift @bytes);
print "Width: $width Height: $height\n";
my $control_string = ord (shift @bytes);
my $is_map = $control_string / 128;
$control_string %= 128;
my $bit_resolution = int(($control_string / 16) + 1);
$control_string %= 16;
$control_string %= 2;
my $bits_per_pixel = $control_string;
my $background_color = ord(shift @bytes);
print "Background is $background_color\n";
my $color_map = ord(shift @bytes);
print "Color map is $color_map\n";
my @colors;
for (my $i = 0; $i < 2 ** $bit_resolution; $i++) {
my $color_channels = {};
$color_channels->{'red'} = ord(shift @bytes);
$color_channels->{'green'} = ord(shift @bytes);
$color_channels->{'blue'} = ord(shift @bytes);
push @colors, $color_channels;
print 'R: ', sprintf ("%03d", $color_channels->{'red'}),
' G: ', sprintf ("%03d", $color_channels->{'green'}),
' B: ', sprintf ("%03d", $color_channels->{'blue'}), "\n";
}

foreach my $char (@bytes) {
my $byte = ord($char);
my $first_nibble = int($byte / 16);
my $crumbs = $byte % 16;
print "$first_nibble\n$crumbs\n";
}
print 'Data size was ', my $byte_size = @bytes, "\n";

^Z
GIF89a
Width: 30 Height: 16
Background is 0
Color map is 0
R: 000 G: 000 B: 000
R: 128 G: 000 B: 000
....
2
1
15
9
0
4
0
1
0
0
....
3
11
Data size was 117

Right now, I'm sort of tracking as I read the spec. I swear to Gawd, I
couldn't find anything like this last time I went a-hunting!

It's not very often that you'll see me writing this much flush-left scrit,
but right now I just want to follow a file through sequentially, and deal
with each part as it comes.

Joseph