Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2020-08-03 16:43:28

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 3,176

Re: Multiple image handling: profiles

jakob wrote #325094:

ImageOptim also has an API (hattip to Pete) including a resize option but it’s not free.

There’s this – any good?: github.com/ImageOptim/php-imageoptim-api

Offline

#12 2020-08-03 19:05:21

giz
Member
From: New Zealand
Registered: 2004-07-26
Posts: 190
Website

Re: Multiple image handling: profiles

Bloke wrote #325085:

Yes, part of the issue here is that smd_thumbnail requires endless configuration for no actual gain. It simply adds complexity to have to create new profiles for different ratios or different pixel densities.

So I’m looking for a better method to support and define that without all the faff.

I’ve found most clients (admin users) are bowled over by the complexity around managing images / resolution / pixels; adding profiles and sets of images to choose between would burden them further.

I like to keep the images tab as a master repository of images in their original resolution and proportion – ready for further manipulation / display via whatever template you’re using in TXP.

I use SLIR to handle all image sizing – its rather good , generates images on demand, caches them, and allows the designer to control everything from the code.

Try it!

Last edited by giz (2020-08-03 19:05:54)

Offline

#13 2020-08-03 20:44:11

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,792
Website

Re: Multiple image handling: profiles

giz wrote #325106:

I’ve found most clients (admin users) are bowled over by the complexity around managing images / resolution / pixels; adding profiles and sets of images to choose between would burden them further.

Yes. And that’s an excellent point. It’s not just end users, but admin users too.

I use SLIR

I did look at that briefly, then forgot all about it, sorry. Considering what it does, and that it only requires GD, the fact it’d add a few hundred KB to our core seems fairly modest. Yes, it’s a good few years old now. But if it works, well, who’s to say we can’t just try it out.

I’d like to see how it stores all those files (in that empty /pel directory?). If it keeps them in subdirs somehow, then even better. Guess it’s not that important: running your site with 7K images is a good testament to it working well!

So if we didn’t bother with profiles at all and stuck SLIR in Txp’s /vendors directory, I wonder how we’d use it in core? We’d have to maybe symlink (bah, Windows) to it or use mod_rewrite to pass control to the correct dir. Or simply install it in our /images directory (is that dangerous?). I’m a bit wary of polluting the root file system with another dir, but that’s the worst case scenario.

After that, do we just let it do its job? Leave it entirely up to the site designer to create whatever images they want from originals as suits their design? If they want to make srcsets from the images, all they need to know is the syntax for creating their own images (if they wanted to do it by hand).

Or we could hardwire <txp:image> tag attributes such as width and height to pass them through /slir before fetching them. If we retrofitted them with some other attributes like crop and quality and fill etc then it might just be all we need. No admin overhead. I kinda like the sound of that. Especially when core could do exactly the same calls to auto-generate thumbs and grid images as needed.

The thing I really like is that it forbids upscaling. So if you do try and upload a teensy image, so what? You get the same size image when you pass it through /slir and ask for a bigger one, right? That has serious merit. Does make it interesting if someone uploads a crap quality/size image as it might break a layout, but caveat utilitor.

Y’know, the more I think about this, the more I like it. There has to be a downside. Is there?

EDIT: I guess we don’t get the option to do art direction or custom crops / thumbs at all, because there is always only one main image from which all others are taken. Unless we could extend it to permit cropping at a given point. Or use CSS on the output stage to handle reframing?

Last edited by Bloke (2020-08-03 21:01:31)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#14 2020-08-03 21:02:29

giz
Member
From: New Zealand
Registered: 2004-07-26
Posts: 190
Website

Re: Multiple image handling: profiles

Bloke wrote #325110:

I’d like to see how it stores all those files (in the pel directory?). If it keeps them in subdirs somehow, then even better.

Wherever you put slir and run its install script, it creates a folder structure like so:

  • {my-slir-install}
    • cache
      • rendered
      • request

