Right now with the scaling addition all images require scaling. However there's no way currently to have the old functionality of just having dimensions and byte size of the image determine if its good or not. So images now always get scaled to have a viewable version (default is 640x480 in the module). This is just overkill. There needs to be a way to just have images left alone.

CommentFileSizeAuthor
#11 image-original-size.patch4.46 KBAnonymous (not verified)
#3 image_1.module68.45 KBixis.dylan

Comments

circeus’s picture

circeus commented

Okay so I grabbed the CVS version and the option isn't there. Care to explain what the fix was, or was I not clear on what I'm asking for?

Simply put the old image.module for 4.4 showed the image at original size. It didn't try to scale it unless the user tried to do it when added or it was greater than the maximum size.

Now since it always forces a resize on enter OR for images that were already in the gallery that did not have a view size of itself it will try to resize on the next view.

There is as far as I can see no option to NOT have this resizing done.

I tried clearing the "List of valid resolutions" but this only removes the selections. This will remove choices for "Default image display resolution" and "Specify resolutions that will be generated at time of editing" however there is still a call made somewhere to the gd2 library to resize the image even though I have no resizing set.

Really this resizing needs to be removed.

How do I know? Well my virtual host limits my maximum process size -- hence since image manipulation is generally a resource hog, I want to basically use the gallery without the resizing option. Well since I'm limited I get a memory error at line 519 in image.inc.

Line 519 happens to be a call inside the function _image_open_gd2() which if I'm not resizing should not be called (note I checked this is not an issue with thumbnails which are getting generated properly).

In effect I want an option that after an image has been added and its thumbnail created, that I just don't want any more image manipulation done or made available to be done. This way we can in effect have the old image.module functionality where it behaved in this manner.

So I am reopening this.

circeus’s picture

circeus commented

I just wanted to add as a followup to the above that basically in effect I want an option whereby I never see any _640x480 or _800x600, etc. images in my /images directory. But even when I clear the options I mention I still see these getting created.

That needs to not happen if the options are not set.

ixis.dylan’s picture

ixis.dylan commented
StatusFileSize
new image_1.module68.45 KB

Attached is a copy of my edited image.module file. Replace your version with this, then leave the "List of valid resolutions" section of the config page blank. It's an ugly hack and unsuitable for a patch, but it works for me for now.

circeus’s picture

circeus commented

Yes, works for me too. Though if you have debugging messages in setup it does generate the following:

warning: imagecreatetruecolor(): Invalid image dimensions in /home2/netmarks/net-marks-www/avatarsofjustice/modules/image/image.inc on line 547.
warning: imagecopyresampled(): supplied argument is not a valid Image resource in /home2/netmarks/net-marks-www/avatarsofjustice/modules/image/image.inc on line 548.
warning: imagejpeg(): supplied argument is not a valid Image resource in /home2/netmarks/net-marks-www/avatarsofjustice/modules/image/image.inc on line 532.
warning: imagedestroy(): supplied argument is not a valid Image resource in /home2/netmarks/net-marks-www/avatarsofjustice/modules/image/image.inc on line 533.

And for larger images I still get memory errors due to hosting limitations:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 3840 bytes) in /home2/netmarks/net-marks-www/avatarsofjustice/modules/image/image.inc on line 519

I mean the memory exhaustion is not a bug with the module, but the module should handle it more gracefully. It also shows that some kind of image manipulation is still occuring even though you've done your hack.

David Hull’s picture

David Hull commented

I believe that the patch that I gave here:

http://drupal.org/node/10461

fixes this problem.

Anonymous’s picture

(not verified) commented

Not in this case. Comparing the hacked image.module provided above to the CVS one image_display() is one of the hacked functions.

David Hull’s picture

David Hull commented

To #6 by Anonymous: You're right; I didn't read the original bug report carefully enough.

bitman’s picture

bitman commented

Okay, this patch should fix this problem. It adds an "original image" choice to the "Default image display resolution" option. This choice will cause the original image to be displayed by default, rather than trying to scale the image, which should prevent other sizes from being generated.

Additionally, if you clear the "List of valid resolutions" then it will not display the links to other image sizes at the bottom of the image, again preventing other image sizes from being generated.

Finally, the "Specify resolutions that will be generated at time of editing" option gets a "" choice, which makes it possible to generate no image sizes when uploading the image. If you simply deselect all choices, or if no choices are given, then this value is not changed. So a "" choice is the only way to clear this list. If "" is selected in combination with other choices, it is simply ignored when generating images.

This patch fixes these issues without removing any functionality from the image module. Patch against image.module 1.134 or higher if you know what's good for you. Avoid 1.132 (which is the current release version), because permissions are broken.

bitman’s picture

bitman commented

Er, all those "" choices above should be "<none>" choices. Sorry.

bitman’s picture

bitman commented

Er, all those "" choices above should be "<none>" choices. Sorry.

Anonymous’s picture

(not verified) commented
StatusFileSize
new image-original-size.patch4.46 KB

And to top it off, the patch didn't get uploaded. Trying again...

intel352’s picture

intel352 commented

I've modified the resize function to only resize when the requested dimensions are larger than the original image dimensions.
this is modified from the CVS files (as of Dec 26,2004)

the code follows:

/**
 * Resize (resample) an image file.
 */
function image_scale(&$image, $width = '', $height = '') {
	$imagelib = variable_get('image_lib', 'imagemagick');
	$function = '_image_scale_' . $imagelib;

	if (function_exists($function)) {
		$details = image_get_info($image->filename);
		if((($width && $height) && ($details[0]>$width) && ($details[1]>$height)) || (($width) && ($details[0]>$width)) || (($height) && ($details[1]>$height))){
			return $function($image, $width, $height);
		}else{
			return $image;
		}
	} else {
		return false;
	}
}

This method works fine for me, and doesn't touch an image that does not need resizing.

magico’s picture

magico commented
Component: Code » image.module

What is the status of this in the image module?
There is really a need to only scale the images when inserting or updating data in the database. It's not logical to change images when viewing them

magico’s picture

magico commented

_image_build_derivatives should not be updating the images when "$temp" is false. What is the reason to force this update?

walkah’s picture

walkah commented
Status: Needs review » Closed (works as designed)

image module only resizes images on view after the derivatives have been updated - and only does so once... under normal circumstances, yes new derivatives will only be generated on insert/update... however, if you change the preview size (say from 600x600 to 400x300) - then the derivatives will be regenerated on next image view - otherwise you'd have to "edit" every image.

i believe the rest of the issues are prior to 4.6 ... i'm marking this by design for now.