Uploading and resizing a large image, how do sites like Flickr do it?

I've got a script that allows a signed in user to browse their computer and upload an image. The script then resizes the uploaded image, once for the correct display size and secondly for a thumbnail.

It all works fine but.....only for smallish images :(

By trial and error any image bigger than 200k tends to break the entire script and I get an ugly error page.

I tried fixing it by adding a size filter:
//check size
if ($_FILES["file"]["size"] > 200000){
header("Location: http://www.myDomain.com/tooBigError.php");
exit();
}

That kind of works (sometimes even a 194k file trips the filter) but 200k is ridiculously low, especially when the users I'm targetting are likely to be taking their pictures with hi-res digital cameras. Also anything way bigger than 200 completely breaks the script and I get an error again! Sometimes I get a php memory error too.

I've tried all sorts of things but short of directing the users to an image resize site (an ugly solution) I'm out of ideas. Ideally I'd like to be able to upload images of 3Mb.

I'm on a decent but shared hosting package, just wondering how Flickr and other sites easily upload large images with no problems?

Anybody know? All ideas welcome!

It might help to know the error message to help us narrow down the problem.

Hi,

I have run into this issue too: if you resize using GD functions, the non-compressed rgb image must fit within your php memory allowance. If you are lucky, your hosting provider will increase that for you.
On one server where this was not an option, but imagemagick was installed as a program (not just another php function), and exec was not available either, I finally chose to make a virtual call to a cgi that execs the imagemagick converter. Note: you will have to make sure that this script cannot be abused - it has no access to your php sessions

Musicman

Thanks for the replies guys. Basically I get 2 errors...

A) Any image more than 1500 pixels wide generates a memory error:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 6400 bytes) in /vhost/vhost6/c/a/m/mydomain.com/www/assets/myUploadScript.php on line 199

B) Any image with a filesize greater than 510k gets a "Problem loading page: myUploadScript.php not found/unavailable etc etc"

I've tried using an .htaccess file to change the memory allocation (pumped it up from 8M to 64M, that too high?) and FANTASTIC....I can now upload and resize images as large as 3000px, but...

and here's a killer ONLY if that image is no greater than 510k, I've somebody's suggestion of placing:

Code:

---

ini_set('post_max_size', '8M');
ini_set('upload_max_filesize', '8M');

---

In the beginning of my "myUploadScript.php" but it didn't change anything.

Thanks for the help guys, I'm halfway there on this problem now, if I can somehow raise the upload limit above 500k I've cracked it.

Is there any more I can do to the .htaccess to lick that problem do you think?

ini_set will not work on 99% of shared servers. You should contact your host to see how you can up that limit. Most of the time you can place your own php.ini file in the root of your ftp and the host will pick it up or you can use htaccess to set those limits.

Thanks sstalder, I've tried altering both upload_max_filesize and post_max_size in my .htaccess file but doing that, or even one of them completely breaks the entire site!

Is there a correct way to add multiple lines on an .htaccess file? i.e is the following wrong:

php_value memory_limit 64M
upload_max_filesize 4M
post_max_size 16M

I think I may have found the issue, from my own testing it seems anything greater than 510k breaks the site well from this site: http://www.radinks.com/upload/config.php check this out:

Quote:

---

Apache Settings

The apache webserver has a LimitRequestBody configuration directive that restricts the size of all POST data regardless of the web scripting language in use. Some RPM installations sets limit request body to 512Kb. You will need to change this to a larger value or remove the entry altogether.

---

hmmmm....god knows how you bypass that on a shared server, LimitRequestBody...wow what can you do with that?

Hi,

getting back to my previous post: one particular server showed the same problem, and it turned out that the problem could be bypassed by uploading to a cgi script rather than php. In this particular situation, behaviour was sporadic (e.g. a file of 540k or 1.2M would fail, while 1.1M might work) So there may be another cause other than the apache setting you mentioned.
Integrating the upload.cgi with the existing php framework was a nightmare, though

Musicman

Thanks Musicman,

I'd try the .cgi method but I'm guessing its more complicated then renaming the file extension right! ;)

Someone suggested this little uploading applet: http://www.jumploader.com/
that replaces <input type="file"> etc. It works great and has a lovely little progress bar but.....you guessed it, on my shared server it only works for images < 513k!

The old Apache limitRequestBody defeats that too.

I finally had a response from the tech support, they can't raise/remove this problematic upload limit but he has 2 ideas:

1. Try it with a Pearl script
2. Upgrade to a Virtual Private Server.

If you spend say £110 annual fee on a simple Linux shared hosting package, have that for 5 months then want a £140 Virtual server will most hosts charge you the full £140 or offer you some special "upgrade price"?

Just wondering whether this is gonna cost me £30 or £140!

Hi,

try a cgi upload script on your server first; this will reveal whether the problem is inside apache or inside php.
The problem machine I mentioned before is a managed dedicated server (i.e. a handful of domains owned by the same customer). We can call support to change settings, but they wont recompile any software - and every now and then their patch management will revert some changes they made for us.
Depending on what this "virtual server" really is, it will either force you to maintain the system or restrict you in what you can do with the installed software.
As for "upgrading": a while ago I needed an upgrade - replacing a complete box by one with more cpu and memory. The hosting company charged their usual setup fee for the new server but arranged for the two machines to run side by side for one month, for a smooth transition.

Musicman