Bug 216943
| Summary: | Chroma subsampling based on encode quality | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Micah <micah.millereshleman> |
| Component: | Canvas | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | dino, sabouhallawa, sam, simon.fraser, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 14 | ||
| Hardware: | Mac | ||
| OS: | macOS 10.15 | ||
Micah
Hi,
One unresolved browser inconsistency in the Canvas API is how image encoding quality affects chroma subsampling.
In Firefox, chroma subsampling is turned off at quality >= 0.9, allowing crisp images to be exported from Canvas at relatively small file sizes (e.g. quality 92%). Chrome & Webkit only disable chroma subsampling at quality == 1.0 (100%), meaning that it's impossible to export a crisp canvas as a JPEG without also exporting a massive image.
I work at an online photo editor, and it means that we recommend Safari users save their images at 100% quality, and then use a different program to compress them (w/out chrome subsampling) before using them on a website. Other online photo editors bypass the browser altogether and load their own version of libjepg in WebAssembly. This seems a bit heavy-handed, and it'd be great if the browser default for Canvas produced images that were ready to use on the web.
Chrome recently opened a WHATWG issue for this, and it'd be great to hear from Safari.
https://github.com/whatwg/html/issues/5395
Improving this small corner of the web platform would make Safari a better platform for our users. Thanks!
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/69660091>
Micah
Any thoughts on this? It'd be great to hear from the Webkit team. Thanks!