Feature request: Support for WEBP as a possible `extensionTypes.ImageFormat` option

[hicallmeal]

Request motivation

I use captureVisibleTab frequently and I often use a low quality, JPEG, capture to reduce the size for follow up operations (image processing / messaging) for performance reasons.

I've had to stop using low quality JPEG for quality reasons, and thought - wouldn't it be nice to be able to use WEBP instead, given its inherent benefits over both PNG and JPEG (reduced size at the same quality, optional quality adjustment).

I looked through Chromium and Firefox source codes and both could (in my naive opinion) fairly easily support it.

It doesn't seem like WebKit could, as if Canvas.toDataURL with WEBP isn't supported in WebKit, then this likely wouldn't be either, as I imagine this and the above are related to some degree.

Pros

• Inherent benefits that come with WEBP
• This change wouldn't (or shouldn't, at least) break any extensions

Cons

• Introduces new inconsistency
• Not supported in WebKit
• May become redundant as newer image formats (AVIF, JXL) are being implemented and may find their ways in to APIs

Conclusion

It would be a nice-to-have feature, but I can see and would understand why vendors would be unsupportive.
Nevertheless, I'm interested to hear thoughts.

Follow-up - Are vendors open to supporting newer formats (as described above) in the future?

[hicallmeal]

Leaning towards Off-Topic, but I just realised it'd also be nice to get the raw bitmap as well.

• Reduces processing (for what is a large image)
• Can still be quickly sent, as a transferable

[hicallmeal]

Just going by #947 I decided to take a look at whether support in Webkit is realistic -
Short answer, no.

Looking at supported mimes for encoding here, WebP is only supported for builds that use Skia.
My understanding is that Skia is only used in WebKitGTK (linux).

For Safari, I assume the renderer used is CoreGraphics (CG), which you can see lists

• JPEG
• PNG
• GIF

This is surfaced a few layers up, to here, where for an unsupported mime, PNG is used. (For toDataURL, in particular).

A cursory search found that there haven't been requests for support (e.g. for the above API).
My understanding/assumption is WebP encoding isn't intended to be supported in Safari.

---

That all being said, if FF and Chrome vendors are still supportive, I'd be happy to open bugs and submit patches.
Given the above, I think this issue is better closed.

In the instance where JXL is propsed, etc; for optimal feature detection, all platforms should probably surface extensionTypes or ImageFormats.
At the moment, it looks like only Firefox does.

This comment made me reflect on why I sought after WebP - performance -> processing - and I realised perhaps supporting a different output (behind a flag) would be better.
E.g. Blob or Bitmap

That's out of scope for this issue, but if there's initial interest, we can close this and I can open a new issue?

[Rob--W]

In Firefox we could support webp as an export format, but the question I have is: why?

If extensions want to export as webp, what stops them from using a canvas or OffscreenCanvas to convert the png (a lossless format) to webp?

[hicallmeal]

@Rob--W

My apologies, the request isn't very clear any more, but the crux of it is

[..] made me reflect on why I sought after WebP - performance -> processing - and I realised perhaps supporting a different output (behind a flag) would be better.
E.g. Blob or Bitmap

One part of my extension is captureVisibleTab -> extract specific portion, as image data. Until recently I also sent the capture via sendMessage.

These operations - sendMessage, imageData extraction - become bottlenecks when trying to quickly process data (and for my ext, these are user-visible actions)

I'm talking in the ms level, so nothing like second delays, but it can still be apparent sometimes, especially less powerful devices.

Webp was my initial suggestion as it would take less time to sendMessage a webp image, and less time to convert to imageData, given its size. I think internal decoding would possibly quicker too.
And it has adjustable quality too.

So I agree with OffscreenCanvas, etc, my issue is more to do with reducing bottlenecks when using captureVisibleTab.