I have a website with images upload/show functionality on it. All images are saved into filesystem on a specific path.
I use Yii2 framework in the project. There isn't straight way to the images and all of them requested by specific URL. ImageController proceses the URL and takes decision about image resizing. ImageModel does the job. The user get image content.
Here the code snippet:
$file = ... // full path to image
...
$ext = pathinfo($file)['extension'];
if (file_exists($file)) {
// return original
return Imagine::getImagine()
->open($file)
->show($ext, []);
}
preg_match("/(.*)_(\d+)x(\d+)\.{$ext}/", $file, $matches);
if (is_array($matches) && count($matches)) {
if (!file_exists("{$matches[1]}.{$ext}")) {
throw new NotFoundHttpException("Image doen't exist!");
}
$options = array(
'resolution-units' => ImageInterface::RESOLUTION_PIXELSPERINCH,
'resolution-x' => $matches[2],
'resolution-y' => $matches[3],
'jpeg_quality' => 100,
);
return Imagine::resize("{$matches[1]}.{$ext}", $matches[2], $matches[3])
->show($ext, $options);
} else {
throw new NotFoundHttpException('Wrong URL params!');
}
We don't discuss data caching in this topic.
So, I wonder about efficient of this approach. Is it ok to return all images by PHP even they aren't changed at all? Will it increase the server load?
Or, maybe, I should save images to another public directory and redirect browser to it? How long does it take to so many redirects on a single page (there are can be plenty images). What about SEO?
I need an advice. What is the best practice to solve such tasks?
You should consider using sendFile() or xSendFile() for sending files - it should be much faster than loading image using Imagine and displaying it by show(). But for that you need to have a final image saved on disk, so we're back to:
We don't discuss data caching in this topic.
Well, this is actually the first thing that you should care about. Sending image by PHP will be significantly less efficient (but still pretty fast, although this may depend on your server configuration) than doing that by webserver. Involving framework into this will be much slower (bootstrapping framework takes time). But this is all irrelevant if you will resize the image on every request - this will be the main bottleneck here.
As long as you're not having some requirement which will make it impossible (like you need to check if the user has rights to see this image before displaying it) I would recommend saving images to public directory and link to them directly (without any redirection). It will save you much pain with handling stuff that webserver already do for static files (handling cache headers, 304 responses etc) and it will be the most efficient solution.
If this is not possible, create a simple PHP file which will only send file to the user without bootstrapping the whole framework.
If you really need the whole framework, use sendFile() or xSendFile() for sending file.
The most important things are:
Do not use Imagine to other things than generating an image thumbnail (which should be generated only once and cached).
Do not link to PHP page which will always only redirect to real image served by webserver. It will not reduce server load comparing to serving image by PHP (you already paid the price of handling request by PHP) and your website will work slower for clients (which may affect SEO) due to additional request required to get actual image.
If you need to serve image by PHP, make sure that you set cache headers and it works well with browser cache - you don't want to download the same images on every website refresh.
I'm programming a tool that gathers images uploaded by a user into a zip-archive. For this I came across ZipArchiveAdapter from Flysystem that seems to do a good job.
I'm encountering an issue with the memory limit when the amount of files in the zip archive goes into the thousands.
When the amount of images for a user starts to go beyond a 1000 it usually fails due to the available memory being exhausted. To get to the point where it seems to handle most users with less than 1000 images I've increased memory limit to 4GB, but increasing it beyond this is not really an option.
Simplified code at this point:
<?php
use League\Flysystem\Filesystem;
use League\Flysystem\ZipArchive\ZipArchiveAdapter;
use League\Flysystem\Memory\MemoryAdapter;
class User {
// ... Other user code
public function createZipFile()
{
$tmpFile = tempnam('/tmp', "zippedimages_");
$download = new FileSystem(new ZipArchiveAdapter($tmpFile));
if ($this->getImageCount()) {
foreach ($this->getImages() as $image) {
$path_in_zip = "My Images/{$image->category->title}/{$image->id}_{$image->image->filename}";
$download->write($path_in_zip, $image->image->getData());
}
}
$download->getAdapter()->getArchive()->close();
return $tmpFile;
// Upload zip to s3-storage
}
}
So my questions:
a) Is there a way to have Flysystem write to the zip-file "on the go" to disk? Currently it stores the entire zip in memory before writing to disk when the object is destroyed.
b) Should I utilize another library that would be better for this?
c) Should I take another approach here? For example having the user download multiple smaller zips instead of one large zip. (Ideally I want them to download just one file regardless)
I have a PHP script that creates a very tall image and draws a lot of lines on it (an organizational web kind of look). For the tallest images I've tried creating, the line drawing just stops abruptly toward the middle to bottom of the image: http://i.imgur.com/4Plgr.png
I ran into this problem using imagecreate(), then I found out that imagecreatetruecolor() can handle larger images, so I switched to that. I'm still having the same problem, but the script can now handle somewhat larger images. I think it should be drawing about 1200 lines. The script doesn't take more than 3 seconds to execute. Here's an image that executed completely: http://i.imgur.com/PaXrs.png
I adjusted the memory limits with ini_set('memory_limit', '1000M') but my scripts never reach near the limit.
How do I force the script to keep drawing until it finishes? Or how can I use PHP to create an image using less memory (which I think is the problem)?
if(sizeof($array[0])<300)
$image=imagecreate($width,$height);
else
$image=imagecreatetruecolor($width,$height);
imagefill($image,0,0,imagecolorallocate($image,255,255,255));
for($p=0; $p<sizeof($linepoints); $p++){
$posx1=77+177*$linepoints[$p][0];
$posy1=-4+46*$linepoints[$p][1];
$posx2=77+177*$linepoints[$p][2];
$posy2=-4+46*$linepoints[$p][3];
$image=draw_trail($image,$posx1,$posy1,$posx2,$posy2);
}
imagepng($image,"images/table_backgrounds/table_background".$tsn.".png",9);
imagedestroy($image);
function draw_trail($image,$posx1,$posy1,$posx2,$posy2){
$black=imagecolorallocate($image,0,0,0);
if($posy1==$posy2)
imageline($image,$posx1,$posy1,$posx2,$posy2,$black);
else{
imageline($image,$posx1,$posy1,$posx1+89,$posy1,$black);
imageline($image,$posx1+89,$posy1,$posx1+89,$posy2,$black);
imageline($image,$posx1+89,$posy2,$posx2,$posy2,$black);
}
return $image;
}
I'm going to take a guess that you have created a memory leak, and as you do more operations on a larger image you are eventually hitting PHP's memory limit. Rather than raise the limit, it would be better to find the leak.
Try changing your code so it explicitly deallocates the color you are creating in draw_trail. Also, there is no reason to return $image since you are passing a resource around.
if(sizeof($array[0])<300)
$image=imagecreate($width,$height);
else
$image=imagecreatetruecolor($width,$height);
imagefill($image,0,0,imagecolorallocate($image,255,255,255));
for($p=0; $p<sizeof($linepoints); $p++)
{
$posx1=77+177*$linepoints[$p][0];
$posy1=-4+46*$linepoints[$p][1];
$posx2=77+177*$linepoints[$p][2];
$posy2=-4+46*$linepoints[$p][3];
draw_trail($image,$posx1,$posy1,$posx2,$posy2);
}
imagepng($image,"images/table_backgrounds/table_background".$tsn.".png",9);
imagedestroy($image);
function draw_trail($image,$posx1,$posy1,$posx2,$posy2)
{
$black=imagecolorallocate($image,0,0,0);
if($posy1==$posy2)
imageline($image,$posx1,$posy1,$posx2,$posy2,$black);
else
{
imageline($image,$posx1,$posy1,$posx1+89,$posy1,$black);
imageline($image,$posx1+89,$posy1,$posx1+89,$posy2,$black);
imageline($image,$posx1+89,$posy2,$posx2,$posy2,$black);
}
imagecolordeallocate($black);
}
OP here. I figured out, or at least got around, my problem. I was drawing a lot of lines on the image, and the way my code got those points created a lot of repeats, so I still suspect it was a memory problem. I consolidated all the points, taking out the repeats and now it works just fine. Thanks to anyone that tried to help.
I really can't understand why GD has different function for loading images such like:
imagecreatefromjpeg()
imagecreatefrompng()
imagecreatefromgif()
While there is a single function if the image is string?
imagecreatefromstring()
Indeed it's much better to read the image into the string and pass it to the function, something like:
$imgBlob = file_get_contents($imagePath);
imagecreatefromstring($imageBlob);
unset($imgBlob); //> Free memory, but I am not interested in memory consumpation
? Or I am missing something ? This could led to potential confusion for new users
Maybe they just forgot to create a function imageCreateFromFile()?
Ps. Of course I am not interested about memory consumation using the file_get_contents method
imagecreatefromstring() runs a switch against the passed image type, checks if your system has support for that image type, and then actually runs the correct imagecreatefrom* function.
You can check out the source code to see this: https://github.com/php/php-src/blob/master/ext/gd/gd.c?source=cc (line 2280 for the function, line 2301 where it switches on the image type and calls the correct function).
So, the imagecreatefromstring() function is really just a helper wrapper. You'll get a very slight benefit from not running _php_image_type (line 2217) if you call the actual image type function.
imagecreatefromjpeg()
imagecreatefrompng()
imagecreatefromgif()
create image resource from a file - you pass file path as parameter and that's the only acceptable input.
imagecreatefromstring()
creates image resource from string, not file - it could be virtually anything, you can even type in a content. For example you can use
imagecreatefromstring(base64_decode('R0lGODlhAQABAJAAAP8AAAAAACH5BAUQAAAALAAAAAABAAEAAAICBAEAOw=='));
to get 1x1 pixel transparent gif (useful for tracking gifs)
Granted, you could pass everything through imagecreatefromstring, but it would not be memory efficient - handling large images takes a lot of memory and with low memory limit that makes a huge difference.
Like so many before me, I'm writing a PHP script to do some image thumbnailing. The script has earned WOMM (works on my machine) certification, but when I move it to my host (1&1 Basic), there's an issue: images above a certain filesize cannot be processed. I've moved all operations to the filesystem, to be certain it's not some latent POST issue. Here's the relevant code:
function cropAndResizeImage( $imageLocation )
{
//
// Just to be certain
//
ini_set('display_errors','on');
error_reporting(E_ALL);
ini_set('memory_limit','128M');
ini_set('max_execution_time','300');
$image_info = getimagesize($imageLocation);
$image_width = $image_info[0];
$image_height = $image_info[1];
$image_type = $image_info[2];
switch ( $image_type )
{
// snip...
case IMAGETYPE_JPEG:
$image = imagecreatefromjpeg($imageLocation);
break;
default:
break;
}
// snip...
}
Using my mystical powers of println debugging, I've been able to determine that imagecreatefromjpeg is not returning; in fact, the script halts completely when it gets to it. Some facts:
This is correlated to filesize. Images under 1MB appear to be fine (spot-checked), but images around 3MB barf. No clue what the precise cutoff is, though.
This is not due to server timeouts; wget returns in <1s on 3MB images, significantly longer on "appropriately small" images (indicating no processing of large images).
Prefixing the function call with # to suppress errors has no effect. This matches well with the fact that the script is not throwing an error, it's simply silently terminating upon this function call.
If I had to guess, there may be some GD parameter that I don't know about (or have access to) that limits input file sizes on 1&1's servers — the config variable guess is due to the fact that it barfs immediately, and doesn't appear (heuristically) to do any actual loading of or computations on the image.
Any suggestions? Thanks for the help.
Update (courtesy #Darryl's comments): calls to phpinfo indicate that PHP is updating the max_execution_time and memory_limit variables correctly. This doesn't necessarily mean that these resources are being allocated, simply that they appear to be functioning as expected.
Update 2: following some references from The Google, I tried optimizing the JPEG (reduced in quality from 3MB to 200KB) with no luck, so it's not an image filesize issue. I then tried reducing the number of pixels of the original 3888x2592 image, and the first successful size is 1400x2592 (1401x and 1402x both result in half-parses and errors indicating "malformed JPEG", which doesn't make much sense unless the entire image isn't being loaded). By reducing further to 1300x2592, I can instantiate the 400x300 thumbnail image that I'm actually looking for; at 1400x2592, the imagecreatetruecolor call I'm using to take care of that task fails silently in the same manner as imagecreatefromjpeg.
As to why this is, I'm a little uncertain. 1400 * 2592 == 3.5MB gives nothing particularly meaningful, but I have to imagine this is a limit on the number of pixels GD + PHP will process.
Please see this note regarding memory usage on the php website.
*"The memory required to load an image using imagecreatefromjpeg() is a function of the image's dimensions and the images's bit depth, multipled by an overhead.
It can calculated from this formula:
Num bytes = Width * Height * Bytes per pixel * Overhead fudge factor"*
I'm guessing 1&1 doesn't allow you to change scripts memory_limit or max_execution_time, so it's probably running out of memory. Have you tried running phpinfo() to see what the limits are?