I have a databse containing amongst other things many images stored as
BLOBS.

When listing, currently I download all the images full size and let he
browser do the reduction to thumbnails.

It's getting a little slow on long lists.

Is there anyway to take the data and scale it down on the fly to a
smaller image? I have plenty of processor power, just not much bandwidth.


The images are a mixture of GIF, JPEG and PNG.

The Natural Philosopher wrote:
> I have a databse containing amongst other things many images stored as
> BLOBS.
>
> When listing, currently I download all the images full size and let he
> browser do the reduction to thumbnails.
>
> It's getting a little slow on long lists.
>
> Is there anyway to take the data and scale it down on the fly to a
> smaller image? I have plenty of processor power, just not much bandwidth.
>
>
> The images are a mixture of GIF, JPEG and PNG.
>
>

imagecreatefromstring() is your friend. Then just resize to your liking
and output as normal.

--
Norman
Registered Linux user #461062

Norman Peelman wrote:
> The Natural Philosopher wrote:
>> I have a databse containing amongst other things many images stored as
>> BLOBS.
>>
>> When listing, currently I download all the images full size and let he
>> browser do the reduction to thumbnails.
>>
>> It's getting a little slow on long lists.
>>
>> Is there anyway to take the data and scale it down on the fly to a
>> smaller image? I have plenty of processor power, just not much bandwidth.
>>
>>
>> The images are a mixture of GIF, JPEG and PNG.
>>
>>
>
> imagecreatefromstring() is your friend. Then just resize to your liking
> and output as normal.
>
Looks good.Any special libraries needed? having hell trying to install
imagemagick..

Norman Peelman wrote:
> The Natural Philosopher wrote:
>> I have a databse containing amongst other things many images stored as
>> BLOBS.
>>
>> When listing, currently I download all the images full size and let he
>> browser do the reduction to thumbnails.
>>
>> It's getting a little slow on long lists.
>>
>> Is there anyway to take the data and scale it down on the fly to a
>> smaller image? I have plenty of processor power, just not much bandwidth.
>>
>>
>> The images are a mixture of GIF, JPEG and PNG.
>>
>>
>
> imagecreatefromstring() is your friend. Then just resize to your liking
> and output as normal.
>
Well MANY thanks..

After struggling to get Gdlib on one machine..it was magically on the
other..I didn't realise that php5-gd was an extra debian package

the final send-thumbnail.php is, with obvious inclides to access
databases etc, as follows.

It sends a 100PX wide picture of anything it understands in the
database: speed is about ten times greater than with the original mostly
480px wide images.

The actual code that calls the sub file is
<?
printf("<IMG src=\"send_thumbnail.php?id=%d\"
width=\"100px\">",$product_id);
?>
and send_thumbnail.php itself is..

<?php
$privilege_level=0; // only we an access anything..external users must
match,
include('shoplib.php'); // deals with privilege levels and database
opening..
// include('mimelib.php'); //Always use JPEG now!!
open_database(); // ready to check
$id=$_GET['id'];
$query="select picture from product where id='".$id."'";
//echo $query;
$result=mysql_query($query);
if(($result>0) && (($rows=mysql_numrows($result)) == 1)) //got some data
{
$content=mysql_result($result,0,'picture');
}
else die();
if ($name="") die();

// now to shrink the picture..
$im=imagecreatefromstring($content);
// get sizes
$width=imagesx($im);
$height=imagesy($im);
// our thumbnails are 100px wide..dont care about the height so scale as
width
$newheight=round(($height*100)/$width);
$newwidth=100;
$thumbnail=imagecreatetruecolor($newwidth,$newheig ht); // make empty new
wotsit.
imagecopyresampled($thumbnail,
$im,0,0,0,0,$newwidth,$newheight,$width,$height);
header("Content-Type: image/jpeg");
imagejpeg( $thumbnail,null,75);
?>

..oO(The Natural Philosopher)

>After struggling to get Gdlib on one machine..it was magically on the
>other..I didn't realise that php5-gd was an extra debian package
>
>the final send-thumbnail.php is, with obvious inclides to access
>databases etc, as follows.
>[...]

You should definitely add some caching to store the resized images on
disk (outside the document root) or in the DB as well. Scaling images is
one of the most time-consuming processes. You don't want to do the same
thing over and over again, since this just creates another bottleneck.

Micha

Michael Fesser wrote:
> .oO(The Natural Philosopher)
>
>> After struggling to get Gdlib on one machine..it was magically on the
>> other..I didn't realise that php5-gd was an extra debian package
>>
>> the final send-thumbnail.php is, with obvious inclides to access
>> databases etc, as follows.
>> [...]
>
> You should definitely add some caching to store the resized images on
> disk (outside the document root) or in the DB as well. Scaling images is
> one of the most time-consuming processes. You don't want to do the same
> thing over and over again, since this just creates another bottleneck.
>
> Micha
Good point, but in this case it not necessary here at this point.

The machine is a small commercial server on the end of an ADSL line
essentially 448Kbps as far as downloading FROM it goes..

If it were to get 1000 hits a day we would be over the moon.
Its does noting else BUT display HTML stuff largely, so has plenty spare
capacity.

The original images are not huge..mostly 480-640 pixels wide...its
purely to display shop style product shots so we don't have a huge
amount of RAM or processing power being taken up either. In any case RAM
is cheap.


The reason to resize was taken because we had an excess of processing
power over bandwidth.

Ecah picture in the list is a separate threaded instance of php/apache
anyway, so its not a huge per prioess load. Just a lot of little
processes. ;-)

Michael Fesser wrote:

> You should definitely add some caching to store the resized images on
> disk

....why make them on the fly?
Weather blobs in the database or images on the file system,
the big photos are already there. Adding a few thumbnails won't break
the disk space bank. If you do make them on the fly, then you would
need caching.....but it seems likely you'd run out of ram before
disk space. So making them in advance is still a better solution,
I think. That's what I do (make any missing thumbs at night, from cron).

Victor Remose wrote:
> Michael Fesser wrote:
>
>> You should definitely add some caching to store the resized images on
>> disk
>
> ...why make them on the fly?
> Weather blobs in the database or images on the file system,
> the big photos are already there. Adding a few thumbnails won't break
> the disk space bank. If you do make them on the fly, then you would
> need caching.....but it seems likely you'd run out of ram before
> disk space. So making them in advance is still a better solution,
> I think. That's what I do (make any missing thumbs at night, from cron).
>
>
Well, if I had thought about it first, I would have made them on the fly
when uploaded and stuffed them in the database..as well..but suh is history.

It's a quick hack to solve a problem *well enough* for now...