Add webp to supported attachment file types

[tooki]

Could we add webp to the list of allowed file types? Increasingly, websites are serving webp images dynamically even when requesting another image format (e.g. the URL is …/thing.png or .jpg but you actually receive the webp instead), which gets annoying when trying to save them to then attach. (Especially when doing it on mobile, where I don’t normally have an image format conversion tool handy.)

Thanks!

[ledtester]

If you have a .jpg file that's really a WebP image, it'll work just fine.

If you have an image with a .webp suffix, just change the suffix to .jpg.

Browsers now look at the actual image data to determine how to render it.

But it wold be nice not to have to change any file names in order to use them on the forum.

Here's a WebP image from Google's example gallery - I just changed the .webp sufix to .jpg.

https://developers.google.com/speed/webp/gallery1

Note that the size is 59K so it's not the JPEG version.

[5U4GB]

As a local workaround you can also get a Chromefox extension, "Webp / Avif Image Converter", that saves webp files in a more standard format like JPEG that everything understands.

[tooki]

If you have a .jpg file that's really a WebP image, it'll work just fine.

If you have an image with a .webp suffix, just change the suffix to .jpg.

Browsers now look at the actual image data to determine how to render it.

But it wold be nice not to have to change any file names in order to use them on the forum.

I know that, but it doesn’t really solve the issue.

Unfortunately, changing the file extension isn’t an option when it’s just saved to the device photo album, especially on mobile.

Typical workflow: browsing to research a post, find relevant image, tap and hold > Save to Photos. Keep browsing and saving images. Write post, go to attach file, choose Photo Library as source, select the photo, and only then get the message that it’s a damned webp. By then I’ve long since navigated away from the source web page.

Yes, it is possible to export the original image from the Photo Library and then deal with it from there. But it’s just a whole lot of steps that simply shouldn’t be necessary by now; webp has proven it is not some passing fad.

It also just grosses me out to deliberately give a file the wrong extension!

I’m not looking for workarounds (I already know them), I’m asking for the forums to be updated to obviate the need for such a workaround.

[tooki]

As a local workaround you can also get a Chromefox extension, "Webp / Avif Image Converter", that saves webp files in a more standard format like JPEG that everything understands.

Yep, and there’s even an equivalent extension for Safari on iOS (my primary browsing platform). Unfortunately, by the time I actually learn an image has been saved as webp, it’s far too late.

[5U4GB]

This may be a Windows thing but the save dialog shows files of the same type in the destination directory, so if I save an image and there's 20 others already there it's fine, if there's zero others there it's a weirdo format that I need to save via the image converter, meaning save-as rather than save.

[tooki]

This may be a Windows thing but the save dialog shows files of the same type in the destination directory, so if I save an image and there's 20 others already there it's fine, if there's zero others there it's a weirdo format that I need to save via the image converter, meaning save-as rather than save.

Yep. But alas, not applicable when saving a photo to the device photo library.

[gnif]

Wont happen sorry, SMF is too old to know how to process webp files to generate thumbnails and the likes.
If people are renaming webp to jpeg it would explain why I frequently see errors in the logs regarding failure to parse them.

[tooki]

Wont happen sorry, SMF is too old to know how to process webp files to generate thumbnails and the likes.
If people are renaming webp to jpeg it would explain why I frequently see errors in the logs regarding failure to parse them.

So what if it doesn't know how to thumbnail them, it would still be able to have them as attachments, as it does with non-image files, no?? That would still be far better than nothing.

[PlainName]

Serving up unknown data it a fake format is surely a security nightmare. Akin to renaming .exe to .txt and having downloaders auto running it.

[EEVblog]

So what if it doesn't know how to thumbnail them, it would still be able to have them as attachments, as it does with non-image files, no?? That would still be far better than nothing.

Added as a test. Looks like it defaulted to the full size image instead of the thumbnail.
I don't know about the log gnif is talking about, so yeah, might still be generating a log error that it couldn't generate the thumbnail.

[tooki]

Much appreciated, thanks!

[ledtester]

I think I've figured out how to get webp thumbnails - it could just be a one line addition to the code.

I downloaded and installed version 2.0.19 of SMF. That version uses GD for creating thumbnails and GD has had support for webp for several years so it is very possible that the GD library used on the forum supports webp.

It is very easy to test... just place this .php file on the server (call it foo.php):



and when you access /foo.php you will get output like:

Code: [Select]

(
    [GD Version] => 2.3.3
    [FreeType Support] => 1
    [FreeType Linkage] => with freetype
    [GIF Read Support] => 1
    [GIF Create Support] => 1
    [JPEG Support] => 1
    [PNG Support] => 1
    [WBMP Support] => 1
    [XPM Support] => 1
    [XBM Support] => 1
    [WebP Support] => 1
    [BMP Support] => 1
    [AVIF Support] =>
    [TGA Read Support] => 1
    [JIS-mapped Japanese Font Support] =>
)

and look for [WebP Support] => 1.

If GD has webp support then adding a single line of code will enable it.

Around line 325 in Sources/Subs-Grpahics.php add the green line in the resizeImageFile function:


function resizeImageFile($source, $destination, $max_width, $max_height, $preferred_format = 0)
{
        global $sourcedir;

        // Nothing to do without GD
        if (!checkGD())
                return false;

        static $default_formats = array(
                '1' => 'gif',
                '2' => 'jpeg',
                '3' => 'png',
                '6' => 'bmp',
                '15' => 'wbmp'
                ,'18' => 'webp'
        );


Note that the new line begins with a comma.

What's going on... GD provides several functions to import images from a file: imagecreatefromgif(), imagecreatefrompng(), imagecreatefromjpeg(), etc. The problem is that you have to decide which of these functions to call. To determine that you first call getimagesize() which returns the image dimensions as well as a numeric code indicating what kind of image it is (gif, jpeg, png, etc.) You'll find those numeric codes in the $default_formats table. By adding a new entry for code 18 mapping to 'webp' the SMF code will call imagecreatefromwebp() on webp images.

[EEVblog]

I think I've figured out how to get webp thumbnails - it could just be a one line addition to the code.

I downloaded and installed version 2.0.19 of SMF. That version uses GD for creating thumbnails and GD has had support for webp for several years so it is very possible that the GD library used on the forum supports webp.

We are already running 2.0.19

[ledtester]

Right, so all we need to know is if the GD library (which is part of PHP) has webp support compiled into it. That's what installing that foo.php file and accessing it will tell us.

In fact, I'm sure you can just make the one line addition to the Sources/Subs-Graphics.php file that I indicated. The mod works on my 2.0.19 installation.

There are two possibilities... if your GD library has webp support then getsizes will return 18 for .webp files and everything will just work.

If you GD library doesn't have webp support then it will never return 18 and the additional row in the table will never be accessed.

[EEVblog]

gnif would have the make any changes in this regard, I don't want to touch it.