Image cropping script [cropcanvas] returns problems on a PHP5 hosting server

[marcofama]

hi guys, I'm new at this forum, so thank you for reading my post!

I am a PHP/mySQL developer, and work on a CMS project that I am used to deliver to my clients after finishing the Adobe Flash site, so that they can easily manage their website after they got it.

This is a two-years CMS project I keep on modifying from time to time, and I got into a huge problem I can't solve.

Some months ago I found a great PHP class called CROPCANVAS , that I included in my coding for a easy cropping interface.
After the cropcanvas produces the output file, I simply rename it and resize the image the way I want.

This script doesn't work on my client's hosting machine. It simply hangs forever, and shows no output image (or sometimes not even the cropping interface as well). Quite often I get this error message:
Fatal error: Allowed memory size of xxxxxxx bytes exhausted

As everything works fine on my computers and on my hosting provider server, I asked some help to the provider customer service, and they told me that "it is for sure my script has some problems with PHP5 and the newest GD library", and this is why it won't work. BTW, I already tried to increase the memory limit from 64M to 80 or more MB but with no result.

They do not even want to switch that domain to a PHP4 server, so I am desperately looking for a solution to this issue.

The original script in action can be found here:
php.amnuts.com demos crop-canvas interactive.php

I would have asked for help on the author's FORUM, but all threads seems to be locked 🙁 so..

Thank you very much for your help, hope to hear from you very soon.

[NogDog]

My guess is that it's not so much a PHP version problem as a configuration problem, specifically the max memory setting. The GD image functions are memory hogs due to each image being stored in memory as a bitmap. The memory requirement is therefore directly proportional to the number of pixels as the color depth, therefore any compression in the source file is immaterial. You can try altering your memory_limit setting, either via [man]ini_set/man in your script or a .htaccess file setting (if on Apache).

[dcalisaya]

Hello,

for one site that has gallery I'm using .htaccess with: php_value memory_limit 128M

May it helps.

[marcofama]

thanks NogDog and dcalisaya for your fast reply!

I already tried increasing that value via

ini_set('memory_limit', '80MB');

and it did not work.
BTW, I took a look at the phpinfo() and found out that "megabytes" is briefly written with a "M" not "MB".

As I just tried to put

ini_set('memory_limit', '80M');

I got the script working with a quite small JPG file (around 1M😎!
Got the same error with a 2MB file, so at the moment I'll try to increase that value to 250M and see what happens.

By the way, I was also trying the

.htaccess with: php_value memory_limit 128M

solution but.. as I never did it, I don't know how to do it.
Is it enough to create an empty txt file, write that string down, and save it as

.htaccess

without name? On my windows system you can't assing the extension only.. how should I do it, dcalisaya?
(update: no way of creating/editing that file. My hosting provider says they don't allow it)

Thanks a lot guys.. 😉

---

small update to my POST:

I found this interesting article:

Bug #33595 recursive references leak memory
http bugs php net bug.php?id=33595

The cropcanvas script, as I understood, initialises a new Obj everytime it runs the PHP page (i.e. test.php in my example script I provided to you before) at
$ci =& new CropInterface(true);
.. I imagine that this might be a problem in increasing the used memory by the script? maybe I should destroy all the obj before run the script (and therefore, clean up the memory)... what do you think? 😕

[Weedpacket]

marcofama wrote:

I got the script working with a quite small JPG file (around 1M😎!

As NogDog pointed out, the compressed size of the file is irrelevant, since the image GD completely uncompresses it to work on it. In other words, the file format is irrelevant. The real size of the file, is width×height×depth (where the depth of a JPEG is usually 3 bytes per pixel (it can be 1 if it's a greyscale JPEG)). I've got a 1MB JPEG file here that will take 1500×1192×3 = 5364000 bytes - 5.1MB - uncompressed. A 2MB image uncompressed to 17.9MB. Then of course there is the memory required to store any intermediate images that are generated along the way, if they're not being destroyed.

Bug #33595 recursive references leak memory

First, a "recursive reference" is when object A refers to object B and object B refers to object A. Even if nothing else refers to them, they're still both being referred to, and the bug is that PHP doesn't clean them out. But even if that is what is happening here, it doesn't matter, because

The cropcanvas script, as I understood, initialises a new Obj everytime it runs the PHP page (i.e. test.php in my example script I provided to you before) at

All of the memory is cleaned out after the script ends, and the next time the page is run it is with clean memory. In the bug report you cite, read dmitry's post of 1st August, 2005.

[Weedpacket]

marcofama wrote:

I got the script working with a quite small JPG file (around 1M😎!

As NogDog pointed out, the compressed size of the file is irrelevant, since the image GD completely uncompresses it to work on it. In other words, the file format is irrelevant. The real size of the file, is width×height×depth (where the depth of a JPEG is usually 3 bytes per pixel (it can be 1 if it's a greyscale JPEG)). I've got a 1MB JPEG file here that will take 1500×1192×3 = 5364000 bytes - 5.1MB - uncompressed. A 2MB image uncompressed to 17.9MB. Then of course there is the memory required to store any intermediate images that are generated along the way, if they're not being destroyed.

Bug #33595 recursive references leak memory

First, a "recursive reference" is when object A refers to object B and object B refers to object A. Even if nothing else refers to them, they're still both being referred to, and the bug is that PHP doesn't clean them out. But even if that is what is happening here, it doesn't matter, because

The cropcanvas script, as I understood, initialises a new Obj everytime it runs the PHP page (i.e. test.php in my example script I provided to you before) at

All of the memory is cleaned out after the script ends, and the next time the page is run it is with clean memory. In the bug report you cite, read dmitry's post of 1st August, 2005.