in reply to Re: insert & retrieve images from DB to web
in thread insert & retrieve images from DB to web

I got chastised by this before, so I remember it.......89a handles animation, but does not mean it is animated. It is a newer format that handles other things. 87a can be animated too. See Gif 87a/89a

I'm not really a human, but I play one on earth Remember How Lucky You Are
  • Comment on Re^2: insert & retrieve images from DB to web

Replies are listed 'Best First'.
Re^3: insert & retrieve images from DB to web
by ksublondie (Friar) on Sep 05, 2008 at 16:18 UTC
    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
      What is the non-animated supposed to have?

      There is no way to tell if a gif87a or gif89a is animated by the header.(well maybe deep down in there). Your best bet is to use Image::Info or something similar to check the Image

      #!/usr/bin/perl -w use strict; use Image::Info qw(image_info); use Data::Dump; while (@ARGV) { print Data::Dump::dump(image_info(shift)), "\n"; }
      If you run animated gifs thru that you will get a parameter called GIF_Loop, that may be a way of detecting it. Some graphics module may have an is_animated method, but I don't know of one off hand.

      I'm not really a human, but I play one on earth Remember How Lucky You Are
      I spoke too soon. The hex conversion worked!!! However, some of the images are incomplete. I had changed a line above the hex conversion from my original that didn't work. MS sql must be automatically converting the raw data to hex when it's inserted to the db.

      --ksublondie

        Cool! now regarding the incomplete images I found a snippet earlier on DBI and blobs that may explain your problem if all the images are trunacted to a certain size. I don't have much experience with BLOBS, though.

        I found it in the DBI::FAQ doc under '5.2 How do I handle BLOB data with DBI?'

        As for the first advice to convert to JPEG unconditionally and that GIF89a is only the animated GIF format I would disagree. JPEG was designed for photgraphic images, GIF can get smaller sizes when less colors are necessary. Pretty much every GIF around now is GIF89a, the format that supercedes GIF87a, even if they are not animated.

        As for image file format advice I would convert to PNG. PNG was created to replace the GIF format, has smaller file sizes, increased color depths, transparent alpha blending, and I _think_ a specific grayscale color model. The only downside is older browsers (IE especially) have poor or no support for it. Oh and it isnt animated but that wont affect you.

        some of the images are incomplete

        Just from my previous dealings with animated gifs, you may be seeing the effects of the interlacing and compression. The later gifs, can be optimized for size, and it usually is done by only storing the "changed image pixels" in subsequent images( or something like that concept). What you will need to do is run the animted gif thru a competant extraction utility, that will rebuild each image fully. Try Gifsicle .


        I'm not really a human, but I play one on earth Remember How Lucky You Are
        Just tried the png which would be perfect...however, content type image/png doesn't work and I'm getting the dreaded red 'x' (both IE7 & FF browsers). The raw data LOOKS ok though...

        I'm confused by the animated gif discussion: I'm starting out w/static 2 color tif's (all <14K), running a straight-forward conversion w/ImageMagic to a gif using the defaults, nothing is animated. The 'original' gifs look fine. Somewhere between inserting to db, retrieving from db, and converting data from hex, I'm only getting partial display and/or snow on some images.

        The images that are jacked up are generally, but not all, the larger files. Of the subset that I looked at, most of my bad/partial images are around 30K, but one of them is only 15K, a 27K isn't showing, but a 29K is. The most of my <30K images are showing up. I can try playing with the blob, but when comparing the rawdata size of one of the original gif vs. the jacked output gif, they're the EXACT same length (at most 1B off). So, it doesn't look like I'm truncating data somewhere in the conversion.

        Here's a thought: since inserting raw data mysteriously converts to hex, can I cast or convert in my select to convert back to the raw data? While I eagerly await your response, I'll see if google knows.

        --ksublondie