Open aerni opened 6 years ago
Wow, you're really keeping me busy here!
Sounds like a decent FR, though the downside is that the server might fill up quite fast depending on the number of images used on the site.
With Statamic's presets you have exact control of the number of variants that are being created, however with ResponsiveImg it'll automatically decide based on the original image width (and scale down until tiny) meaning potentially 10+ versions per image.
I think this should go hand-in-hand with a global setting to control the scaling down % and a max width size.
Yeah, hope to not keep you too busy 😉
Yes I know. A lot of assets that have to be generated and cached. In my current implementation the assets.yaml
looks like this:
# Square Image Presets
400x400:
w: 400
h: 400
q: 80
800x800:
w: 800
h: 800
q: 80
1000x1000:
w: 1000
h: 1000
q: 80
1200x1200:
w: 1200
h: 1200
q: 80
1600x1600:
w: 1600
h: 1600
q: 80
2000x2000:
w: 2000
h: 2000
q: 80
# Hero Image Presets
375x600:
w: 375
h: 600
q: 80
750x1200:
w: 750
h: 1200
q: 80
800x1000:
w: 800
h: 1000
q: 80
1000x700:
w: 1000
h: 700
q: 80
1400x980:
w: 1400
h: 980
q: 80
1800x1260:
w: 1800
h: 1260
q: 80
2000x1400:
w: 2000
h: 1400
q: 80
# Image/Slider Presets
2500x1650:
w: 2500
h: 1650
q: 80
2000x1320:
w: 2000
h: 1320
q: 80
1800x1188:
w: 1800
h: 1188
q: 80
1600x1056:
w: 1600
h: 1056
q: 80
1400x924:
w: 1400
h: 924
q: 80
1200x792:
w: 1200
h: 792
q: 80
1000x660:
w: 1000
h: 660
q: 80
700x462:
w: 700
h: 462
q: 80
# Inline Image
400:
w: 400
q: 80
600:
w: 600
q: 80
800:
w: 800
q: 80
1000:
w: 1000
q: 80
1200:
w: 1200
q: 80
1400:
w: 1400
q: 80
What happens if you turn off the cache?
Ah right, looks like in your case you were already generating a lot of versions -- it'll work similarly then.
Caching is required for the inline SVG to be generated (blurred image). For the addon to create a tiny, base64-encoded version of the image, the physical file needs to exist on the server, that's what the cache does.
Though honestly, that setting should always be on in my opinion -- if you disable it, you'll force Statamic to do a LOT of work for each user that visits the site because it will keep regenerating the image on the fly vs. deferring to a cached file on the server. This ensures your server doesn't get overworked and speeds up load times for users.
Yes, I agree. Caching should be on. Would be great to have a php please …
to generate the cache. I'm looking forward to see your implementation.
Yeah, a php please
command for this would be 👌
I think also a button to trigger the command from the global settings page (once it exists).
FYI: I'm not sure when I'll be able to work on this feature, but you'll be notified of any updates here!
If this is implemented, it would actually make a lot of sense to add true image compression. That way the pre-generated images have the smallest possible file size.
Glide is not very good at that, jpg images at quality 75 already look blurry. Using serverside compression libraries the results would be MUCH better.
What I mean is, integrating for example https://github.com/spatie/image-optimizer
PS: That would also solve the other issue regarding all images are converted into JPGs atm... Then images could stay whatever format they had before, and alternatively maybe have an option to convert the final image to .webP for max compression.
This addon requires
image_manipulation_cached: true
. Because the cache gets generated the first time an image is viewed, it is possible to run into a server timeout. Especially if you have a lot of new images on a page. There should be a way to generate the assets cache in advance. With Glide you can just callphp please assets:generate-presets
.