Multiple image handling: profiles

giz · 2020-08-04 18:35:53

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!

giz · 2020-08-04 19:37:43

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

giz · 2020-08-04 19:51:38

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

Vienuolis · 2020-08-05 05:42:57

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)

zero · 2020-08-05 08:51:55

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.

Bloke · 2020-08-05 09:25:59

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)

phiw13 · 2020-08-05 09:27:06

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.

philwareham · 2020-08-05 09:43:30

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.

philwareham · 2020-08-05 09:55:08

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.

Bloke · 2020-08-05 09:56:38

philwareham wrote #325162:

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

Yes, or we write a cunning wrapper around Intervention’s API to offer on-demand resizing and caching to either the local image store or cloud/CDN service. In other words, do something along the lines of what slir does but we control what parameters are exposed and how the resulting images are named/referenced.

I’ve not delved into all the stuff that Intervention offers yet. But I can see something like I posited earlier of using <txp:images> to first ask for the cached version of any requested image and, if it’s not there, generate it on-the-fly and cache it. Depends largely on performance as we test this.

Core’s Images panel would/could do exactly the same process so we don’t need to make pre-defined versions “just in case”. We make one size (the dimensions of which we hardcode in core as appropriate) based on whether the user is viewing grid or list. If they switch, we generate another size at that time to support that view.

Worst case scenario is that we generate 96 images in one go if you flick from list to grid with max paging (I suppose there could be more if a plugin has extended this max value). But I’m interested to know how lazy loading interacts with Intervention. Since we now only fetch images as the user scrolls, that might mean we can generate/cache them as people scroll too, which cuts down on the processor load of generating them all at once. Of course, once generated, then it’s just a cache read so it’s a one-off process per page of results.

Lots of fun to be had here.

Last edited by Bloke (2020-08-05 10:00:09)

Vienuolis · 2020-08-05 10:01:04

Is PHP Tinify library third-party dependent? It seems to me API only is, although I am not a programmer, sorry. Its PHP code is published on GitHub.

I don’t think Panda holds some monopoly for quantization techniques — Cloudinary works in similar way. Maybe PHP GraphicsMagick module is also capable to quantize graphics?

Weired, I do not know any similar desktop app. I mostly use PNGOUT and RIOT (Radical Image Optimization Tool) plug-ins for IrfanView — both work fine, but only degrading image quality.

Last edited by Vienuolis (2020-08-05 10:15:20)

Bloke · 2020-08-05 10:20:00

Vienuolis wrote #325165:

Is PHP Tinify library third-party dependent?

Yes. You install the PHP library as a convenience to access their online service. And you need an API key to do so, which is an additional user hurdle.

I do not know any similar desktop app.

Although it doesn’t optimize per se, even Mac’s built-in Preview application does a wickedly good job at resizing images and retaining quality – it far outstrips GD’s attempts.

And if you want to squeeze more bytes out without altering quality, there’s Exifpurge which strips out all the junk camera metadata (assuming you’re not using it for cataloguing purposes!).

Last edited by Bloke (2020-08-05 10:23:50)

Textpattern CMS

Textpattern CMS support forum

#37 2020-08-04 18:35:53

Re: Multiple image handling: profiles

Bloke wrote #325112:

#38 2020-08-04 19:37:43

Re: Multiple image handling: profiles

Bloke wrote #325127:

#39 2020-08-04 19:51:38

Re: Multiple image handling: profiles

#40 2020-08-05 05:42:57

Re: Multiple image handling: profiles

philwareham wrote #325147:

#41 2020-08-05 08:51:55

Re: Multiple image handling: profiles

philwareham wrote #325147:

#42 2020-08-05 09:25:59

Re: Multiple image handling: profiles

#43 2020-08-05 09:27:06

Re: Multiple image handling: profiles

philwareham wrote #325147:

#44 2020-08-05 09:43:30

Re: Multiple image handling: profiles

#45 2020-08-05 09:55:08

Re: Multiple image handling: profiles

phiw13 wrote #325160:

#46 2020-08-05 09:56:38

Re: Multiple image handling: profiles

philwareham wrote #325162:

#47 2020-08-05 10:01:04

Re: Multiple image handling: profiles

#48 2020-08-05 10:20:00

Re: Multiple image handling: profiles

Vienuolis wrote #325165:

Board footer