Symphony.

For some unknown reason my client wants to upload images directly from his NIKON D700 (4035px?×?2685px) which is a bad idea, but anyway, he the boss.

On my testenvironment this just works fine with JIT scaling these big images with no lament. On the live server, however, those images won't get converted.Symphony Logs are a bit sparse here, only saying, that the requested url (e.g mage/2/450/450/5/) does not exists. Unfortunately php-error loggin is a bit tricky on that server (1&1 hosting), not to say impossible, since setting an errorlog path via htaccess will throw a 500 server error and custom php.ini settings are not applied global but only to the current directory.

I'd bet it might be a memory allocation problem but on the otherhand, I have set my testing environment to the exact same amount of available memory (90M) and even lower and converting still works.

I know that this isn't directly a problem with JIT, but a server related issue, but maybe someone has encountered a similar situation found some possible solutions.

Thanks in advance, Thomas

ok, this ist the only error output I could get so far:

PHP Fatal error: Call to a member function Meta() on a non-object in /extensions/jit_image_manipulation/lib/image.php on line 220

Not much, but at least something.

Double-digit megapixel image uploads as well as 1&1 hosting! Jeez - all the best.

yep, couldn't be worse.

Well, at least I have shell access.

Kazoom!

tracked this thingy down, the breaking point was the load method in class.image and finally imagecreatefromjpeg causes Fatal error: Out of memory (allocated 32768000) (tried to allocate 4035 bytes) As I said! It's not my fault :D

Although, this is strange, I looked up for memory limit via phpinfo and there should be plenty of it (even more than in my testing environment). Maybe that's all 1&1-masquerade.

Nah, that sounds about right. It's quite an intensive process, especially for something that size in dimensions. You never notice the memory usage on smaller images as PHP clears out the garbage quite quickly after the process is run, but for something that big, it will just chew it up before any garbage collection.

The simple answer is to say it can't be done on a shared webhost with images that large. If the client wants that kind of power, they're going to have to fork out some cash for it and get a dedicated host. Or simply just reduce the images first. If they want the large copy available on the web, then persuade them to upload a 'smaller' copy too, to use for display and JIT-ing.

I know it's not the best answer, and I promised myself I'd never advise that about dedicated hosts, but hey, I have.

Get him a flickr pro Account!

I promised myself I'd never advise that about dedicated hosts, but hey, I have

You've not only let us all down, but you've let yourself down too.

But designermonkey is right, if your host does not let you bump up the memory limit (have you tried doing so in your htaccess file?) then you are limited by the processing power a shared host affords.

The cheaper option in the long run might be to get your client using a basic resizer first. There are almost certainly some free ones they could install.

The cheaper option in the long run might be to get your client using a basic resizer first. There are almost certainly some free ones they could install.

Thanks, that made me smile since my clients sits on a mac and therefore has plenty 'free' resizers on board…

Unfortunately 1&1 doesn't allow php settings within htaccess. Memory Limit is set to 90M but thats just spoilage. ulimit -a says 53248 kbytes. Thats it.

I'm now writing a little extension that would resize the uploaded image to a maximum size using imagemagick (at least this works).