Re: Reduce file size with Imager
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. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Reduce file size with Imager
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 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Reduce file size with Imager
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\perlStuffperl -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
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response
Re: Reduce file size with Imager
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 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Reduce file size with Imager
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 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