Calling slir from anywhere is as simple as <img src="path-to-slir/my-slir-install/w640/<txp:image_url />" />. If you omit the sizing string, slir returns the original image url.

So if we didn’t bother with profiles at all and stuck SLIR in Txp’s /vendors directory, I wonder how we’d use it in core? I mean, do we just let it do its job? Leave it entirely up to the site designer to create whatever images they want from originals as suits their design? If they want to make srcsets from the images, all they need to know is the syntax for creating their own images (if they wanted to do it by hand).

Or we could hardwire <txp:image> tag attributes such as width and height to pass them through /slir before fetching them. If we retrofitted them with some other attributes like crop and quality and fill etc then it might just be all we need. No admin overhead. I kinda like the sound of that. Especially when core could do exactly the same calls to auto-generate thumbs and grid images as needed.

The second one!

Y’know, the more I think about this, the more I like it. There has to be a downside. Is there?

None that I know of. The biggest problem I’ve had was once when a client’s host changed data centres and time zones, and some of the images came up as 404 on the public site. The fix was deleting slir’s cache so it could start afresh.

Last edited by giz (2020-08-03 21:05:14)

Offline

#15 2020-08-03 21:47:05

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,792
Website

Re: Multiple image handling: profiles

giz wrote #325111:

Wherever you put slir and run its install script

So that installation might have to be something we could automate somehow as part of the Txp upgrade process. But if we could conquer that then I don’t see why we can’t install it inside an /images/slir/fetch/ directory. So the cache sits there, and all the image handling code and full size pics can sit alongside it. Nice and compartmentalised.

One day we should consider rejigging our storage methodology (as I alluded to in the OP) so the main images are not all in one dir, but that does make generating images via slir potentially more tricky since the /path/to/image might not always be the same. Needs to be pondered.

Calling slir from anywhere is as simple as <img src="path-to-slir/my-slir-install/w640/<txp:image_url />" />.

So, let’s see. Today:

<txp:images category="products" wraptag="div" class="gallery">
   <txp:image width="0" height="0" />
</txp:images>

Creates:

<div class="gallery">
   <img src="/images/widgetA.jpg" alt="Widget A" />
   <img src="/images/widgetB.jpg" alt="Widget B" />
   <img src="/images/widgetC.jpg" alt="Widget C" />
   ...
</div>

We could do this:

<txp:images category="products" width="450" background="ccc" wraptag="div" class="gallery">
   <txp:image width="0" height="0" />
</txp:images>

Which would create a gallery thusly instead:

<div class="gallery">
   <img src="/images/slir/fetch/w450-bccc/images/widgetA.jpg" alt="Widget A" />
   <img src="/images/slir/fetch/w450-bccc/images/widgetB.jpg" alt="Widget B" />
   <img src="/images/slir/fetch/w450-bccc/images/widgetC.jpg" alt="Widget C" />
   ...
</div>

That would make all images in that set 450px wide with optional light grey background if they needed scaling in any dimension, dump them on the page and cache them for the next person.

If so, I’m sold. We can close this thread, add the feature and go home :)

Realistically, I wonder if there are any security implications of leaving /install lying around after the fact? I mean, in theory anyone could re-run it and alter the installation dir, which would break the feature or potentially redirect elsewhere.

Maybe we could run it once on a local install, see what it does, and what it generates. There’s mention of a config file so I wonder if that might give some clues. i.e. does it just create the dir structure you highlighted or does it do more?

Then there’s also what to do with multi-site installs. And what about people who use ihu to serve images from a cookieless domain other than the one in Txp? That might not have the ability to run PHP, so housing slir in there might not work.

It’d be nice if slir’s core PHP itself could be uploaded to, say, /vendors and we could just “install” the cache to /images/fetch. i.e. split it. If it does permit that, things get a lot easier – especially for upgrades. That might give us the opportunity to add a pref that could define the endpoint of your cache. If that’s set, slir wakes up when you Save the prefs and all the image tags start to use it. Without that pref, you get image links as you do today.

