smd_thumbnail: manage multiple thumbnails of your images

maniqui · 2010-11-17 00:06:00

OK.
But this is what happened, after enabling smd_thumbnail, the one thumbnail I already had, wasn’t displayed in the “Images” tab nor in the editing screen for the correspondent image.

Bloke · 2010-11-17 00:34:48

maniqui wrote:

after enabling smd_thumbnail, the one thumbnail I already had, wasn’t displayed in the “Images” tab nor in the editing screen for the correspondent image.

That’s correct behaviour: it completely sidelines your existing thumbnails and just leaves them exactly as they were. The plugin uses the new callbacks on the panel and puts its content in place of TXP’s thumbs but they’re still in the database and in the /images directory. So when you disable or uninstall, everything magically pops back as if the plugin had never been installed.

All the while it’s enabled, smd_thumbnail takes control of your images and uses its own table and its own directory structure to maintain the images you see in the Images panel. Only if you choose to sync the default profile with TXP’s thumbs will anything happen to the thumbnail info in the txp_image table and the ‘t’ files in /images. Does that explain it a bit better?

Last edited by Bloke (2010-11-17 00:36:44)

maniqui · 2010-11-17 04:27:20

Yes, Stef, that explains it well.
And now that I look deeper into the documentation, I see that you have explained it there too. So, sorry for the above have-not-RTFM questions.

maniqui · 2010-11-18 05:13:01

Hi Stef,

I’m a bit confused. Let me try to explain.
Plugin help says, under the Custom thumbnails section:

thumbs cannot have dimensions greater than the original image or the upload will be ignored

If by original image you meant the main one, that is, the full built-in managed-by-txp image, then, the above statement is wrong.
My main/original image is 720px (width), and I can upload a 900px (width) image for my “xlarge” smd_thumbnail profile (my “xlarge” profile has been defined to be 900px width)
In other words, the upload hasn’t been ignored.

And I’m pretty happy with that!
I mean, not sure if it was unintended/unplanned/not-in-the-scope-of-a-thumbnail-plugin, but I like/wish/expect that smd_thumbnail can handle/manage/create/allow the “thumbnails” to be larger than the original image.
Let me try to explain:
I’ve created two smd_thumbnail profiles: “medium” (540px width) and “xlarge” (900px width). I expect/planned those two profiles to be the “thumbnails” for a size that is in the midst (720px width).
In other words, the built-in/txp-managed/standard image would be a 720px.
Evidently, 900px > 720px, but I still expect that smd_thumbnail empowers me to have that.

So far, I’m currently happy with the odd (unexpected?) behavior of smd_thumbnail letting me upload larger-than-original-image custom thumbnails, against to what plugin help states.
Certainly, I would also logically expect that smd_thumbnail wouldn’t let me create a larger-than-the-original-image thumbnail, as this would imply some quality loss or distortion (an enlarged-by-software image won’t regain the already loss quality). But, to be fair, even in this case, I would still prefer that smd_thumbnail let me create larger thumbnails of my original images, even if that implies some distortion or quality loss.

I hope you still follow me, because there is something else I’d like to report, and it’s directly related to the last paragraph.
On my short experience with smd_thumbnail during the last day, this was my workflow:

I created two profiles: medium (540px) and xlarge (900px), as stated above.
Then, I uploaded the original/main images (720px).
Then, I manually uploaded the medium and xlarge thumbnails. In other words, I didn’t use the smd_thumbnail creation powers.

So far, so good.
But then, the unexpected, dissonant thing happened:
I said, “Let’s try the powers of smd_thumbnail to create a 900px image”

I went to “Images” tab
Clicked on an image to edit it
Under “Thumbnail”, I chose the xlarge (900px) profile on the dropdown menu
And then clicked on “Create” button and….
an image was created, but it was just 720px, not 900px as the profile dictates (and as end-user may expect, being that the process worked and smd_thumbnail didn’t complain at all).
And also, to add to the confusion: the created image was effectively 720px width, but on the editing page, it was being stretched (by width="" attribute) to 900px. I see this as something really confusing, particularly for end-users, that won’t understand why they image seems to be 900px, but then, it’s just 720px.

So, Bloke, thanks for reading till here. Now, the quick summary of the issues and my personal wishes/thoughts:

