After uploading a file I'm getting a memory exceeded on nothing but a thumbnail. I can continue and attach the image to the node and view the node, edit, etc...but it shows up as an invalid image in the browser. When I try to navigate directly to the URL in the image source by going to: http://mysite.com/sites/default/files/styles/square_thumbnail/public/bod... I get:
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 720 bytes) in /home/username/public_html/subdomain/modules/system/image.gd.inc on line 303
This is drupal 7 beta 3 with a total of maybe 6 3rd-party libraries installed. It doesn't make sense that generating a thumbnail should exceed a fairly standard server default of 64MB for php. The image is a jpg - size 5x1560 even in memory an image that size wouldn't take more than 64K.
Additionally, after I increase my php memory limit to 128MB, the thumbnail that is generated is a 180x180 Dark gray square.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | image-resize-dimensions-979382-8.patch | 952 bytes | shadowspar |
| #7 | blueweb-vbar.jpg | 17.25 KB | shadowspar |
Comments
Comment #1
mcaden commentedNote: I took my domain out of the url above b/c this is on a sandbox I'm using, I put in mysite.com instead. Don't bother clicking the link - you'll get a 404. On second thought I should've used example.com but I can't edit soo....oh well.
Comment #2
mcaden commentedAHA,
The thumbnail actually enlarges the image if it's below the 180x180 it wants it to be in the end. SO! What that translates into is taking my 5x1560 png image and blowing it up to 180x56160!!! that's 4 bytes per pixel x 180 wide x 56160 high = ~40 meg in memory. From there it's a much smaller jump for php to hit 64 meg usage.
AND it explains why the image (once I bumped php's memory limit) was nothing but a dark grey 180x180 square...the preview was nothing but the top 5x5 square of my image scaled to 3600%.
Comment #3
mcaden commentedAh, this isn't Styles. Styles' thumbnail is merely a resize, it's Media doing image_scale_and_crop that is enlarging the image.
Comment #4
mcaden commentedI'm changing this to minor, most people won't be using 'preview' on an image that is extremely small on one axis. I only ran into this because I tossed up a css background image for the body of one of the themes merely as a test image. It's a vertical image intended to be used with repeat-x. I can't imagine really running into this much.
Comment #5
JacobSingh commentedThis is not a media issue, it might be the core image styles of the Styles module. Putting it there for now.
Comment #6
aaron commentedmoving to core, where the image resizing actually happens.
Comment #7
shadowspar commentedIn the latest D7 dev snapshot, I don't seem to be getting an out of memory error when uploading disproportionately long/tall images. I do, however, get
This is because when
image_scale()inincludes/image.inctries to calculate dimensions to resize the image to, it comes up with numbers like 0.32051282051282 x 100, which by the time it filters back toimage_gd_create_temp()is 0 x 100.Example image that causes the issue attached. Patch pending.
Comment #8
shadowspar commentedThis patch ensures that
image_resize()always returns integers for height and width, and they're at least 1.Comment #9
mcaden commentedThe code in the patch looks sound and it's nice that we found a core issue but that's not the cause of the memory usage here. The heart of this is that resize and crop is taking a 5x1560 and turning it into a 180x56160 in order to get a 180x180 crop. Either media/styles needs to not use this method for its thumbnails or the method needs to be reworked so it doesn't scale images to insane proportions in order to crop 'em.
Comment #10
shadowspar commentedI notice that
image_resize()has code in it to guard against scaling an image up, and I'm wondering if that's been added since this bug was reported. I'm on the road now but I'll take a stab at reproducing the memory issue in D7beta3 when I get back to the office.Comment #12
mcaden commentedI just tested on a 1x5000 size jpg. It seems fine now, no memory exceeded. I guess this was fixed elsewhere. It did generate a preview thumbnail it just took a bunch of processing behind the scenes in order to do so. I did get the same warning mentioned in #7 though. We should probably get the patch for that warning committed and close.
Comment #13
grendzy commented#8: image-resize-dimensions-979382-8.patch queued for re-testing.
Comment #14
fietserwinI'm wading through the iamge system issue queue.
It looks like this problem is related to using the ScaleAndCrop image effect to get a thumbnail of fixed dimensions. This speific image effect always does the resize first and then the crop. I think that first cropping to the new aspect ratio and then resizing will work as well.
Moreover, I think that doing it in this order will always be faster (assuming that cropping is a fast operation and that resizing is a rather slow operation involving some mathematics on each pixel)
I think that memory usage will not always be lower, but will have a lower upper limit that is relatively safe: max(2 * oriignal image, original image + thumbnail image) Whereas doing the resize firs can give you a max of scale * original image.
The edge cases should be worked out though, the above are my intuitions.
If you still want the original issue to be fixed, please
- Rename the title
- Rewrite the issue summary, preferably including some edge case examples
If you want the other edge case (image dimension reaching 0) to be solved, please:
- Create a new issue
- Reroll the patch (using round or even ceil instead of floor, and preferably using max instead of the ternary operator). Please mention the new issue over here.
Comment #15
mgiffordPatch no longer applies.