The image.module doesn't resize the uploaded images.
The attached recommended patch solves this problem:
1) instead of 'image_max_upload_size' the 'upload_max_resolution' variable is used (set by the upload module at /admin/settings/uploads) and uploaded images are automatically resized.
2) older images larger than 'upload_max_resolution' are also resized.
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | image_143828.patch | 36.52 KB | drewish |
| #17 | image_resize_143828_1.patch | 22.26 KB | drewish |
| #16 | image_resize_143828_0.patch | 21.15 KB | drewish |
| #15 | image_resize_143828.patch | 9.67 KB | drewish |
| #14 | image_27.patch | 2.12 KB | he_who_shall_not_be_named |
Comments
Comment #1
drewish commentedwe don't depend on upload.module so we won't use their variables. feel free to copy those settings in to make them image.module specific.
Comment #2
he_who_shall_not_be_named commentedOf course:) It was a suggestion (or example) only. I have installed this patch on one of my sites and hope that you'll make something similar to help users by resizing their images instead of displaying an error message.
Comment #3
deciphered commentedI second the request for such a feature.
I'm working on a gallery site for a photographer and the image files he will be uploading will be high resolution images. As I don't want people to have access to the high resolution images it would be perfect if the high res images that where uploaded where automatically resized to set dimensions.
Comment #4
he_who_shall_not_be_named commentedIf you wish I'll add a variable 'image_image_max_upload_size' variable to the image module's settings page and modify the patch.
Comment #5
he_who_shall_not_be_named commentedSorry, ''image_upload_max_resolution''
Comment #6
he_who_shall_not_be_named commentedComment #7
Vallenwood commentedThis is a fantastic idea and I'm glad I'm not the only one who thunk of it. I'm hoping I can point you to a Feature Request issue I just opened which I believe is a more full-featured implementation of this idea, which allows you to specify the two things (filesize and resolution) independently of one another, and has other cool features besides. Please check out my "Configurable Resize Original patch plus other enhancements" posting at http://drupal.org/node/149093. I didn't know vrencianz was working on this when I started working on my own solution; I hope mine is a good successor to it. If you agree, you may want to close this issue and use mine instead.
Comment #8
he_who_shall_not_be_named commentedWill be implemented by http://drupal.org/user/43278. See http://drupal.org/node/149093
Comment #9
he_who_shall_not_be_named commentedI decided to reopen this issue and redirect to the recent release.
The attached patch adds an 'image_max_resolution' setting (like the upload module) and uses it.
The feature is tested on the 5.x-1.2 version.
Comment #10
drewish commentedi think this is an excellent feature but i think a better way to implement the settings would be to add an "Original" image row to the "Image Sizes" table and put separate fields for hight and width there.
Also after resizing the image you probably should call clearstatcache() to clear out the cached file info so that filesize() will return the new file size.
Comment #11
he_who_shall_not_be_named commentedYou have right. The clearstatcache is needed.
Thanks.
Comment #12
he_who_shall_not_be_named commentedAdding a new required size 'original' to the _image_required_sizes() conflicts with the IMAGE_ORIGINAL and its access rights (even if the 'view original images' isn't set user will see required size).
What is enervating is that the image has no such a feature. It is a must because of the users (see the next paragraph), saved space on the server and, of course, reduced load time for the browser.
1) Users uploads a big image and after they waits 30 secs (for a 3mb image downloaded from his camera, for example) to see an error message. They must reedit locally the related files to make sure that it has the required size in KB (resizing locally a an image to a required resolution (widthxheight) is much more easy than resizing it to a required size in KB).
2) Every time I update the Image module I must apply a patch like this one.
This is the only one image module which has galleries for Drupal (except the great third party Gallery, of course) so I have no choice.
Could you please, image module developers, implement this feature. It is normal and isn't for me only. You know better than me this module and, of course, you know better how to add features to it.
PLEASE!
:)
Comment #13
drewish commentedvrencianz, you make it sound like i've marked this patch as "won't fix", i understand the benefits of this patch and i want to get it committed, but i want to see it done right, not half way. i appreciate that you split up your big patch into smaller bits. i've been reviewing your patches, i posted two comments yesterday and though you'd post an updated patch but haven't seen anything.
it sounds like you didn't understand what i meant by putting the max sizes into the image sizes table. i didn't want you to add a new upload item to that, rather put in a hard coded 'original' row. i'll try to roll a patch to show you what i mean.
Comment #14
he_who_shall_not_be_named commentedNo, no. Sorry for misunderstandings. Probably it is because of my English.
I understood what you told me about the 'original' and started to work on it but realized that 'original' conflicts with the '_original' (see the define('IMAGE_ORIGINAL', '_original') and the access rights) and give up.
There is only one patch. This one. Sorry for the other posts.
The attached patch is the one I applied on my site (contains the clearstatcache() fix, thanks).
Comment #15
drewish commentedi used your patch as a starting place and fixed some other things with the size settings that have been bothering me for a while. it changes the way that the settings are stored and will allow the size labels to be translated. it needs an update function to migrate the variables but i don't have time to do that right now. i did a little testing on this (after re-setting the image settings form to default) and it seemed to work pretty well.
Comment #16
drewish commentedokay well this has an update in the .install file. it's turned into a kind of massive patch but i'm pretty pleased with the way it cleans up all the special cases. i've gone through cleaning up a bunch of stuff and added thumbnail and preview constants.
Comment #17
drewish commentedgetting close here... i'm going to be offline for next week so i probalby won't be able to do much with this.
Comment #18
skizzo commentedHaving the same requirement, I applied the simple workaround suggested by vhmauery in http://drupal.org/node/152021 . This solves my max_resolution problem, while leaving
me with a min_resolution issue (I am using Acidfree and Image core).
Comment #19
drewish commentedthis updates image_galler and image_attach to use the new settings. since there wasn't any feed back i'm probably just going to commit this and then start looking at what code from vrencianz's other issue still needs to be applied.
Comment #20
drewish commentedokay i applied this to both HEAD and DRUPAL-5
Comment #21
he_who_shall_not_be_named commentedI was afraid that the 'Original' will conflict with the '_original'.
1) Well, after the 5.x-1.3 is installed, because of rebuilds, some previews/thumbnails/originals dissapeared.
2) After saving again the settings no images (thumbnails and/or previews and/or originals are showed).
3) I have a lot of previews (downloaded the entirely 'image' directory and closed the site for the same image (example: 1.preview_0.jpg, ...., 1.preview_10.jpg)
I see that posting this issue wasn't a good idea. Sorry for that.
Comment #22
drewish commentedit shouldn't. after the update 'Original' will be 'original' which should be different than _original. since i had a hard time getting people to test patches there are several bugs in 1.3. please see the other issues and see if the patches help.