Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Multiple image handling: profiles
Bloke wrote #325138:
Nice! An additional 79KB plus whatever baggage composer brings in.
Just composer installed the whole lot (Glide, Intervention Image and Flysystem) and the size is about 900kb. That gives us image editing tools, image caching and (via Flysystem) the ability to add and use adapters to write the final images directly to services such as Amazon S3 and Azure. Pretty impressive.
Offline
Re: Multiple image handling: profiles
That’s not a bad package indeed. This is sounding viable.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Multiple image handling: profiles
Bloke wrote #325090:
It’s far better for users to just drag an image – whatever the size (max file upload limits notwithstanding) – and have Txp automatically generate every image size that we – the designers – have decreed we require. So it makes us a max-res 1600px image, plus a 1280px, plus an 800px and a 300px image because we know that our design supports those sizes.
The fact we never use the “collosal” original is a small price to pay for the end-user convenience of just being able to throw pretty much any image at the CMS and have the designer (the person who has set up the image profiles and breakpoints and templates) handle everything on their behalf.
Yes. These two brief paragraphs nail it. Image confusion is the one consistent issue I have in handing sites over to customers. Having the above capability in 4.9 in a manor that’s easy to use would be huge for Textpattern.
Offline
Re: Multiple image handling: profiles
Hi,
if handling images is like described by Stef then it will be a huge improvment in simplicity for end users.
I am eager to see the first draft of that.
Cheers.
Offline
Re: Multiple image handling: profiles
philwareham wrote #325122:
- You upload an original image at whatever max size it was created at. No processing is done on that image
I do not know PHP GD module capabilities nor Tinify quantization technique, but its Panda drastically eliminates my PNG and JPEG overweight without compromising image quality — and thus with no options, no questions about desired image size. Panda offers free Tinify API for HTTP, PHP, Node.js, WordPress and other CMS.
Sometimes I check my new pictures by another similar online service called Cloudinary, although it optimizes images on webpage only.
(i.e. it stays at original dimensions/file size). That is your master image, for want of a better word.
- 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).
That is what I meant naming it default txp:image — not txp:thumbnail, and not an original full-size master image, thank you.
EDITED: I remembered Cloudinary, too.
Last edited by Vienuolis (2020-08-04 15:36:37)
Offline
Re: Multiple image handling: profiles
Vienuolis wrote #325146:
I do not know PHP GD module capabilities nor Tinify quantization technique, but its Panda drastically eliminates my PNG and JPEG overweight without compromising image quality
Image optimisation tools are a separate discussion in my opinion, and perfect for plugin territory, once we have the fundamental image processing and UX nailed down.
You simply run whatever optimisation tool you have signed up for over your images directory. Indeed, all the third-party integrations mentioned in the Tinify website are simple scripts to point the API at the right image directory of the CMS.
Offline
Re: Multiple image handling: profiles
Bloke wrote #325112:
Realistically, I wonder if there are any security implications of leaving /install lying around after the fact?
To the best of my knowledge once installed in the (say) images directory, the installer script is no longer needed unless the location of slir is changed. eg. my all-grid template has slir installed in the theme’s directory. I ran the installer script once on my Mac under MAMP, and then transferred the theme to the live server. I didn’t need to reinstall slir in its new location.
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?
Dunno. It does have quite a few options, but I must admit I’ve never bothered playing with them as the default settings have always been up to the task.
Hmmm, I can feel some experimentation coming on…
Gluck!
Offline
Re: Multiple image handling: profiles
Bloke wrote #325127:
Now this is where slir falls down. Unless we can understand how it caches images and retrieve them, we have no idea how many images at varying sizes and crops and whatever have been created. So we can’t offer to individually replace them.
I’m the last person to ask how slir works ;-) but clients replace/change images all the time and everything behaves as it should. We don’t need to know what has happened to the old unused cached versions – they get deleted from the system by slir’s garbage collection routine.
Again, this is something slir doesn’t give us. So if you upload an image that is on its side from the camera, I don’t know how to handle this. If we’re saying we’re not changing the original in any way once it’s uploaded, this is going to be an issue.
An image rotation option would be incredibly useful. Just because the image is right way up on your desktop is no guarantee that it’ll stay that way when uploaded into TXP.
Now, if we were to alter the image and allow some rudimentary editing of the original so you could zoom in, crop, rotate inside Txp and then commit your modifications, how does that affect any cached images that have already been created? Presumably they have no knowledge of the fact you’ve changed it, so when you ask for your 450px version, you get the old one from the cache. Gary might be able to supply some info on this if he’s ever replaced any original pics from the Image Edit panel.
If slir is clever, it will check the timestamp of the original and if it differs from that of the cache, it’ll invalidate the cache version and overwrite it with a fresh copy generated from the (changed) original. If it does that, I’d be happy with just allowing people to edit the original and have it cascade to the image cache on an as-needed basis.
Thats how I think it works: here’s my MAMP test install:
- slir-install/cache
- rendered (these are image files, and have varied creation dates)
- 69d777f01ce76fac77f8ce391f207283
- 545c44e5ec5f72edd4584756e96d78c3
- 0279790813f31aef0e154cab7bed0687
- a11095f466f57e006a7573849c52cedc
- request (these show up as aliases on my mac, and have the same creation date)
- 20bf2ec0606bcaaccc7ddc8edbef2a58
- 96cc4dca608c785e0e975f564d6a9437
- 749a7a44fa24ada11c9b5c8fa5d9ae0e
- 300926855770a5f6edd2b3b0bde6aa13
- a35997bd99ddc5082b73b474bba7a786
- rendered (these are image files, and have varied creation dates)
Offline
Re: Multiple image handling: profiles
On a MAMP install, slir’s .htaccess directive (sometimes) needs these 2 lines to be commented out:
# Prevent other scripts from interfering with SLIR
php_value auto_prepend_file none
php_value auto_append_file none
Offline
Re: Multiple image handling: profiles
philwareham wrote #325147:
Image optimisation tools are a separate discussion in my opinion, and perfect for plugin territory
Why? The quantization is not a choice between weight and quality — it always remains in original quality, eliminating overweight only.
For an example: smd::thumbnail asks publisher for image quality (default 75%). Alternatively, the quantization retains full 100% quality always, asking nothing, and providing images even lighter than optimized to 75%.
I’d like Textpattern would always (not only by default) upload quantized images only, do not caring about its raw stuff. Further graphics manipulation leaving to SLIR and plugins.
Publishers, designers, and sysadmins would be grateful for such simplicity ant clarity of Textpattern. And visitors would love the maximum quality and speed of webpages, produced by Textpattern.
Last edited by Vienuolis (2020-08-05 08:24:35)
Offline
Re: Multiple image handling: profiles
philwareham wrote #325147:
You simply run whatever optimisation tool you have signed up for over your images directory. Indeed, all the third-party integrations mentioned in the Tinify website are simple scripts to point the API at the right image directory of the CMS.
Designers know that you need a high-quality image to start with if you’re going to resize them and keep the same quality. Users don’t, they just hope for the best. It’s no good running an optimisation script over directories of images that have lost quality in the resizing process. As Vienuolis is pointing out, we need the Textpattern process to keep the full 100% quality whilst drastically reducing file size, just as Panda does. This needs to be done before or during not after the processing. If scripts like these can do this using Panda, then why not a Textpattern one?
At present, smd_thumbnail trades off between quality and byte size, because Stef isn’t an expert wrt to image optimisation. SLIR is reported to produce good image quality and perhaps the others too, but is the quality as good as Panda? I doubt it, but would love it if proved wrong.
Dozy P My attempt at music
Offline
Re: Multiple image handling: profiles
I see where everyone is going with optimisation. Using a proper optimisation service (online or in your OS of choice) is arguably better than the ‘quality’ setting offered in GD which we use in core and I expose in smd_thumbnail. That quantizer just smooshes the file size down and throws bytes away without much regard to qualitative/visual effects.
Proper optimizers (and maybe those filters loaded into the third party tool we’re evaluating as part of this image drive) do far more analysis and are often slower as a result, depending on the level of optimization.
I say we test the Image Intervention library and see what it can do. Phil’s hot on optimization, so if it does a decent job of it, he’ll know. If it works well, we can perhaps offer it as part of the bundle and expose the degree of optimisation to admin users when uploading and manipulating images. And expose it to plugin authors for more control.
If it doesn’t work well, let’s keep the optional third-party optimization step as a stretch goal. If it’s used by a lot of systems, as zero say, then clearly it’s possible and maybe the service isn’t going away. It might be desirable to include it in core, it might not. In which case we could expose it to plugin authors instead.
My reservations are:
- It adds a network step to the upload process, which has the potential to slow things down (or break the user experience).
- Automatically passing images through a third party service may violate the trust we layer in Txp. I know some people upload their own copyrighted images to their sites and watermark them and so forth. I wouldn’t like to automatically employ a third party system and find that they cache the optimized images (or originals) somewhere.
In short: let’s play this one by ear.
Last edited by Bloke (2020-08-05 09:29:25)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Multiple image handling: profiles
philwareham wrote #325147:
Image optimisation tools are a separate discussion in my opinion, and perfect for plugin territory, once we have the fundamental image processing and UX nailed down.
You simply run whatever optimisation tool you have signed up for over your images directory. Indeed, all the third-party integrations mentioned in the Tinify website are simple scripts to point the API at the right image directory of the CMS.
Hmm. Image optimisation is a serious problem. How “bad” are those tools at producing decently sized images? I once ran some test with the (default) smd_thumbnail, comparing with the exact same process in my image editor, starting from the same mother image. image editor won … massively.
and this:
run whatever optimisation tool you have signed up for over your images directory
I don’t feel comfortably at all introducing such an external dependency.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: Multiple image handling: profiles
I think we are all talking at crossed-purposes here regarding optimisation. That is just a small part of the grand scheme.
The process I see is:
- User uploads their original photo to Textpattern.
- Intervention Image then makes a series of duplicated copies of that image based on user-defined size settings (or a default set if user hasn’t changed profiles from what we set at installation). Let’s say for example the largest size of processed image is 2560px, and then 1280px, 1920px, 960px, 640px, 320px. Image quality settings are user defined from 0-100. Let’s say for arguments’ sake the resized images are fairly well optimised by this but could be further optimised further down the process (see 7 below).
- Original uploaded image remains untouched (and is generally not used in public-side theme).
- User can crop, rotate, colorise, greyscale, sharpen, whatever the 2560px image (all doable in Intervention Image). New versions of the set of smaller images are then remade.
- User can reset the image back to a 2560px version of the original at some point in the future, because the original upload is still there in the file system. Useful for if you change theme or make a complete pig’s ear of editing the images.
- User can optionally offload the images directory to a cloud/CDN service using tools that are already built into the package we would be using.
- User can then optionally run an optimisation tool of their choice, either manually, as a server-based tool, Textpattern plugin, third-party API, whatever, on the images directory – wherever that images directory is housed. No opinionated tool to do that is supplied by us in the core, since there are so many satisfactory ways to achieve that already.
Offline
Re: Multiple image handling: profiles
phiw13 wrote #325160:
Hmm. Image optimisation is a serious problem. How “bad” are those tools at producing decently sized images?
In short, GD that comes with PHP is average at doing it (but better in recent years/PHP releases), ImageMagick is much better as standard. The package we would be using detects whether the server has ImageMagick installed and uses that in preference to GD anyway, if available.
Offline