Not sure what would happen if you changed your mind and moved the cache by changing the pref. That sounds awkward, so maybe that won’t work and we just automatically assume ihu is the base path of where the cache will live. Then again, if you change your mind, the worst thing that happens is that you lose the thumbs that have been cached and start again. The only way round that would be to manually move the cache over to the new location. And if you don’t move/delete the cache, it just stagnates and takes up space.

Hmmm, I can feel some experimentation coming on…


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#16 2020-08-04 04:21:31

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 8,297
Website

Re: Multiple image handling: profiles

Hi guys,

I’m worried about incorporating an unsupported project as part of the core. Also, I understand that SLIR has issues when working on MAMP/WAMP offline environments and it will more tedious for new users to set up or ignore it.

I nevertheless like the idea of SLIR and I am wondering if there is another supported script which can do more or less what it does.


Yiannis
——————————
neme.org | hblack.net | LABS | State Machines | NeMe @ github | Covid-19; a resource
I do my best editing after I click on the submit button.

Offline

#17 2020-08-04 05:04:38

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,146
Website

Re: Multiple image handling: profiles

so… what I understand so far from this thread, you are mostly focussed on generating images for gallery type of pages / sites. what I work with mostly is very far away from that. What I do is articles – text narrative – which may contain images. the narrative lines between text and images is sometimes complementary, sometimes diverging, sometimes even clashing. And then those embedded images need various sizes (accommodating large and small screens). to make it more fun, for one set of articles I may need large and small images, e.g somewhere in the article you see a 800px wide image, other places use a couple of 300px images side by side. other sets of articles have different requirements / needs when it comes to images.

It is even possible that an article contains, in the middle or towards/at the end some kind of mini-gallery of rather thumbnail sized things.

and more fun: images were sometimes reused in other articles in a different context with different t size requirements…

smd_thumbnails is useful in managing all this although it requires quite a mess of profiles…


Where is that emoji for a solar powered submarine when you need it ?

Offline

#18 2020-08-04 08:51:20

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,792
Website

Re: Multiple image handling: profiles

phiw13 wrote #325115:

so… what I understand so far from this thread, you are mostly focussed on generating images for gallery type of pages / sites.

Not at all. Sorry if that came across. It was late and my brain couldn’t face coming up with more than one (simple) example, so I chose gallery.

I haven’t thought it through fully yet, but for the multi-size case you might be able to do this:

<txp:images name="JapanIn1805.jpg" width="800, 1280, 300" />

And that would generate:

<img src="/images/fetch/800/images/JapanIn1805.jpg"
    srcset="/images/fetch/800/images/JapanIn1805.jpg 800w,
        /images/fetch/1280/images/JapanIn1805.jpg 1280w,
        /images/fetch/300/images/JapanIn1805.jpg 300w" />

That’s one image, multiple sizes that the browser can choose from, by using <txp:images> (plural) to deliver the set. And note the first one is the ‘fallback’ image used for browsers that don’t understand srcset (if there are any left out there that don’t).

Now, that’s only a third of the story. You still need to somehow specify the HTML sizes attribute to give the browser an indication of how to handle the images at your breakpoints. I guess we could just add a sizes attribute and that could be passed verbatim to each image in the “set” (which in this case isn’t a gallery: just the same image at different widths).

If you combined the above with not just one image but an entire category of images, you could create a gallery where each image also has a bunch of sizes for viewports, so it makes each image have the same set of image widths you define in the <txp:images> tag). I think that would work.

The beauty of the slir approach is that once the heavy lifting has been done on first render at any given device width, the images at those sizes are cached so future paints are near-instant. So you get an infinite number of profiles without having to define them up-front – which is where the smd_thumbnail approach falls down.

The final third of the puzzle is perhaps using <txp:images> to output <picture> wrappers and somehow getting it to render <source> tags, as well as being able to output srcset. In that situation it’s sometimes not the same image each time because you want to do art direction such as offering a zoomed-in view that uses a completely different image.

