smd_thumbnail: manage multiple thumbnails of your images

Bloke · 2011-06-23 22:03:21

maniqui

I’d forgotten about your post, thanks for the reminder.

The “pure” smd_thumbnail approach would work by “fetching” the latest txp_thumb

In theory yes. But two things leap out at me:

how do I know which thumb it is? Do I list images in the /images folder sorted by reverse date and take the first one? (hoping two people aren’t editing different images at the same time or I might miss one)
(more fundamental) how do I know when to do step (1)?

With a callback from ebl_image_edit I have a trigger to know that a crop action has taken place and, if the image ID of the recently cropped image is passed in, smd_thumbnail knows which one to work on and never misses a thumbnail.

The “pure” ebl-image-edit hack/mod approach would work by hacking that plugin to present the user with a dropdown select

That would work.

Although it does not rely on the existence of smd_thumbnail per se, the fact that the subfolders are beeing looked at by ebl_image_edit implies some link to my plugin. If another thumbnail plugin came along and did things differently by using a different folder structure or naming convention, TheEric may well be asked to support that. Similarly, if I discovered a bug and had to change the way smd_thumbnail stored its images, it impacts Eric’s code.

So while such a mod would work, I can understand Eric’s reservations for making such changes himself. What I don’t understand is his reluctance to raise a callback with the ID of the recently edited image each time a thumb is written to the filesystem. For example:

callback_event('ebl_image_edit', '', 0, $id);

That leaves it up to other plugins to hook into the ebl_image_edit workflow and leaves implementation details up to third parties in the same way I can hook any plugin into mem_form to validate form fields when someone clicks Submit. There may of course be some valid reason for Eric not wishing to do this; I’m only going on my own blinkered understanding of TXP’s callback mechanism.

maniqui · 2011-06-23 22:34:27

Bloke wrote:

how do I know which thumb it is? Do I list images in the /images folder sorted by reverse date and take the first one? (hoping two people aren’t editing different images at the same time or I might miss one)

Not sure if I follow you here. This is what I’ve in mind:

user uploads image (it gets some id, like 123)
user goes to the “Edit image” on TXP admin
user creates a regular txp thumbnail using ebl-image-edit crop/resize powers
thumbnail is saved at /images/123t.ext
now, user says: “hey, smd_thumbnail, go and get the regular thumbnail for this image, and make it the thumbnail for the ‘square’ smd_thumbnail profile”. UI: “Create [dropdown:list_of_smd_thumbnail_profiles] thumb from regular TXP thumb”.
smd_thumbnail goes, picks the /images/123t.ext file and copies it to /images/square/123.ext.

Time passes… now user needs to create another thumbnail for image 123, this time the thumbnail for the “rectangular” smd_thumbnail profile.

user goes to “Edit image” for image 123.
user creates a regular txp thumbnail using ebl-image-edit crop/resize powers
thumbnail is saved at /images/123t.ext (it will probably overwrite the previously created regular txp thumbnail, see list of steps above)
now, user says: “hey, smd_thumbnail, go and get the regular thumbnail for this image, and make it the thumbnail for the ‘rectangular’ smd_thumbnail profile”.
smd_thumbnail goes, picks the /images/123t.ext file and copies it to /images/rectangular/123.ext.

Of course, it’s up to the user to create/crop/resize thumbnails with the appropriate dimensions that would match/fit the purposes of each smd_thumbnail profile.

Although it does not rely on the existence of smd_thumbnail per se, the fact that the subfolders are beeing looked at by ebl_image_edit implies some link to my plugin.

This is the interesting part: if ebl-image-edit could be hacked to let the user store thumbnails on some selected folder… who would need smd_thumbnail at all? ;)
I mean, as long as the user knows how to create a folder via FTP, that would be enough to create the equivalent of a smd_thumbnail profile.
Of course, I know your plugin does more than creating folders and storing images there.

In any case, I also know you know better about all this stuff, and my hack-ish suggestions are probably ugly from a plugin developer POV. :)

Bloke · 2011-06-23 22:49:04

maniqui wrote:

Not sure if I follow you here [snip]

Sure, that’ll work. It requires one change to my plugin to allow you to choose whether to create thumbs from the full size image or from the TXP thumbnail (in theory: untested).

But that burdens the user with going to the smd_thumbnail’s Tools area after they’ve edited thumbnails and then highlighting the ones they want to create (e.g. selecting them one by one, or choosing ‘by category/ author / all’) and then hitting the Go button. I thought what Gil was after was a way that the thumbnails could be automatically updated from the cropped/rotated/edited thumbnail as soon as it is altered.

Maybe I misunderstood the request? I can (and will) look into adding the ability to choose an image source for thumbnail creation.

Last edited by Bloke (2011-06-23 22:52:00)

maniqui · 2011-06-23 23:08:27

Bloke wrote:

to create thumbs from the full size image or from the TXP thumbnail (in theory: untested).

