Welcome to WebmasterWorld Guest from 188.8.131.52
Forum Moderators: not2easy
I'm putting a size limit on the uploads: 3Mb. I think that's a reasonable size limit - big enough for most digital cameras, but not so big as to allow outrageously high resolution graphics. Correct me if I'm wrong.
To test it, I need to create JPG files, where:
1) the filesize is exactly 3Mb
2) the filesize is slightly more than 3Mb (2,999,999 bytes)
3) the filesize is slightly less than 3Mb (3,000,001 bytes)
Any hints how to do this?
fyi I do have PhotoShop
In my script, 3Mb is defined as $limit = (3 * 1024 * 1024) = 3145728, not $limit = 3000000.
I need to be careful that the limit is identical at each stage of the upload. Is a megabyte always (1024^2), or are there times when a megabyte is really (10^6)? This is another topic.
As for file size—you could try creating a new document, then scaling the dimensions until you reach the desired file size (60cm x 21.75 cm @ 72 PPI was close on a quick test in PSCS3)-it displays it within the new file dialogue box. A bit crude but best I could think of.
Alternatively you resize the image in 3~5% increments (save, refresh file view, repeat) until you reach a few KB either side... Even cruder I suppose.
I'm polishing up a feature that lets a user upload a photo.
I'm guessing PHP based. Not sure about the GD toolkit, but Imagick/ImageMagick allows you to set the compression level. What I'd do is set a maximum display size (say 600 px width) then do some math against the compression so it equals +- 3MB. Or work it backwards; 3MB/$compression = (w X h).
you're right rocknbil, I'm using the GD library in PHP5.
The file upload has its limit of 3Mb. I've got that working OK now, and I managed to create a few images that were close to, above and below the limit. good.
When I get the image into memory using imagecreatefromjpeg() [ca3.php.net], the image is stored in memory on the server, uncompressed. So what was a 3Mb upload actually becomes a 40-million-something byte binary object or something. In memory.
This leads to memory allocation issues. The default 8Mb allocated by PHP isn't enough for even a typical snapshot from a contemporary point-n-shoot digital camera. To handle one from my little Sony Cybershot, I had to nudge the memory limit up to 40Mb:
Giving the user >40Mb of memory space to upload their super-high-rez photos is overly benevolent, IMHO.
Overflowing the memory limit causes a Fatal Error. I've got some error handling in this script, but those Fatal Ones... they have a tendency to blow up and quit page execution before I can output a friendly error message. Three options are: 1) increase that memory limit to something outrageous, 2) capture Fatal Errors and handle them after the script has aborted, or 3) detect or predict the uncompressed size of an image in advance and throw a preemptive error back at the user.
I prefer #3.
Is there any way to predict the uncompressed size of a JPG without actually uncompressing it?
I was here a few months back. You can keep cranking that stuff up or switch to Imagick/ImageMagick, it's the stuff.
To predict the uncompressed size you need to be able to read it, to read it . . . well you know, chicken and egg.
I started here [webmasterworld.com], then wound up here [webmasterworld.com]. After working through the problems with Imagick/Imagemagick, there's just no going back to the GD toolkit, even for smaller images. :-)