It might be too much to ask for a single tag to do it all, so I’m open to suggestions how to handle this for the least amount of confusion and maximum flexibility that allows us to build sensible and powerful HTML tags with a little Txp magic.

somewhere in the article you see a 800px wide image, other places use a couple of 300px images side by side. other sets of articles have different requirements / needs when it comes to images.

And this is a perfect example of why you don’t need pre-defined profiles. They’re counter-productive because you get all these images created on your behalf that you could use, but probably won’t ever need, which wastes space.

An on-demand image generator such as slir would give you the flexibility to render a single image at 800, then two later in the article at 300. For maximum enjoyment you could make yourself a shortcode to do it and pass the width(s) and filename(s) you need to a form.

and more fun: images were sometimes reused in other articles in a different context with different size requirements…

Again, on-demand image generation covers this. When your visitors encounter the same image in a different width, a cache miss occurs, slir goes off and generates the image for you at the given size, serves it and caches it for next time.

Does that give you more insight into the idea?

Last edited by Bloke (2020-08-04 08:56:43)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#19 2020-08-04 08:56:52

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,396
Website

Re: Multiple image handling: profiles

I’ve only skimmed this thread as I’m really busy this week – but my opinion on image handling is in agreement with others here, that:

  1. You upload an original image at whatever max size it was created at. No processing is done on that image (i.e. it stays at original dimensions/file size). That is your master image, for want of a better word.
  2. Textpattern then creates one or a number of different sizes of that image depending on what profiles you have set up (we can define some defaults as a starting point). Cropping can occur based on original versus profile.
  3. Textpattern also creates a thumbnail image square (cropping done) which it uses on the images list panel(s). This can be used on live site too, if required for some reason.
  4. Possibly, user can upload replacement images for any that have been auto-created by the profile.
  5. Cropping/rotating/etc of original file can be done directly within Textpattern panel, but the edited file never overwrites the original.

This above process means that if the user decides at some future date to change their theme, column width, whatever, the original images are still available to generate new sizes from.

It’s going to be a careful balance between simplicity, perceived user ability and features to get this working in the best way. I need to play with my latest local WordPress install too and see if there is any learning we can get from their process.

Offline

#20 2020-08-04 09:07:48

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,792
Website

Re: Multiple image handling: profiles

colak wrote #325114:

I’m worried about incorporating an unsupported project as part of the core.

It’s a valid concern. The project is over 5 years old, despite being written in a forward-thinking object/class manner (from skimming the code). I don’t know of any alternatives that do the same thing, because I haven’t looked. If there’s a better project, great.

We can’t shield ourselves indefinitely from unsupported code. phpass, which we include, has ceased development it seems. jQueryUI is gradually dying it seems. So what seemed like a good idea 5 years ago is now not so. There’s nothing we can do but adapt.

The good news is that if we do find that slir (or whatever) breaks under some future version of PHP or something there’s nothing to stop us forking it, because it’s open source code. PHP might decide one day to drop GD, but if they do that, Txp is stuffed as it is today anyway in the thumbnail department as we’ve assumed it’s available.

Yes, it’s possibly a bind to fork third party code and maintain it, as we’d need to grok it and maybe in the process come up with ways to extend it to do more. But the option is there should we need it. It’s only code.

The fact Gary (giz) has been using it for years and it’s still working is testament to the fact it must be reasonably well written in the first place. It would need thorough testing. And if anybody does stumble upon a more recent project that does something similar for the roughly the same (or smaller) code/memory footprint then let’s consider it. I’m rapidly going off the idea of “image profiles” because they’re way too restrictive.

I understand that SLIR has issues when working on MAMP/WAMP offline environments

This I don’t know. If that’s the case then maybe we’ll need to fork and patch it from the get-go. If the “installation” procedure isn’t automatable or if the slir code must reside in the image directory where your cached images are stored then it’s also a show-stopper for me. I don’t like the idea of code lying around in my /images dir. If that was the case, we’d either need to find an alternative project that does allow it or fork and make the changes ourselves.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB