XF 2.3 Image optimization, enhanced image resizing, and more!

Screenshot 2023-10-11 at 00.59.50.png
We hope you're enjoying the "Have you seen...?" series for XenForo 2.3 so far. We still have quite a bit more to show you while we work on adding the last finishing touches before we unleash XenForo 2.3 on this very forum.

This week we're going to talk about various improvements we have made which are mostly focused around images.

Check out the index below to skip to a specific post:
To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

While that is all for this week, we continue next week! We will be focusing on only a single new feature next week, it is a doozy and we're excited to hook you even further into the exciting world of XenForo 2.3 🌎🪝
 
Tell me, if we use s3, will there be any problems? using this plugin?

A few years back I ran a WP bulk image optimisation plugin which proceeded to read/write several thousand files to/from S3 overnight. Got a nice big AWS bill that month.
 
A few years back I ran a WP bulk image optimisation plugin which proceeded to read/write several thousand files to/from S3 overnight. Got a nice big AWS bill that month.

If you're going to bulk process files stored in S3 you're 100% better off starting up a temporary EC2 instance within the same region as your S3 bucket and running the process from that EC2 instance as you pay no data transfer costs for data within the same AWS region. Could process hundreds of terabytes of data with the only additional cost being for whatever tier of EC2 instance you're running it on
 
And the next one’s?
Back to normal. Actually I just checked and it was an Amazon Cloudfront bill of $480.03, not AWS.

Edit: Unbelievably enough they wrote it off when I contacted them.

ANYWAY to stay on topic - it could be something to bear in mind if someone were to be considering converting a lot of image files.
 
on demand media conversion would have been nicer (images converted on the fly as they are first called from old posts). would have worked better on low end hosting accounts as well. but i guess addon developers have a lot of potential to offer customized addons for webp functionality! one feature definitely would be to have different compression options for gallery and forum. should be interesting once this is out in the wild!
 
Back to normal. Actually I just checked and it was an Amazon Cloudfront bill of $480.03, not AWS.

Edit: Unbelievably enough they wrote it off when I contacted them.

ANYWAY to stay on topic - it could be something to bear in mind if someone were to be considering converting a lot of image files.
I expected that next S3 bills gone down after the conversion.
 
With this being a rather intensive and lengthy process, if you'd prefer to run this without the risk of browser timeouts and supervision, you can also use one of the built in commands:

Code:
xf-rebuild:attachment-optimization
xf-rebuild:avatar-optimization
xf-rebuild:profile-banner-optimization
Can these commands take advatange of multiple CPU cores, eg. support --processes like for imports?
 
We will now track these sizes within the embed_metadata field of the content and to a certain extent, can rebuild that information when the "Post embed metadata" rebuild is run against existing content (if the dimensions have been stored by the image proxy).
Do we need to keep the image proxy enabled to do this or can we turn it OFF when the rebuild is done to have the dimensions added?
 
On upload, all currently supported image types (except GIFs) will be saved to WebP format.
Is there some reason not to convert GIFs also to webp (which as far as I know supports animations)? 🤔

Or alternatively, converting them into some video format that takes a lot less space? :)
 
Converting to an alternate format, like video, requires FFmpeg which is probably a step too far in the general case.

Turns out GIF to WebP is possible, I was just experiencing issues with it while I was developing this. I think @Jeremy P is/has sorted that though.
Converting animated images (or compressing them) will often massively degrade the quality; if animated conversion support is added, please make it optional.

I have personally had to make 600+ animated gif for one site, and having their quality degraded would mean almost a thousand hours of work would have to be re-done, or completely done away with.
 
Converting animated images (or compressing them) will often massively degrade the quality; if animated conversion support is added, please make it optional.

I have personally had to make 600+ animated gif for one site, and having their quality degraded would mean almost a thousand hours of work would have to be re-done, or completely done away with.
Here's an example of a GIF uploaded to our forum:
Original GIF @ 2.1MB:

example.gif



Webp (lossy) @ 1 MB: https://ampxf.com/media/user-uploads/example-lossy.webp
(It seems Xenforo doesn't allow attaching webp images yet...)



MP4 @ 269 kB (This is for example what Imgur / Giphy does to serve "gifs"):

MP4 can be made to behave like GIFs with autoplay, loop, and mute on the <video> element. (example can be seen by inspecting source at Giphy link)

I don't really see any markable difference between the GIF/WEBP/MP4, but there is a significant decrease in size...
 
Here's an example of a GIF uploaded to our forum:
Original GIF @ 2.1MB:

View attachment 292681


Webp (lossy) @ 1 MB: https://ampxf.com/media/user-uploads/example-lossy.webp
(It seems Xenforo doesn't allow attaching webp images yet...)



MP4 @ 269 kB (This is for example what Imgur / Giphy does to serve "gifs"):
View attachment 292682
MP4 can be made to behave like GIFs with autoplay, loop, and mute on the <video> element. (example can be seen by inspecting source at Giphy link)

I don't really see any markable difference between the GIF/WEBP/MP4, but there is a significant decrease in size...
The images in question can run from 13 to 25 frames (long animations), and are about 5-10mb each.

Converting to webp causes noticeable grain, and optimizing to webp adds more grain; that said it is better than gifsicle so I will have to see if I can make things work.
 
The images in question can run from 13 to 25 frames (long animations), and are about 5-10mb each.

Converting to webp causes noticeable grain, and optimizing to webp adds more grain; that said it is better than gifsicle so I will have to see if I can make things work.
Maybe a semi-automatic conversion can be a solution? For example: lists in the backend all the gifs (sorted from bigger in size), select like 20 of them and "preview convert", pick the previews you like to confirm the conversion.

In this way you don't have to convert all if some of them as too grain and you can free up a lot of disk space.

For new uploads maintain gifs and do this semi-auto conversion like once a month.
 
That deals with future uploads, but, many of you will be wondering how to optimize existing files. So you'll be pleased to hear that you are able to rebuild all of your existing attachments, avatars and profile banners automatically.
Does the rebuild process change xf_attachment_data.file_hash?

Although users shouldn't do that, I am sure there could be a dozen posts when users embedded thumbnails via [IMG].

So if xf_attachment_data.file_hash ist changed, this would also change the URL of attachment thumbnails and break those embedded images.

If it is not changed but the files are modified, this could cause issues with deduplication.
 
Top Bottom