Textpattern Support Forum

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:

1. I created two profiles: medium (540px) and xlarge (900px), as stated above.
2. Then, I uploaded the original/main images (720px).
3. 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”

1. I went to “Images” tab
2. Clicked on an image to edit it
3. Under “Thumbnail”, I chose the xlarge (900px) profile on the dropdown menu
4. And then clicked on “Create” button and….
5. 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).
6. 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)

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:

1. 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.
2. 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).

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,

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}.

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

To create thumbnails for just uploaded images only ?