large image size = preset not created

I'm having the same problem on Drupal 5.

Here's some of my settings.

Drupal 5.0
PHP Version 4.4.4
max_execution_time 50000
memory_limit 40M
post_max_size 8M
upload_max_filesize 20M

GD library bundled (2.0.28 compatible)
Content 5.x-1.2
Image 5.x-1.x-dev
Imagecache 5.x-1.x-dev

Hey fellas, sounds like a pretty bad problem. Just clarifying what we're dealing with here. Are the presets not being created or are resized images not being created for a preset?

Thanks!

The resized images aren't being created.

The presets work just fine for images that are small enough. Looks like images below 300KB are resized properly. For large images, no resized images are created.

I'll try to narrow down where the cut-off is.

Can anyone with working imagecache share their php settings? I'm wondering if this is a problem with the image libraries.

I looked at image_scale in image.inc, and didn't find anything obviously wrong. This function is behaving normally even when my resized image isn't created.

One suggestion:

When I upload a very small image, and I'm resizing to "inside" given dimensions, imagecache throws this error: "Imagecache scale action ID 2 failed."

The scale action fails because the image is already small enough. "Failed" implied that something went wrong. A better error might be something like "Imagecache scale action ID 2 was not carried out."

I think something is going wrong in the img_gd_resize function in image.inc.

The function doesn't make it past this line in image.inc:

$im = image_gd_open($source, $info['extension']);

Here are the values just before this line:
$source is /tmp/huge_13.jpg
$info['extension'] is jpg

I guess I'll move on to img_gd_open.

I just want to say keep up the good work! I'll try to make sure the change gets in once we figure out what the problem is. Thanks!

Looking in img_gd_open, I find that it dies any time I try to do anything with
$open_func($file)

Where $file is /tmp/huge_18.jpg
And $open_func is imageCreateFromjpeg

I was concerned that maybe the largest images weren't being resized because PHP didn't like the EXIF and thumbnail info that digital cameras add.

So I opened the original image in GIMP and saved it without EXIF or thumbnail info. Didn't help.

I made a drawing with GIMP, 2272x1704. I tried it at different jpeg quality
settings, from 100 on down to 10. Didn't work for any of these. At 100 this was
1.36MB, at 80 it was 355K, at 10 it was 109K.

Then I resized it to 1000x750. The saved file was 389K. Worked like
a charm. The preset was resizing it to "inside" 300x300.

My PHP memory_limit is 100M.

Closer to a solution...

I included this in the body of a page
passthru("ulimit -a")

And found out that I really only have 36M memory, despite what other tests have said.

That memory limit may be the problem.

How big was the original image, and what is the php max execution time?

I gave some of the image sizes above. The original photo, which is the kind of image that will be uploaded to the site on a regular basis, is 993K, 2272x1704.

max_execution_time 50000

beneditt, I'm trying to emulate your results, but I'm not having success. I uploaded a 3.3MB photo at 4096x3072 pixels and didn't have any trouble. I didn't even increase any defaults:

max_execution_time = 10 ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)

I'm setting to needs more info. I haven't been able to reproduce these problems myself.

After tracing through for an hour or two to the $open_func($file) statement, I decided to change issue status to "All" and found this issue. Could we change status back to active so this issue shows in the list from the modules page?

On my host (modwest.com) it's writing this to error_log.

FATAL: emalloc(): Unable to allocate 8192 bytes

Here's a phpinfo()
http://phpinfo.modwest.com/

Just an update...

My memory limit was set to 64mb. So I tried the "ulimit -a" test and found that I was still limited by my host to 32mb. So I think GD can't get the memory it needs to convert. It's well documented that PHP/GD will just "crap out" on certain errors. This is one example, I guess. Modwest suggested trying ImageMagick because it's not subject to GD's PHP memory limit. So I'm looking at updating the ImageMagick toolkit for 4.7.6. Anyone have any experience with that?

Chris.

We moved the Drupal site from the test server to the production server, which has different PHP settings. And that fixed the problem!

Here are the settings on the new site, according to phpinfo:

Drupal 5.0
PHP Version 4.3.9
max_execution_time 300
memory_limit 200M (this is much more than the old site)
post_max_size 25M
upload_max_filesize 25M

GD library bundled (2.0.28 compatible)
Content 5.x-1.2
Image 5.x-1.x-dev
Imagecache 5.x-1.x-dev

Since the problem disappeared with a different PHP setup, it seems to me this is not a problem with the module. Can this issue be closed?