I think I didn’t explain clearly myself yet.
I’m not suggesting that smd_thumbnail should create a thumb from the TXP thumbnail, but rather, to pick/fetch/suck the already-created-by-ebl-image-edit TXP regular thumbnail and assign/attach it to a smd_thumbnail profile (selected by the user).
No created-by-smd_thumbnail process involved. No thumbnails were harmed during this process.

Must admit that I’ve yet to re-read Gil’s request.

Bloke · 2011-06-23 23:36:58

maniqui wrote:

I’m not suggesting that smd_thumbnail should create a thumb from the TXP thumbnail, but rather, to pick/fetch/suck the already-created-by-ebl-image-edit TXP regular thumbnail and assign/attach it to a smd_thumbnail profile (selected by the user).

Hmmmm, still confused, sorry. Perhaps I’m being dim since you’re at least 5 hours fresher than I am.

Going back to basics for a moment to think this through: in order to have a thumbnail in the relevant profile size(s), smd_thumbnail requires a physical file inside the relevant profile’s subdir with the same ID.ext as the original.

If someone has edited the original (and by original here, I mean either the full size image or the TXP thumbnail) then smd_thumbnail must physically create (or overwrite) one file per active profile to keep things in sync, i.e. store one physical file with the ‘current’ ID.ext in each image subfolder.

Now, whether it does this by creating a fresh image based on the original (real or thumb) or whether it copies the TXP thumbnail file to the subfolder is kind of immaterial: a file still must exist in that subfolder so that the smd_thumbnail tag can use it.

Where the mechanism of storing those files becomes important is with multiple profiles. Imagine if you had 3 profiles set up called Large, Medium and Small, thus having 3 subfolders of the same names beneath /images. After upload, the thumbs in these folders are all based off the original full-size image.

You then crop the original thumbnail (say it’s portrait) to only show the top half. Once cropped, you tell smd_thumbnail to update its thumbs:

If it copied the TXP thumbnail to each profile subfolder, overwriting the original profile thumbs, they would all show the correct (top) half of the TXP thumbnail but would all be the same physical dimensions, thus not reflectring their Large, Medium and Small monikers
If it recreated each profile thumb using the TXP thumb as its original — this is something the plugin does not currently do but could probably be made to do in the next version — then the profile thumbs all show the correct (top) half of the cropped thumbnail and are of the dimensions that reflect the sizes as defined in the profiles

Granted, if your TXP thumbnail is small and your Large profile is 200px square, then it’ll be all blocky/jaggy/yucky after being resized from the smaller thumbnail, but that’s user error :-) And is primarily the reason the plugin uses the full size image to scale down to thumbnail size. But if Gil wants to scale ‘up’ from a thumbnail — which is just a semantic term as the thumbnail may be 4000px wide if he wanted — then I should allow him to choose whether to create images from the full size image or thumbnail; probably via a global plugin pref.

Perhaps we’re talking about the same thing here, just at cross porpoises? Or have I totally lost the plot? Must admit I’ve never used ebl_image_edit so I don’t really know its workflow.

Last edited by Bloke (2011-06-23 23:37:50)

maniqui · 2011-06-24 00:04:22

The feature I’m suggesting is more a “last resort” (or “last step”) from a user POV.
Yes, no problem, let smd_thumbnail do all its initial automagic creation of every thumbnail for every smd_thumbnail profile and keep things in sync at first upload (or re-upload).

But then, if the user would like to override/overwrite one particular thumbnail with a better crop/resize created by ebl-image-edit, then it’s when this requested feature comes in.

Then, if someday the user, by mistake/error/culprit, hits one of those “create all thumbs” buttons, or if he decides to re-upload a new version of an existing image, and then, smd_thumbnail’s automagic creation of all thumbnails gets re-triggered, well, this is user “error”, and he should expect losing any thumbnail customization he did…

I think this integration of smd_thumbnails and ebl_image_edit as a feature to use after smd_thumbnails did all its automagic-creation-&-keep-in-sync duties, to let the end-user to create better thumbnails directly from TXP interface. Of course, using an offline image editor and replacing a particular thumbnail would probably lead to even better results…

In any case, let’s disregard any idea by maniqui for the time being.
I think it could end up being a usability nightmare, if we also consider that ebl_image_edit also has its dropdown of pre-defined thumbnail sizes/profiles, that won’t be in sync with smd_thumbnail profiles (this would cause inconsistency from a usability POV).
At least, until ebl_image_edit gets hacked or TheEric decides to add some plugin-friendly features.

Thanks for the prompt follow up, Bloke. I appreciate you taking the time to explain all the stuff I can’t foresee.

Bloke · 2011-06-24 00:23:50

maniqui wrote:

if someday the user, by mistake/error/culprit, hits one of those “create all thumbs” buttons, or if he decides to re-upload a new version of an existing image, and then, smd_thumbnail’s automagic creation of all thumbnails gets re-triggered, well, this is user “error”, and he should expect losing any thumbnail customization he did…

