Posted by not-anymore-use... on October 29, 2009 at 2:06pm
7 followers
| Project: | ImageField |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
As we know ssince #434394: 'HTTP error 0 occurred' on image upload, there is a problem when uploading files, that have a large size when they are uncompressed. As I stated in http://drupal.org/node/434394#comment-2204654, it would be great to have support for ImageAPI, so that we can use ImageMagick for handling larger images, without running into a php memory problem.
Comments
#1
Here's the patch. Thanks to quicksketch for the draft in #512046: Add support for ImageAPI if available
#2
Tested with debug info of imageapi - it work's!!!
So little and usefull patch - waiting to see it commited
#3
looks clear
#4
I added this patch with the latest dev version of Imageapi 6.x.1.x and ImageField 6.x.3.2.
ImageField is still using the core Image Toolkit with GD. Does something else need to be done to get this working?
#5
What toolkit do you use with imageapi? What's the output of the debug-info of imageapi?
ImageAPI should be used automatically.
#6
I'm using ImageMagick 6.5.9-0 2010-01-19 Q16. I turned on debug. When I upload an image with my normal user account there doesn't seem to be any debug info. However, if I use my root drupal admin account I get the following JavaScript popup after hitting upload:
An HTTP error 0 occurred.
/filefield/ahah/story/field_i/0
After clicking OK for the prompt, a page loads with the URL reference above that contains this content:
{ "status": true, "data": "\x3cdiv class=\"messages status\"\x3e\nThe image was resized to fit within the maximum allowed dimensions of \x3cem\x3e120x60\x3c/em\x3e pixels.\x3c/div\x3e\n\x3cdiv id=\"edit-field-i-0-ahah-wrapper\"\x3e\x3cdiv class=\"form-item\" id=\"edit-field-i-0-wrapper\"\x3e\n \x3clabel for=\"edit-field-i-0\"\x3eimg: \x3c/label\x3e\n \x3cdiv class=\"filefield-element clear-block\"\x3e\x3cdiv class=\"widget-preview\"\x3e\x3cdiv class=\"imagefield-preview\"\x3e\x3cimg src=\"http://example.com/sites/default/files/imagefield_thumbs/p/image.jpg\" title=\"image.jpg\" /\x3e\x3c/div\x3e\x3c/div\x3e\x3cdiv class=\"widget-edit\"\x3e\x3cinput type=\"hidden\" name=\"field_i[0][fid]\" id=\"edit-field-i-0-fid\" value=\"437\" /\x3e\n\x3cinput type=\"hidden\" name=\"field_i[0][list]\" id=\"edit-field-i-0-list\" value=\"1\" /\x3e\n\x3cinput type=\"submit\" name=\"field_i_0_filefield_remove\" id=\"edit-field-i-0-filefield-remove\" value=\"Remove\" class=\"form-submit\" /\x3e\n\x3c/div\x3e\x3c/div\x3e\n\x3c/div\x3e\n\x3c/div\x3e\x3cscript type=\"text/javascript\"\x3ejQuery.extend(Drupal.settings.ahah, { \"edit-field-i-0-filefield-upload\": { \"url\": \"/filefield/ahah/story/field_i/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-i-0-ahah-wrapper\", \"selector\": \"#edit-field-i-0-filefield-upload\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"op\": \"Upload\" } }, \"edit-field-i-0-filefield-remove\": { \"url\": \"/filefield/ahah/story/field_i/0\", \"event\": \"mousedown\", \"keypress\": true, \"wrapper\": \"edit-field-i-0-ahah-wrapper\", \"selector\": \"#edit-field-i-0-filefield-remove\", \"effect\": \"fade\", \"method\": \"replace\", \"progress\": { \"type\": \"throbber\" }, \"button\": { \"field_i_0_filefield_remove\": \"Remove\" } } });\x3c/script\x3e" }#7
Onfortunately, this has nothing to do with that patch. Please take some time to read through #434394: 'HTTP error 0 occurred' on image upload. I'm pretty sure, that there is at least one solution, that fixes your problem. Good luck!
#8
The error I reported above seems to be isolated to Opera 10 on Linux (which opens a new can of worms). I just tried logging in to my root account with Firefox 3.5 and didn't have a problem uploading an image. To test whether or not Imageapi is being used, I tried uploading a jpg image with ImageMagick quality set to 80%. I then renamed the file and uploaded again with ImageMagick set to 100%. Both uploaded files have the same file size, which indicates to me that Imageapi is not being used. I then tried adjusting the quality setting for Image Toolkit. Sure enough, the filesize changed.
Are you sure that Imageapi is being used after applying this patch?
#9
Yes, I am. I tested it as well as andypost and Ilya1st. The patch is really simple. Please have a look at the code.
If you upload an image that is smaller than the dimensions of your image field, the image is not touched by ImageAPI. It is only used to resize larger images to fit the dimensions of your image field.
#10
I have correctly applied the patch. I made sure to upload an image that is larger than dimensions of Imagefield. Drupal core Image Toolkit is still being used rather than Imageapi. Is the image placed somewhere else besides the directory specified for storing Imagefield files after adding the patch?
#11
Okay! Now it is working. I deleted all of the images from imagefield_thumbs directory. I think perhaps Imagefield was pulling from these when I was adding the new images, although this doesn't explain why changing the Image Toolkit settings would result in an increased file size.
Now I am seeing the Imageapi debug info. I had cleared the drupal cache several times when testing earlier.
So, it is working but there is a new problem. The file is being resized even though it is not larger than the dimensions specified in Imagefield. I have the dimensions set to 120x60. Imageapi debug reports resizing to 100x59. If it's not one thing, it's another :P
It seems to be resizing any image over 100px in width. I don't have 100px in width set anywhere, why is it deciding to use this value with ImageMagick?
#12
Okay, that seems to be a problem in the configuration as ImageAPI only uses the same height and width as ImageField without the ImageAPI-Support.
#13
Do you think this is a problem in imageapi.module? Also, I recently upgraded to PHP 5.3.1 and applied the recommended patch to Imageapi.
#14
Alright, figured out what is going on. Imageapi is resizing the thumbnail image but not the actual image. The function for resizing the thumbnail is in imagefield_file.inc here (I will probably set this smaller to reduce image size for admin previews since they are pretty much unnecessary in my usage. Might be nice to have this configurable in Imagefield):
function imagefield_create_admin_thumb($source, $destination) {
if (!is_file($source)) {
return FALSE;
}
$info = image_get_info($source);
$size = explode('x', variable_get('imagefield_thumb_size', '100x100'));
// Check if the destination image needs to be regenerated to match a new size.
if (is_file($destination)) {
$thumb_info = image_get_info($destination);
if ($thumb_info['width'] != $size[0] && $thumb_info['height'] != $size[1] && ($info['width'] > $size[0] || $info['height'] > $size[1])) {
unlink($destination);
}
else {
return;
}
}
Case closed :)
#15
Actually no. The case is not closed. It works when I am logged in with my root admin account. However, if I log in with my normal user account, Imagefield is using core Image Toolkit. I tried giving my normal user account node administer imageapi and administer nodes permissions. It still refuses to use Imageapi with anything other than the root admin account.
I give up. I'll just use Gimp to save a local copy of the original and a scaled version for use in the actual post.
#16
@undoIT What are you talking about? This patch only adds ability to use imageapi for admin thumbs so everything other is out of scope! File another issue...
#17
I don't see any mention of admin thumbs only either in the original issue or the post with the patch. I guess I was assuming the patch was to add support for Imageapi, like the title says.
#18
I have last version of "devel module" 6.x-1.x-dev (2010-Feb-14).
Disabling it solves my problem.
#19
Re-title, while this still not commited?
#20
Thanks all. Committed. No hurries in committing things when there aren't any new releases being made.
#21
Automatically closed -- issue fixed for 2 weeks with no activity.