Full sized (not thumbnail) image is displayed when using image filter

I just set up a new drupal site (www.joepilot.net) and wanted to use the image_filter module, so I hacked it for the CVS version.

BTW, that was me who just posted the fix, I had forgotten to log in. Also, be sure to rename to image_filter.module, instead of image_filter0.module or whatever.

Even if your patch does work if you just want thumbnails, it removes the possibility to choose the resolution of the image you want to incorporate into the story. In fact it reverts to the old behavior of the image filter.

While I agree the current solution does impact the server load, it provides more flexibility. Note that if there is no image for the resolution choosen, the corresponding image is generated on the fly only once. If the choosen resolution is not in the default list, the image of the next resolution available is used and the browser does the resizing.

I have updated image filter for 4.5.0 release and fixed this problem.

How about having it send the standard thumbnail if the resolution is not specified but sending the resized image if one is specified? That would allow one to resize the image and also keep the low overhead of a simple replacement string.

While I agree the current solution does impact the server load, it provides more flexibility. Note that if there is no image for the resolution choosen, the corresponding image is generated on the fly only once. If the choosen resolution is not in the default list, the image of the next resolution available is used and the browser does the resizing.

If I understand you correctly, this means that if, for example, the smallest resolution in the default list is "640x480" and I specifiy 120x90, the user will be downloading a 640x480 image (which is then resized to 120x90 in the browser). This is not only load on the server, but a big pain (and somewhat defeating the point of thumbnails) for the user to download.

While I appreciate the flexibility, I think it might be better to retain the old behaviour (of inlining the thumbnail) unless a different resolution is specified.

Ok, attached is a patch that incorporates joemc91's patch (to use $img->thumb_path) iff the width and height are not specified. If they are specified, the filter will use Bruno's new functionality.

An excerpt:

<img src="' . ($img->width || $img->height 
                         ? url("image/view/$img->nid", 'res=' . $img->width . "x$img->height") 
                         : url("$base_url/$img->thumb_path"))) . '" ...

Best of both worlds?

If there are no complaints, I'll commit this in a few days. I'd like to commit it to the 4.5 branch, since right now sites upgraded from a working 4.4 installation will be broken. (There are currently no differences between 4.5 and HEAD for this module).

I mean that #12 is bug, it generates "?q=/images/thumbs/flags/flag-mn_th.gif" thumb image src. Correct one is:

<img src="' . ($img->width || $img->height
                         ? url("image/view/$img->nid", 'res=' . $img->width . "x$img->height")
                         : "$base_url/$img->thumb_path")) . '" ...

Tomas

Aha. Good catch. I didn't see this, since I have clean urls turned on for all my sites, and it only affects the output if clean urls are off.

Patch attached, and I'll commit it to DRUPAL-4-5 and HEAD.

Thanks.

Is the new CVS version of the module backward compatible with 4.5?

Also, I am getting errors when I try to use different sizes. Not sure the problem is with image.filter...

Can someone tell me, do the sizes I specify in the tags have to be:

a) specified as options in the image module config
b) specified as options in the image module config and highlighted as automatically generated when the image is edited
c) no need to be specified as options in the image module

fyi, the html tag this is generating uses the following as the Image URL:
http://organizersdb.org/image/view/80?res=240x180

thanks,
-rich

Is the new CVS version of the module backward compatible with 4.5?

It should, but this fix has been applied to the 4.5 branch also.

Can someone tell me, do the sizes I specify in the tags have to be:

a) specified as options in the image module config
b) specified as options in the image module config and highlighted as automatically generated when the image is edited
c) no need to be specified as options in the image module

I believe (c) is the correct answer.

I'm sorry if I got this wrong, but it would appear that this has been only partially fixed. Now, no parameters will show the thumbnail... that's great, but if I supply 'width' and 'height' parameters, it still downloads the full sized image and uses 'img' tag width and height properties to scale it down within the browser. Not only is this bandwidth intensive, but it also gives a degraded image quality.

Please correct me if I'm wrong... but my comparisons of [image:node-id width=x height=y] results with the actual image node results shows a marked difference, especially if the original image uploaded is 3+ megapixel - the [image]-tagged one is jagged and pixelated.

If you right-click and 'view' the image ([image]-tagged), it will display the orginal full sized image, which is incorrect, in my opinion. Let me know if I can provide any more information.

James Addison
http://www.pjsoft.ca

Just to provide some examples on my website...

[image:node-id ...] syntax (not so nice)
normal image node (nice)

I'm somewhat at a loss on how to get this filter to behave itself.

I upload an image with a resolution of say 240x120 .. OK; I use it with the [image]-tag inside a story, I get the thumbnail displayed. Fine.

If I click on the thumbnail, I get the uploaded picture displayed at the resolution I've set uploaded images to first be displayed at.. ?!?! But why oh why isn't it defaulting to the image's ACTUAL size? I don't understand this.. why on earth would I want to INCREASE the size of the image.. ?

This is 4.5.2 btw.

Another (off-topic) question is: Is there a good reference of all "tags" and what not that can be used while editing entries?

-joho

joho (comment #23): Your issue is actually with the image module, not image_filter. I think that the behavior is what you want in 4.6.0; I no longer have a 4.5.2 installation to see if it's different.

The documentation for the tags is included in the module. For the latest CVS version, it's:

[image:node_id (left|right|top|middle|bottom|absmiddle|texttop|baseline) hspace=n vspace=n border=n width=n height=n class=x]

With any luck this is self-explanatory.

Except that the current image_filter module won't work with the 4.6 image module.

Attached is a patch that might (or might not) make it work. It is almost competely untested. It may well cause your cat to explode. But do let me know how it goes (the patch that is, not your cat).

Yes. I've modified image_filter.module to be compatible with 4.6.0 as well.

The image module no longer supports specifying the image resolution any more (that is, "image/view/nid?res=widthxheight"), so my patch moves the equivalent functionality into image_filter. I'd like to contribute a patch after I've had a chance to clean it up a little more.

I'm curious, what does the db_rewrite_sql do? I looked at the code in database.inc, but the documentation there doesn't explain what the purpose is.

To follow up to my previous message, I submitted my image_filter patch for 4.6.0 compatibility at http://drupal.org/node/22104.

The version of image_filter that I've just committed to CVS now determines which of the various resolutions of the image are available to refer to in the img tag. The 4.5 version of image used to take a trailing "res=WxH" on the URL to generate an image at the specified resolution, but that functionality was removed in version 4.6. image_filter now creates an img tag that links to (via href) the next larger available image than the user specified.

Feedback on my code is welcome.

I'm curious, what does the db_rewrite_sql do?

http://drupaldocs.org/api/4.6/function/db_rewrite_sql

Basically, it allows database drivers (e.g. for postgresql) to rewrite the query to follow any non-mysql syntax or conventions.

To follow up to my previous message, I submitted my image_filter patch for 4.6.0 compatibility

Thanks for that, I dropped the ball a bit. But your patch is much more comprehensive than mine anyway.