issue 1: smd_thumbnail allows you to upload thumbnails larger than the main image, although plugin help says the contrary. My opinion/wish: keep this behavior. I like the idea of having thumbnail profiles for larger versions of an image, and to be able to upload them manually.
issue 2: when creating a thumbnail (ie. hitting the “Create” button on edit image screen) for a profile that has a larger size than the original/main image, smd_thumbnails “fails” silently: it creates a thumbnail as large as the original/main image (fail 1) and it wrongly displays it as the size specified in the profile. My opinion/wish: smd_thumbnail should do any of this:
- option 1: just create the larger image (expected behavior, even if this logically results in no-gain of image quality at all), as there is a profile for it. Yeah!
- option 2: it should complain: “Hey, you, end-user: you can’t create a thumbnail larger than the original image. It may look bad, low-fi, distorted, pixelated. But there is hope for you: you can upload a nice thumbnail, larger than the original image, and I promise I won’t complain.” (see issue 1)

Bloke · 2010-11-18 14:08:10

maniqui

Thanks for the detailed report. Short answer was going to be: not a lot I can do about it because it’s a core feature of the wet_thumb class. At least I didn’t think there was. I knew about the fact you could upload bigger images; the documentation just sucks here so I’ll fix that.

However, now I have my glasses on I can see that it’s possible to override this feature with a simple setting so you might be able to trick it by adding one line to the plugin, around line 261 just before this:

$t->crop = ($crop == '1');

Add:

$t->extrapolate = true;

Then see if that allows you to create images beyond the dimensions of your original. If it works I’ll set it like that by default so you can create images of any size all the time.

maniqui · 2010-11-19 13:55:56

Hi Bloke,
thanks for the reply. Haven’t tested yet the suggested change.

I’ve an idea that may have its merits, if you can code it ;)
What if you plug your plugin to another plugin? Plugtastic! (no, I’m not good at copying your writing style… yet…)

Probably someone already requested it, or even it crossed your mind.
There is the ebl_image_edit plugin that lets you edit (resize, crop, rotate, etc) your TXP images using some cool jQuery/jCrop/Ajax/GD.

Of course, you (or others) may have had this idea and say: “too complicated, it may imply hacking/forking ebl_image_edit, or asking grumpy TheEric…” (note: TheEric, if you are reading this, it’s just a joke!).

But I think there is a workflow to make this two plugins work together like Wonder Twins, without hacking ebl_image_edit.

The workflow:

user creates a thumbnail (resizing or cropping the original image) using ebl_image_edit. This thumbnail will be saved by ebl_image_edit using the built-in TXP thumbnail.
this new created thumbnail will be used then to create a new (smd) thumbnail for an existing profile. There would be a button in the “Images -> Edit” screen that would read something like:
- “Create a thumbnail for [dropdown with profile names] profile from the existing TXP thumbnail.” (this would need some rewording).

The idea has some drawbacks:

it may not play nice with the current Sync abilities of smd_thumbnail, because now, the original TXP thumbnail is being used as an “temporary stepping stone” to create new thumbnails.
it may need that smd_thumbnail displays again the built-in TXP thumbnail in the editing screen (only if ebl_image_edit is installed), so the user has a better idea of what the built-in TXP thumbnail currently looks like, so to be able to correctly choose which profile should that thumbnail be copied to.

I’ll stop by now, and only continue if you think this idea may have any merit and may be feasible (and interesting for you to code it).

Bloke · 2010-11-21 17:02:59

Eeek, I just spotted something. When wet changed the image callbacks after RC1 the callbacks are defined ‘backwards’ compared to how they are usually done: they are defined step first, then event so my plugin’s not calling them any more (I assumed event/step like normal).

I’ll issue a fix asap. If your thumbs aren’t being automatically created or deleted when you interact with the plugin that’ll be why, oops, sorry.

maniqui

I’m not sure if I can get the two plugins to co-exist happily but I can certainly add a callback or two to my plugin if others want to be notified of when each thumb is created and do something with them. Likewise, if TheEric or somebody were to add a callback to their plugins I could hoopk into them and create multiple thumbs from each uploaded / cropped image. Maybe. Would need some thought.

Last edited by Bloke (2010-11-21 17:03:35)

Bloke · 2010-11-21 17:28:23

