Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Handling multiple image formats
Bloke wrote #335311:
we can leverage Intervention or Imagick to do it, which is what we’re planning to use for everything else. Not tested it for performance yet.
I use GraphicsMagick GUI in FreeBSD desktop for daily image manipulation. GM is a quick and lightweight, although quite feature-rich and high quality alternative to ImageMagick. GM converts images to avif and webp, but I do not find php module for GraphicsMagick, although the website says it has.
Offline
Re: Handling multiple image formats
Not heard of GM. Thanks for the tip. I’ll look at it and see if it has anything we can use.
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
Re: Handling multiple image formats
One more thing for bedtime reading:
- Glide (MIT) glide.thephpleague.com github.com/thephpleague/glide
Edit: actually, never mind – already on the radar: forum.textpattern.com/viewtopic.php?id=51453
Last edited by gaekwad (2023-04-18 07:35:22)
Offline
Re: Handling multiple image formats
I’d forgotten about Glide so it’s always good to polish the radar every now and again. Thanks for the nudge.
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
Re: Handling multiple image formats
Bloke wrote #335325:
I’d forgotten about Glide so it’s always good to polish the radar every now and again. Thanks for the nudge.
No trouble. FYI, happy to deploy extra image handling libs to the demo server if you want a live testbed.
Offline
Re: Handling multiple image formats
FWIW, in no particular order of importance
- AVIF images – trying to generating this type of images is depressing. The google tool (Squoosh) generates systematically more contrast than the original; an alternative (avif.io) on the other hand generates very soft images. I have command line tool (cavif-rs, by Kornel of imageoptim fame) but I have not used it in a while. Source images for those tests where high quality JPEG and TIFF images, landscapes and outdoor portraits mostly.
- I have mostly given up on the workflow linked by Bloke in the OP. The few people I tried it cannot be bothered by the effort, and for my personal needs, I only upload jpg/png and when needed sFTP equivalent webp images.
- my favourite workflow would be: upload a high quality, uncompressed JPEG image (still a recognised archival format) and have the tool then generate the needed scaled down images (JPEG and eventually webp, although the benefit of that format is not large). AVIF might be nice (file size), but see above about converters. This should be based on a series of preset profiles, similar to the way smd_thumbnails currently works. The tool should have an option to override automatic generation for some images (UI screenshots are notoriously difficult to automatically downscale). For PNG images I am not sure what to recommend.
- a little exercise I did recently (again): testing which images (sizes) — in a given layout with <picture /> and 3 diff. widths (small, medium & large) are actually requested by browsers. Result: the small format was never requested by any browser, most phones and tables requested at least the medium format (phones, tablets in portrait mode) – 600 ~ 700px wide images.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Handling multiple image formats
phiw13 wrote #335328:
AVIF images – trying to generating this type of images is depressing.
Yeah, support is very patchy, it seems. Not even sure if it’ll gain enough traction to win the VHS/Betamax, Blu-ray/HD-DVD, etc war.
I have mostly given up on the workflow linked by Bloke in the OP.
Unsurprising. It’s a massive faff. We can do better.
my favourite workflow would be: upload a high quality, uncompressed JPEG image (still a recognised archival format) and have the tool then generate the needed scaled down images… This should be based on a series of preset profiles, similar to the way smd_thumbnails currently works.
If – and only if – Intervention/Glide/SLIR/whatever tool we find that isn’t bloaty is viable to generate images on the fly, this is perhaps the workflow that makes sense to me:
1) Visit prefs (or some inline prefs on the Images panel) to access a textbox to specify the sizes and/or formats you want. These act as the only valid sizes your installation will generate. If you try to generate images at different sizes, they will be rejected. This is for sanitization, and security to prevent spamming the server with requests. Core itself will already have built-in defined image sizes/types that it requires for list/grid view on the admin-side. Perhaps these are set in constants.php and can be overridden in config.php. Not sure whether overriding makes sense, given it’ll affect the admin-side layout grid. But if those sizes are suitable for your front-end site then they’re available for use wherever.
2) Upload one or more high quality ‘master’ images using the Images panel. Optionally post-process them individually and provide meta data. If metadata is embedded in the files, there may be an avenue to insert it automatically, but formats (e.g IPTC/Exif) vary wildly so this might be better for plugins to handle. Alternatively, do people who use images regularly have a way to export metadata from image processing tools like Lightroom, into a machine-readable format (e.g. json/xml) that can be uploaded alongside the images to auto-populate the metadata accordingly?
3a) A pref to auto-create thumbnails based on your chosen sizes at upload. This may suit people who do all their editing offline and upload pre-edited copies to Textpattern. This may not be viable depending on server loads (e.g. if you upload 100 images, it’s going to take a significant amount of time to wade through them all).
3b) Defer creation until the thumbs are needed. Whether this is via srcset/picture/txp:image tags on the public site or visiting the admin-side panel is immaterial. If an image is requested, the relevant size/type will be generated and cached. Shortcut attributes in the <txp:image> tag could pre-populate a srcset with values taken from your sizes pref, to save you having to type them out each time. That also means if you edit the list in the pref, all your image tags update accordingly and serve the new image sizes/formats.
3c) A button on the Image Edit panel to (re)create some or all thumbs from the main image ‘now’. Note: multi-edit will likely not be available due to the vast quantity of resources that may be consumed. Options 3b and 3c will suit people who wish to post-process images in Textpattern itself using any contrast/brightness/gamma/crop/plugin-provided filters.
3d) The ability to replace individual thumbs with an uploaded copy on the Image Edit panel. Useful for art direction, special effects, or to upload formats that don’t fare well under automatic conversion.
4) Profit.
Which options in step 3 are available will depend on what capabilities we want to expose. Ideally, all of them would be available but I would like b, c, and d at minimum.
If you upload a new version of a main image, it’s marked as ‘dirty’ somehow (i.e. the thumbs are flushed) so they can be recreated via one of the options outlined in step 3 above. Whether these overwrite the existing thumbs will be library dependent. If not, some element of garbage collection will be required. Perhaps an ‘image expiry’ pref that dictates the maximum age of a thumbnail since it was last generated before it’s deemed out of date and needs to be recreated when next accessed. We also need to consider those images that haven’t been accessed at all in ages (e.g. from old sizes/formats that are no longer in use). Not sure how to handle that. Ideas welcome.
a little exercise I did recently…
That’s interesting, thanks for sharing. Didn’t expect them to ignore the small versions, but maybe mobile browsers assume it’s a better experience to grab the next size up bandwidth allows?
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
Re: Handling multiple image formats
Bloke wrote #335329:
this is perhaps the workflow that makes sense to me:
[…]
That is more or less the steps my prefered work-flow (dream/ideal/…) implies – assuming that an adequate tool is available. Thanks for fleshing that out.
That’s interesting, thanks for sharing. Didn’t expect them to ignore the small versions, but maybe mobile browsers assume it’s a better experience to grab the next size up bandwidth allows?
That was using a <picture /> with a list of width-defined options in the srcset, a pattern like this screenshot. Basically saying here is a list of 3 images available, pick what suits you. The small screen devices never requested the small size, as most (all) are at least 2x dpi, and more and more 3x. The only one who would eventually pick the small size are users who work in a split screen environment (e.g ⅓ the browser for viewing a web page, ⅔ other app).
–^–
BTW,
Core itself will already have built-in defined image sizes/types that it requires for list/grid view on the admin-side. Perhaps these are set in constants.php and can be overridden in config.php.
I would certainly hope that at least some form of site/user config will be available, depending on the needs of the site.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Handling multiple image formats
Basically saying here is a list of 3 images available, pick what suits you.
I know that from the shopping system I am working with and I quite like the concept. You upload a product image and it is stored in the folder “original images”. It will stay there and used later for regenerating if wanted. Then a copy of that with sizes that can be predefined is put in the folders “thumbnail-”, “mini-”, “midi-”, “info-” and “popup-” images. This would be 5 different sizes. If this is really needed for textpattern… not sure.
Working with the template and using those 5 different sizes is pretty convenient to me. But of course I am just pointing things out more from a usability percpective than technically.
In practice that means of course that the sizes can either be used in a srcset or individually if needed.
I quite like the idea of using something like slir. I lately used slir in a textpattern website (TXP4.8.8, PHP8) and liked the fact, that it is a no-brainer for the authors of the website. They do not want to deal with different imagesizes etc. They just want to upload an image and it should work without further adjustments or thinking.
What I like with the use of slir is that cropping can also be included. I quite often run into the problem, that the person that will mantain the website, has no grafix toll at hand or is not really willing to use any. And he/she shouldn´t IMHO. Also there should be no question in which situation which image size should be used. That should be at least somehow be pre-definable by the developer and does not neccessarily be adjustable by an author.
Maybe in the upload process the user could decide if he wants the image to be cropped or whatever.
In my opinion fancy things like graysacling or rotating would go too far. That should not be needed to be handled by a (lightweight) CMS.
Offline
Re: Handling multiple image formats
Yes, all good points. How would cropping be managed? If you set up predefined sizes and say which ones are going to be cropped, and by how much, it means all images at that size will have them done that way. SLIR works by adding the crop commands in the URL, so they have to get into the URL somehow.
Defining different image formats also needs considering. That’s potentially simple when defining acceptable sizes.
Rotation and flipping is handy when uploading images that have come directly from a camera, so that’s why they’re in the images branch. Greyscale and any other transforms we’ll leave to plugins, for sure.
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
Re: Handling multiple image formats
How would cropping be managed? If you set up predefined sizes and say which ones are going to be cropped, and by how much, it means all images at that size will have them done that way. SLIR works by adding the crop commands in the URL, so they have to get into the URL somehow.
Now that I get my head around it I realize that it is not so trivial. Especially when you consider that you possibly want different image sizes for different reasons. It could be that you want to deliver an image by srcset for different devices in an appropriate size but at the same time it could be that you want the pre-defined smaller image to act as an image on an overview page and the bigger image should be the image on a details page.
Whereas the bigger image might also need different sizes in its scrset.
But then it would not want to use the small image that was used on the overview page because this might have wrong dimensions.
So what about the idea to forget about all this pre-defining and to handle all just the slir-way? Thinking about my own type of setups I don´t see the necessity to have a multi thumbnail option in txp itself. But it might be important for others. Maybe at some point there has to be some kind of compromise.
Or maybe in txp we generate only 2 or 3 different images by default. You can predefine their sizes. They are mainly used for srcsets and anything else is done via url? Would that make sense? Not sure if this is too complicated at the end.
Offline
Re: Handling multiple image formats
demoncleaner wrote #335410:
Now that I get my head around it I realize that it is not so trivial.
Hehe. Welcome to my world, and why I’ve not made much headway on it!
Especially when you consider that you possibly want different image sizes for different reasons.
Yes, not only different sizes but different formats (webp, avif, and fallback jpg, for example). But the beauty of on-the-fly image creation is that it doesn’t matter. If you change your mind, it just creates new ones.
So what about the idea to forget about all this pre-defining and to handle all just the slir-way?
I don’t want people to have to define anything up front, but it’s necessary to prevent abuse. Whatever tool we decide upon to deliver on-the-fly image creation needs to be limited to only produce select sizes. Otherwise someone could spam the server with requests for every image size under the sun, and clog/DOS both the site as it generates them, and the disk when it caches them.
Current thinking is that you define a range of sizes; however many you need, it doesn’t matter. Txp will have a bunch of size requirements built in (for admin-side image display in its thumb/grid) and these may be exposed via config.php so you can override them, but that’ll be up to Phil’s CSS.
So every time anyone – core admin side, plugin, site template, etc – requests an image, it consults the allowed image sizes and verifies that the incoming request matches. If it doesn’t, the request fails.
Annoyingly, it might be nice to constrain just one of the dimensions, e.g. specify a max width of 320px. But that would mean people could spam the other dimension with everything from 1px to 50000px, and tie up the server. So I think the only sensible/safe way is to constrain what image sizes can be constructed in both dimensions.
That’s not so bad, because if you, as admin/designer, specify 10 different sizes, including portrait, landscape, square, grid and a couple of hi-density options, when you construct the image tag, it’ll still only physically make the ones you need when the page is viewed by one or more visitors with differing environments. One might make a couple of JPGs, one a webp in a landscape orientation, one could be a cropped square avif, and so forth. All cached for future requests.
In the smd_thumbnail “profile” model, all sizes for all images are made, which doesn’t make sense.
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