Closed Bug 1511670 Opened 6 years ago Closed 3 years ago

Implement WebP image encoder

Categories

(Core :: Graphics: ImageLib, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
96 Branch
Tracking Status
firefox96 --- fixed

People

(Reporter: jbeich, Assigned: ulima.ums)

References

(Depends on 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(2 files, 5 obsolete files)

See bug 1294490 comment 123.

Steps to reproduce:
1. Open http://html5test.com/
2. Navigate to "Image export formats"

Expected result:
- WebP support: Yes ✔

Actual result:
- WebP support: No ✘
See: bug 1294490 comment 124.

IMO this is a bug in html5test's detection routines by requiring encoding capabilities as a measure of decoding capabilities. This isn't a bug in the browser.
I wonder if YouTube uses Canvas for generating animated preview thumbnails.

(In reply to Mark Straver from comment #1)
> requiring encoding capabilities as a measure of decoding capabilities

HTML5Test defines the feature as "export" (i.e., "encoding") and cites compositing/blending API in Canvas2D. Where did you get the idea about decoding-only?
attachment 770546 [details] [diff] [review] has WebP encoder but after playing in Waterfox[1] it appears to be a stub/unfinished - not usable with real consumers.

[1] https://github.com/MrAlex94/Waterfox/pull/514
I'm sorry if I misunderstand what capabilities are requested by the html5 standard. Isn't the goal of this about *decoding* support only, i.e. being able to decode and display images in specified formats on websites, and therefore a test for encoding to specific image formats is testing the wrong thing to determine whether an image format is supported?

html5test.com seems to equate "image format support" with "encoding support", possibly because of the easier detection method when doing it that way. I think that's incorrect. The compositing/blending API also doesn't specify anything in its spec with regard to what image encoding formats should be supported, so in what way is this a test of "how well the browser supports html5"?
Flags: needinfo?(aosmond)
Priority: -- → P3
This will definitely not make it in time for 65. I need to evaluate this for later releases.

Ultimately this is a request to implement an image encoder for WebP. This isn't a high priority right now, but I'll leave the bug open.

Flags: needinfo?(aosmond)
Summary: html5test.com fails to detect WebP support → Implement WebP image encoder
Type: defect → enhancement
Depends on: 1502423
Assignee: nobody → ulima.ums
Status: NEW → ASSIGNED
OS: Unspecified → All
Hardware: Unspecified → All

Depends on D126300

Attachment #9242384 - Attachment description: Bug 1511670 - Adding required files for encoding webp. r=aosmond → Bug 1511670 - Part 1. Adding required files for encoding webp. r=aosmond
Attachment #9242384 - Attachment description: Bug 1511670 - Part 1. Adding required files for encoding webp. r=aosmond → Bug 1511670 - Adding required files for encoding webp. r=aosmond

Depends on D126301

Depends on D128019

Depends on D128020

We are evaluating to use webp to store thumbnails in the profile folder, do you have an ETA for this work?

Flags: needinfo?(aosmond)

The patch is ready to be reviewed. I am waiting for aosmond for approval

Depends on D130547

Pushed by aosmond@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/efdcc9ec0feb
Adding required files for encoding webp. r=aosmond
https://hg.mozilla.org/integration/autoland/rev/be7dd657bae3
Add WebP image encoding support. r=aosmond
Attachment #9242384 - Attachment is obsolete: true
Attachment #9242385 - Attachment is obsolete: true
Attachment #9245131 - Attachment is obsolete: true
Attachment #9245132 - Attachment is obsolete: true
Attachment #9245133 - Attachment is obsolete: true

This will be in Firefox 96.

Flags: needinfo?(aosmond)
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 96 Branch

I am not sure what all the places in the web-platform that expose image encoding are, but HTMLCanvasElement.toDataURL is at least one of them.

Keywords: dev-doc-needed
Regressions: 1740000

The FF96 docs work for this can be tracked in https://github.com/mdn/content/issues/10853

My understanding of this is that that it essentially creates an encoder that can turn generate WebP images from images in other formats. I also understand that this is used by HTMLCanvasElement.toDataURL() to allow you to generate WebP images.

  • Why would you want to do this?
    My guess would be if you wanted to provide a drawing app or similar in a canvas you could use it to provide a mechanism to export the image as WebP. Further, I presume that you might use it to export an image that you could later simple import as data into the canvas rather than downloading it (although I don't know why you would want to do this).
    Are there any other reasons?

The job as it is now is to push the compatibility info into browser compatibility data - along with the data for chrome (any idea when its support for WebP went in?). I would also need to remove that in-text data about chrome support from the doc HTMLCanvasElement.toDataURL().

  • Is there any way to work out where this is used or anyone I can ask? Without that I can't do much more.
    I am pretty sure it is used in HTMLCanvasElement.toBlob.
Flags: needinfo?(ulima.ums)

Sorry for the late reply. Yes, this patch just adds another image encoder. It can be used by canvas.toDataURL() or canvas.toBlob(). I am not aware of any other uses.

I stumbled across this because I created a whiteboard web app and didn't want to upload big png files whenever someone dropped them on the canvas. So I converted them to webp which drastically reduced my traffic. I encountered the same problem in a different project. For me it was always about the size of the uploaded images.

A different use case could be that you created some image on a canvas and want to save it but png is too big and jpg has no transparency

Flags: needinfo?(ulima.ums)

Thanks @ulima.ums! FYI only, this also allows webp to be used in OffscreenCanvas.toBlob() (this is behind a preference).

Why isn't there a quality/compression setting implemented, like there is for jpg?

AFAICS, it's compression level is now something like 93%.

See:
https://stackoverflow.com/questions/70709171/how-to-set-compression-quality-for-webp-encoding-in-firefox
https://searchfox.org/mozilla-central/source/dom/canvas/CanvasRenderingContextHelper.cpp#264

Depends on: 1750475

Thanks. I filed bug 1750475.

Regressions: CVE-2022-1919
Regressions: 1784835
Duplicate of this bug: 1559743
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: