Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

All other Modules /

Discuss all other Modules here.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Image memory size issue on small images


Reply


6 Posts   2394 Views

Avatar
JohnHughes

Community Member, 8 Posts

18 May 2011 at 1:35pm

I have an image of less than 1000x700 in size.

If I attempt to insert this image into the body of the blog article using the Upload File link in the Image Editor, I get a memory limit error. (Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 17520 bytes) in /home/stripe/public_html/sapphire/filesystem/GD.php on line 32)

If I use this same photo as the main image for the blog article, I can upload and use without error.

If I go to Files & Images, I can upload without error and then insert the image into the body of the blog article.

_ONLY_ when attempting to upload from the Image Editor, do I get this error.

Can someone offer an explanation?

Attached Files
Avatar
honeybunny

Community Member, 79 Posts

18 May 2011 at 11:26pm

The last time this issue came up it was suggested that the problem was caused by the way that the image is resampled. I believe the solution was to increase php memory. For what it's worth, I wouldn't call a 1000 X 700 image small. If it's just an image for an article and not a screen sized splash graphic you could really go down in size quite a bit without losing any clarity. Though I did upload a 1220 X 600 gif in the image gallery yesterday without incident, I try to keep my article pics within a 150 - 250px range and almost never have a problem.

HB

Avatar
JohnHughes

Community Member, 8 Posts

19 May 2011 at 2:47am

1. PHP memory_limit is set at 64M

2. Why does the problem only occur when using the Image Upload function used in the WYSIWYG editor? The limit does not come into play with other methods of uploading and resizing.

Avatar
honeybunny

Community Member, 79 Posts

19 May 2011 at 4:32am

Edited: 19/05/2011 4:34am

I don't have the greatest grasp on how php utilizes resources and I'm not really sure why php memory came into play, but when I had this problem last year I was told it was most likely because of php memory. I was in a hurry and didn't have time to look into it, but my quick fix was to simply make a new directory each month so that pics uploaded through the upload function in the wysiwyg editor so that there were a limited number of pics in one folder. They were still in the assets directory, but different sub-directories. It didn't really make sense, I mean the asset folder still contained all the uploaded files, but I never got the error message again so it seemed to work.

HB

Avatar
Ryan M.

Community Member, 309 Posts

19 May 2011 at 1:03pm

Edited: 19/05/2011 1:05pm

As a developer who builds and updates a number of SS sites using images extensively, I've run into this problem more times than I care to count. Here are the fixes I've employed in the past:

- Increase PHP memory, 64M at least. I have my sites set to 128M. Most shared hosts only allow you to go as high as 64 by default, so you will need a dedicated or dedicated-virtual server to bump it even higher.

- Resample your images before uploading. 120dpi or less is best. Anything over usually trips the memory error. Doesn't matter if your image is only 1000x700 big... I've had images of these dimensions trip the error anyways, because they had print quality resolutions such as 300dpi.

The reason why you only get the warnings in certain places and not others is because in certain places, the upload function also performs some manipulation on the image before saving it, such as creating thumbnail sizes. You can tell by looking at the error message and seeing where it's coming from.. usually the GD library.

Avatar
JohnHughes

Community Member, 8 Posts

19 May 2011 at 1:32pm

Increased PHP.ini memory_limit to 128M and then inserted 1100x900 PNG image into blog article. Image was downsized to 600x491 as part of the embedding process.

(This is on a dedicated server)