Add width and height attributes to data stored by imagefield for an image to save getimagesize calls.

You could take 5 seconds and look at either theme_imagefield_image or theme_image and discover..
if (!$getsize || (list($width, $height, $type, $image_attributes) = @getimagesize($file['filepath']))) {

now leave people alone and rtfm ;)....

but this is a kind of cool idea.... so I'll re-title it to something that makes sense.

Ok, so far so good. Now if you assume that $node->field_image_foo[0] equals the $file variable that dopry mentioned above - both have a 'filepath' member, at least - then you can still get width, height, and all that stuff, by replacing $file with $node->field_image_foo[0]:

  list($width, $height, $type, $image_attributes) = @getimagesize($node->field_image_foo[0]['filepath']);

And shwoops, you have all attributes you would ever want, ready to be used for whatever purpose.

Hope that helps! Assuming that it does, I'll close this as support request.

Using getimagesize() every time an image field is viewed is not such a great idea. PHP will have to open the image and determine the dimensions of the image each time, which will add up to a significant slow-down in page loading and unnecessary disk-thrashing. A better solution would be to use getimagesize() once, then cache the result for future reference.

I'm kind of surprised (and disappointed) that ImageField doesn't do this already, and would love to hack together a patch to implement it… but it's crunch time, so in the interest of time I'm going to end up implementing something faster/hackier. But please consider this another voice in support for this idea.

Consider this another voice in support of adding width, height (and might I suggest thumbnail path/width/height as well) to the image array.

In my case the images are getting used in Flash with node array data passed using AMF PHP and Services module. Thus the solutions noted above or here aren't of much use unless I somehow knew how to use them to change the output of the field array. Something clearly over my head as proven here.

That said, thank you to those who maintain the module for all their hard work. I'm not unappreciative. Just want to make another case for this change.

I'm going to re-open this issue because I'm running into it again and still think it's a total bummer for PHP to expend cycles and RAM when it has to open an image and read its dimensions every time it's viewed (Imagecache notwithstanding). This is an intensive process which really should be cached, just like many other intensive process in Drupal such as the output of input filters.

I tried to work it out myself, but unfortunately I wasn't smart enough to figure out how CCK works by myself and don't have time at the moment to learn it properly. Someone smarter than me, please consider taking this issue up and working it out. Stressed-out web servers around the world will thank you.

This won't be added to the Drupal 5 version, which is now maintenance only. In Drupal 6, the height/width tags are already stored if the filefield_meta.module is enabled, though it doesn't use this data even though it's available when displaying the image.

here is a small patch which does this.

It'd probably make more sense to check $file['data']['width'] && $file['data']['height'] rather than checking if the module exists. FileField Meta is a "lazy" module which only affects files on upload, so if a file is uploaded before FileField Meta is turned on, width and height will be empty despite the module being available.

thanks for the review! its definitve true, this was not the right way to do it.

here is the new patch for this.

At the same time i realized, that its not possible to set the width/height parameter with $attributes, what about adding the possibilty to be able to set it with the $attributes

You can currently specify a height and width manually as long as you set $get_size = FALSE. How does this patch look for maintaining this ability while adding the check from your patch?

It's kinda funky because Filefield Meta requires Getid3, which feels like a "heavy" requirement when you just want to get dimensions of images and don't care about any other sort of file. But since the results are cached, it (along with this patch) should provide the features I'm looking for and with less stress on the server in the long run, so I'll quit whining and use it and see how it goes.

I think it might make a good amount of sense to have ImageField auto-add height and width properties of it's own to the "data" column, making FileField Meta unnecessary for this feature. FileField Meta is intended to work with audio and video files more than images, populating image data with height and width is just a bonus (it's really intended to get height and width properties of videos).

We can improve the imagefield_file_insert() function (currently it's empty) to add this cached data rather easily, which is the same approach filefield_meta uses.

Well I went ahead and committed #12, we can add the ability to save image height/width on upload in a separate issue.

Thanks guys!

Searched the solution a long time. The #3 working for me, using this to enable/disable jqury zoom on a product page.

Re-opening as I feel that the original feature request 'Add width and height attributes to data stored by imagefield for an image to save getimagesize calls' is not complete.

Unless I'm mistaken the width and height attributes have been added to the rendered field output via the theme_imagefield_image function but I still don't see the width / height in $node->field_image_foo[0].

Like 'volocuga' in the post above, I'm trying to enable/disable a jquery zoom in my template depending on the width of an uploaded image.

but I still don't see the width / height in $node->field_image_foo[0].

I believe these values are only present if you have enabled the filefield_meta module.

That works!

Although it does required the installation of http://drupal.org/project/getid3 and this adds additional overhead and data such as audio_format and duration which is not a requirement.

FileField Meta is necessary to save these values because that module is responsible for implementing all the various hooks when a file is inserted, updated, or deleted. While additional overhead, this is not likely to change because the D7 version of ImageField will also require an add-on module to store this information just like in D6 (since the "data" column is gone entirely in D7).