Yes, up to a point. I’m thinking of introducing a new plugin pref. Currently we have:

Keep TXP thumbnails in sync with default profile on: [x] Creation [x] Deletion
Recreate thumbnails on re-upload of main image

These already allow you to mitigate the effect of accidentally hitting the Batch button. The third preference might be:

Recreate thumbnails from: [x] Full size image [ ] TXP thumbnail

That way, if you have been mucking about with cropping thumbs in ebl_image_edit and have chosen to create smd_thumbs from TXP thumbs, if you accidentally hit a batch processing button, your thumbs would be recreated from the already-edited thumbnails which might minimise the damage. Thus you can protect against overwriting thumbs on upload of main image AND choose the source for recreating thumbs.

If you’re using ebl_image_edit heavily on a site I would suggest turning off the Recreate thumbs on reupload and also turning off both thumbnail sync checkboxes. That way, the information flow swings in favour of ebl_image_edit as master and smd_thumbnail as (manually updateable) slave.

If ebl_image_edit raised a callback the flow would be completely autonomous and people woudn’t even have to think about revisiting the Tools area as the prefs could be set up in such a way that the smd_thumbs would be auto-updated based on whatever latest thumbnail had been altered in ebl_image_edit. Mmmm, holy hand grenade.

Last edited by Bloke (2011-06-24 00:24:55)

THE BLUE DRAGON · 2011-06-24 08:01:34

Bloke wrote:

The third preference might be:

Recreate thumbnails from: [x] Full size image [ ] TXP thumbnail

Sweet :)

I really appreciate it and thank you for your time whether you make it or not.

MattD · 2011-08-11 18:12:01

Stef, I would expect that my <txp:smd_thumbnail type='projectSlide'/> tag would not include width and height in it’s output since I didn’t tell it to force_size. But it does. Documentation incorrect or am I misunderstanding?

My projectSlide profile:

Name	Width	Height	Quality	Crop	Sharpen
projectSlide	260	143	100	Yes	No

Output:

<img src="http://mydomain.com/images/projectSlide/33.jpg" width="260" height="143" alt="my photos alt" class="projectSlide" />

Bloke · 2011-08-16 09:42:45

MattD wrote:

Stef, I would expect that my <txp:smd_thumbnail type='projectSlide'/> tag would not include width and height in it’s output since I didn’t tell it to force_size. But it does. Documentation incorrect or am I misunderstanding?

Probably confusing docs, sorry.

From memory, forcing size won’t work unless one or both of the dimensions are set to 0: then it grabs the sizes from the image itself. Since you defined both your images they will always be present in the output.

Try using the width or height attributes to force one or both to be omitted (which I don’t think are documented on the txp:thumbnail wiki page yet but are on the txp:images page)

MattD · 2011-08-16 15:29:17

Thanks Stef, since my issue was with a javascript gallery going wonky in IE when the img tag included width and height, (no idea why, it was weird), I ended up just editing smd_thumnails to not output that part.

frickinmuck · 2011-09-26 23:15:33

I love this plugin! I was wondering if it’s possible to use this with smd_gallery – I love the idea of being able to do something like this:

<txp:smd_gallery type="Large" thumblimit="1" />
<txp:smd_gallery type="Small" offset="1" />

to display the first image using the large thumbnail, the rest using the smaller thumbnail. Or is there a simpler way to do this that my limited faculties aren’t grasping at the moment?

Never mind. DUH. txp:images works for this. :^)

Last edited by frickinmuck (2011-09-26 23:35:23)

Textpattern CMS

Textpattern CMS support forum

#121 2011-06-23 22:03:21

Re: smd_thumbnail: manage multiple thumbnails of your images

#122 2011-06-23 22:34:27

Re: smd_thumbnail: manage multiple thumbnails of your images

#123 2011-06-23 22:49:04

Re: smd_thumbnail: manage multiple thumbnails of your images

#124 2011-06-23 23:08:27

Re: smd_thumbnail: manage multiple thumbnails of your images

#125 2011-06-23 23:36:58

Re: smd_thumbnail: manage multiple thumbnails of your images

#126 2011-06-24 00:04:22

Re: smd_thumbnail: manage multiple thumbnails of your images

#127 2011-06-24 00:23:50

Re: smd_thumbnail: manage multiple thumbnails of your images

#128 2011-06-24 08:01:34

Re: smd_thumbnail: manage multiple thumbnails of your images

#129 2011-08-11 18:12:01

Re: smd_thumbnail: manage multiple thumbnails of your images

#130 2011-08-16 09:42:45

Re: smd_thumbnail: manage multiple thumbnails of your images

#131 2011-08-16 15:29:17

Re: smd_thumbnail: manage multiple thumbnails of your images

#132 2011-09-26 23:15:33

Re: smd_thumbnail: manage multiple thumbnails of your images

Board footer