Capture a stream into variable

[straycat]

I've wrote a script that resizes uploaded images. The funktion imagejpeg() create a jpeg stream, either to a file or diectly to the screen. Is it possible to capture the stream into a varable? If so it could easily be stored in a database.

Unfortunately, imagejpeg() return a boolean value. I tried to put the image resizing code, including the imagejpeg() function i a separate file, hoping that the output from that file could be captured i a variable in the file witch called it. Is that possible, and could someone please show me how that code would lool like that calls the "create_thumbnail.php" file.

Here's the rezising code:

<?php

$src_file = $_GET[image];

$src_handle = fopen($src_file, "r");

$src_img = imagecreatefromjpeg($src_file);
$dest_img = imagecreatetruecolor(120, 100);
imagecopyresampled($dest_img, $src_img, 0, 0, 0, 0, 120, 100, imagesx($src_img), imagesy($src_img));
imagejpeg($dest_img, '', 75);

fclose($src_handle);

?>

[Weedpacket]

One question is what benefit would come from storing it in a database. But in answer to your question: like any function that sends output back to the web server, you can capture that output with the output buffering functions (starting with [man]ob_start[/man]) and store it in a variable.

[straycat]

Thx, it worked fine, but the imagejpeg() function still outputs the string (It's annoying). According to the PHP manual the ob_start() function turns off all output exept header information. Is the jpeg stream somehow header info or does it override ob_start()?

The code at this point:

$thumbnail = createThumbnail($hej);

function createThumbnail($image)
{
   ob_start();

   $src_img = imagecreatefromjpeg($image);
   $dest_img = imagecreatetruecolor(120, 100);
   imagecopyresampled($dest_img, $src_img, 0, 0, 0, 0, 120, 100, imagesx($src_img), imagesy($src_img)); 
   imagejpeg($dest_img, '', 75);

   $buffer = ob_get_contents();

   return $buffer;
}

[dave420]

If you want to save the image to the database, use imagejpeg with the extra "filename" parameter. You can specify a filename into which the picture will be saved. You can then fopen() it and write it to the database, or even give the database the command to pull the file itself.

Also, storing binary things like that in a database might not be the best bet. Just because it's possible doesn't make it a good idea. As Chris Rock says, you can drive a car with your feet...

[Weedpacket]

Originally posted by straycat
Thx, it worked fine, but the imagejpeg() function still outputs the string (It's annoying).

Because you're outputting a JPEG image and not an HTML page, you need to send the appropriate Content-Type: header (as noted on the main [man]image[/man] page itself).

[dave420]

I don't think that's the issue here... I believe they're trying to capture the output of imagejpeg() using output buffering.

Of course, outputting that to the browser would be helped by adding the content-type header (although it's not 100% necessary)

[Weedpacket]

But are they clearing the output buffer after getting the contents? I don't see that happening, either.

[dave420]

There's a bunch of stuff not happening in that script 😉

I think that's the main problem, though. I wouldn't be surprised if imagejpeg() turns output buffering off, which would explain the "still keeps outputting" problems, and the lack of ob_end_flush/_clean...

[Weedpacket]

Originally posted by dave420
There's a bunch of stuff not happening in that script 😉

I think that's the main problem, though. I wouldn't be surprised if imagejpeg() turns output buffering off, which would explain the "still keeps outputting" problems, and the lack of ob_end_flush/_clean...

Nah, I don't think imagejpeg() turns output buffering off, but if the buffer isn't cleaned out afterwards, all that JPEG data will still be in there when the script ends and it all gets flushed to the output anyway.

Of course, this also means that if that function is being called in a loop, then every file from the second one onwards is probably corrupted, because the buffer's still got all the previous JPEG data as well as the current one.

I have to agree with you; it's a bit excessive to use a database for a filesystem.