GIF89a is animated? ...interesting. This is the code that I'm using to convert the tif's to gif's:
foreach (@image){
my $image=Image::Magick->new();
$image->Read($_);
$image->Write(substr($image->Get('filename'), 0, length($image->Get('f
+ilename'))-4).".gif");
}
I manually opened one of my tif's and 'save as...' a gif in one of my graphic editing programs, opened the gif in notepad, and it still had the 'GIF89a' at the beginning of the string. What is the non-animated supposed to have?
The original tif's are simple b&w scanned docs, so gif's are MUCH smaller than jpgs in this case. I read that node on handling blobs, but it referred to MB's of data. All the gif's ended up being between 5K-32K, so I assume (correct me if I'm wrong) that I don't have to deal with breaking the data up into chucks??? Will it speed things up if I do? It doesn't look like I'm losing any of the data in inserting or retrieving the data if the hex string is exactly double the raw data directly from the file.
juster--I added the lines of code:
my $rawData = pack 'H*', $data->{BackImg};
print $q->header(type=>'image/gif', Content_Length=>length($rawData)).
+$rawData;
if($blob ne $rawData){die $rawData."\nlength=".length($rawData)."\nfil
+e image = ".$blob."\nlength=".length($blob);}
...but $rawData is an empty string. What am I missing?
Referencing the file instead of putting it in the db would certainly optimize the db, however, for this application and our network configuration (there are a total of 4 servers involved...long story, don't ask), storing the images inside the db works better.
--ksublondie |