From http://caniuse.com/#search=jpeg2000, Safari is the only browser which supports JPEG2000. Because no other browser is adopting JPEG2000, then there's no real reason for WebKit to keep exposing it.
<rdar://problem/35161822>
Created attachment 324771 [details] Patch
This seems like this should be runtime configurable for clients of the WebKit API that want to continue supporting JPEG2000.
(In reply to Sam Weinig from comment #3) > This seems like this should be runtime configurable for clients of the > WebKit API that want to continue supporting JPEG2000. And not drop support for clients that linked against a version of WebKit hat had support.
(In reply to mitz from comment #4) > (In reply to Sam Weinig from comment #3) > > This seems like this should be runtime configurable for clients of the > > WebKit API that want to continue supporting JPEG2000. > > And not drop support for clients that linked against a version of WebKit hat > had support. I filed https://bugs.webkit.org/show_bug.cgi?id=178821.
This is causing web compat issues for other ports, see bug #180995
(In reply to Said Abou-Hallawa from comment #0) > From http://caniuse.com/#search=jpeg2000, Safari is the only browser which > supports JPEG2000. Because no other browser is adopting JPEG2000, then > there's no real reason for WebKit to keep exposing it. Also bug #186272 I think we will have to add JPEG2000 support to GTK and WPE (not really desired) unless Safari drops it.
We saw washingtonpost.com uses JP2000 images recently. So I think it is okay to keep the support for now and not to fix this bug.
Well a *lot* of websites are (or were recently) sending JP2000 images (dell.com, kmart.com, I think perhaps amd.com (though this one is sending weird PNGs too so not certain). It's a significant web compat issue for us right now. We need to either: (a) Remove support from Safari, temporarily breaking these websites in Safari (b) Add support to WPE/GTK We had been expecting you to do (a), so if that's no longer the plan, we'll need to work on (b).
Adrian discovered every instance of JPEG 2000 images I'm aware of are on websites using Akamai Image Manager. This affects both images with the .jpg extension and also .png; the images seem to be reencoded without changing the filename. It only sends JPEG 2000 images for websites that include Safari without Chromium in the user agent. We currently intend to implement support for JPEG 2000, but if Apple still wants to remove it, probably working with Akamai Image Manager would be the first step. Sample JPEG 2000 images: https://www.angieslist.com/sites/all/themes/altheme/images/home-hero-overlay.png https://www.amd.com/system/files/styles/992px/private/65942-ryzen-threadripper-pib-ces-front-facing-1260x709_4.png https://i.dell.com/sites/csimages/Banner_Imagery/all/25957-laptop-inspiron-14-5481-desktop-3670mt-monitor-d3218hn-2800x944.jpg https://www.akamai.com/us/en/multimedia/images/article/akamai-image-manager-overview-image.jpg?imwidth=1366
Repurposed bug #186272 to implement JPEG 2000 for non-Apple ports. (If Safari will be removing JPEG 2000 support, please let us know so we don't have to do this!)
Any chance of Apple removing JPEG2000 from WebKit? Recently we have run into two issues (bug #244528 and bug #244529) and I would rather remove the code than fixing it, giving the marginal usage the format has. From the links mentioned by Michael in comment 10, the ones which still load no longer serve JPEG2000 images. The IKEA website was also serving JPEG2000 to WebKit based browsers at some point, but as far as I can see it seems to be using WebP these days.
Pull request: https://github.com/WebKit/WebKit/pull/3824
Committed 273978@main (78cb9d96aa82): <https://commits.webkit.org/273978@main> Reviewed commits have been landed. Closing PR #3824 and removing active labels.