And here’s the fix. In this version:

Thumbnails can now be larger than the original images (thanks maniqui), though they will still be stretched/squashed to fit the profile they have been assigned. Thus if you upload an 800 × 600px image into a profile with dimensions 200 × 200 (the original image size now doesn’t matter) the browser will scale the image to the profile size, wasting your bandwidth
Fixed the image callbacks: now your thumbs will be automatically ccreated and deleted as you interact with the Images tab, as described in the docs

wornout · 2010-11-22 16:25:04

What about some integration with smd_gallery?

maniqui · 2010-11-23 23:54:02

@wornout,

not sure what kind of integration with smd_gallery are you looking for, but you can do some basic mashup doing this:

<txp:smd_gallery>
<txp:smd_thumbnail id="{id}" />
</txp:smd_gallery>

One disadvantage of this method is that you can’t fine-control the markup of the <img /> tag, as it’s generated by smd_thumbnail.
Thankfully, regarding that, at least, smd_thumbnail is compatible with the new ihu variable, so the images will be served from the correct location.

One advantage of this method is that you have access to the force_size attribute (hey, Bloke, how does that work? Does it query the file in the filesystem to pick up the “missing” (set to 0) size?), so you can improve the rendering when using this “non-txp-standard” thumbnails.

Then, there is this other method: you could do it even more manually, which adds some flexibility to your markup:

<txp:smd_gallery>
    <img src="/images/[SOME_SMD_PROFILE_NAME/{id}{ext}" />
</txp:smd_gallery>

Here, the advantage is having better fine-control over the markup of the <img /> tag.
For example: you could also do <img src="<txp:variable name="static_media_url />/images/[SOME_SMD_PROFILE_NAME/{id}{ext}" /> to fine-control the image URL (static_media_url is just a variable I’ve created, for exactly the same purpose of the new ihu variable).

The disadvantage of this second method is that you can’t access (afaik) to the real dimensions of the thumbnail file, nor even to those defined in the corresponding smd_thumbnail profile, so you can’t replicate the force_size feature of smd_thumbnail.

If some kind of integration could be done between smd_gallery and smd_thumbnail, I think it would be that one: if possible, to let smd_gallery “know” the real size of thumbnail, and create the corresponding {replacement_variables}.

Bloke · 2010-11-24 10:10:30

maniqui

All good stuff, thanks for fielding this one.

One advantage of this method is that you have access to the force_size attribute …how does that work?

You are right, it queries the file system using getimagesize().

you can’t access (afaik) to the real dimensions of the thumbnail file

Correct. I guess I could (should?) offer either usual {replacement} vars or a <txp:smd_thumb_info /> tag so you can use smd_thumbnail as a container if you wish and build your own thumbnails. Will look into that at some point, thanks for the idea both of you.

jpdupont · 2010-12-02 13:12:34

Stef, is it possible to allow “create all” for checked images only ?

To create thumbnails for just uploaded images only ?

Textpattern CMS

Textpattern CMS support forum

#49 2010-11-17 00:06:00

Re: smd_thumbnail: manage multiple thumbnails of your images

#50 2010-11-17 00:34:48

Re: smd_thumbnail: manage multiple thumbnails of your images

#51 2010-11-17 04:27:20

Re: smd_thumbnail: manage multiple thumbnails of your images

#52 2010-11-18 05:13:01

Re: smd_thumbnail: manage multiple thumbnails of your images

#53 2010-11-18 14:08:10

Re: smd_thumbnail: manage multiple thumbnails of your images

#54 2010-11-19 13:55:56

Re: smd_thumbnail: manage multiple thumbnails of your images

#55 2010-11-21 17:02:59

Re: smd_thumbnail: manage multiple thumbnails of your images

#56 2010-11-21 17:28:23

Re: smd_thumbnail: manage multiple thumbnails of your images

#57 2010-11-22 16:25:04

Re: smd_thumbnail: manage multiple thumbnails of your images

#58 2010-11-23 23:54:02

Re: smd_thumbnail: manage multiple thumbnails of your images

#59 2010-11-24 10:10:30

Re: smd_thumbnail: manage multiple thumbnails of your images

#60 2010-12-02 13:12:34

Re: smd_thumbnail: manage multiple thumbnails of your images

Board footer