This is my periodic post that it was a huge mistake for Google to drop JPEG XL support and they should've gone forward with it.
Trying to compress images corresponding to an HTML file, and ideally I want the compression to not lose any quality, but I have to use AVIF because no modern web browser supports JPEG XL. Had I used JPEG XL this could've been lossless. #jxl #jpegxl
(Edit: Technically, Safari will support JPEG XL, but that's still not broad enough as most people still use Chromium)
I've been playing with image formats for the past couple hours and was surprised to find #JPEGXL performing worse than I expected on digital artwork.
It still beat plain #JPEG , but was competing more against #WebP than #AVIF at a similar size, whereas it's normally touted as beating WebP and competitive with AVIF on quality (and beating it in features). Maybe JPEG XL has been tailored more for photos than digital artwork?
I want to thank, Apple, for supporting, JPEG XL, in their Safari web browser. Additionally, Mozilla Firefox, has been including JPEG XL, for a while now (in Nightly).
But Google, who originally supposed the project, tried to shut it down
Apple is not only adding support for JPEG XL to their web browser, but their whole operating system. Their programs and devices will all support, JPEG XL. They join along with Linux distros, who also are adding support
Thank you, Apple
Google May Reconsider JPEG-XL Image Support Within Chrome
»The latest update on the ticket this morning reads:
Setting status to untriaged and requesting someone from respective dev team to look into this for further updates.«
Zdaje się, że się starzeję, bo patrzę na łatkę dodającą wsparcie #Brotli na liście bug-tar, i myślę sobie, że powinniśmy bojkotować ten algorytm.
Brotli nie jest w żaden sposób wybitne. Jasne, jest nieco skuteczniejsze niż gzip — toż to osiągnięcie, pobić algorytm z początku lat 90-tych! Dzisiaj natomiast mamy już zstd, które jest po prostu lepsze.
Brotli istnieje jako opcja kompresji HTTP tylko za sprawą #Google. Tak, tego samego złego monopolisty, który zaimplementował DRM w swojej przeglądarce internetowej (żeby chronić reklamodawców!) i zablokował format #JPEGXL.
Nie zapominajmy też o #snappy, innym algorytmie kompresji z Google Open Source, prawdopodobnie najbardziej znanym z tego, że autorzy odrzucają łatki wykraczające poza "kilka wspieranych konfiguracji używanych wewnątrz Google" (tłum. własne).
I guess I'm getting old because I'm looking at the brotli support patch to bug-tar, and I honestly think we really should boycott #brotli.
Brotli doesn't really excel at anything. Sure, it apparently fared better than gzip — outperforming a format from early 1990s is a great achievement! However, today we have zstd and it simply is better.
Let's also not forget #snappy, another Google Open Source compressor, probably best known for refusing fixes that go outside "a few supported configurations inside Google".
I was so impressed by how easily new image formats were added to the #Evolution #email client in the past, that I'm now suggesting #JPEGXL support in @EvolutionGnome since the latest #WebKitGTK and #GNOME 45 ships with that file format enabled by default 😉 #opensource https://gitlab.gnome.org/GNOME/evolution/-/issues/2451
A list of recent hostile moves by #Google's #Chrome team; handy for sharing with your entourage, to explain why they should stop using #Chromium / #GoogleChrome and use #Firefox or #Epiphany as their main #web #browser :
* The "Manifest v3" sabotage of content blocking extensions: https://www.theverge.com/2022/6/10/23131029/mozilla-ad-blocking-firefox-google-chrome-privacy-manifest-v3-web-request
* The attempted sabotage of #JPEGXL: https://www.cnet.com/tech/computing/chrome-banishes-jpeg-xl-photo-format-that-could-save-phone-space/
* #WebEnvironmentIntegrity a.k.a. #DRM for whole websites would hurt the web, #opensource browsers and OSes: https://arstechnica.com/gadgets/2023/07/googles-web-integrity-api-sounds-like-drm-for-the-web/
As @kdwk revealed, the "Canary" and "Technology Preview" versions of #Epiphany + #WebKitGTK 2.42, which will become #GNOME #Web 45, now support the #JPEGXL #JXL image format by default: https://www.reddit.com/r/gnome/comments/155lt33/introducing_jpegxl_support_in_the_gnome_ecosystem/
It looks like #GNOME is ready to embrace #jpegxl into its ecosystem! Wallpapers are being switched to JXL from WebP, & GNOME Web will adopt JXL support through WebKitGTK. The GNOME SDK is also going to be built with libjxl from now on!
The slow march of *widely* displacing JPEG with #jpegxl continues:
Safari Technology Preview 174 mit neuen Funktionen und Bugfixes
Apple hat die neueste Version von Safari Technology Preview veröffe
This may be an unfounded accusation, but the fact is that over time @mozilla has been progressively less supportive for the #indieWeb, #openWeb, and open standards. There are innumerable examples of this, but my pet peeves are: removal of native support for #RSS (and Atom) feeds, removal of the Live Bookmarks feature without an official extension to replace it, lack of support for #MNG, and now the reticence in making #JPEGXL support official.
Safari Technologie-Preview 173 zeigt Funktionen aus macOS Sonoma
Mit dem Update auf macOS Sonoma kommt auch Safari 17, das Verbesserungen für den Webbrowser von Apple mitbringt. Wer die neu
#Mac #News #HEIC #LiveText #MacOSVentura #MacOSSonoma #SafariTechnologieVorschau #ExperimentelleFeatures #Apple #Webentwicklung #JPEGXL #Installation #ResponsiveDesignModus #Webbrowser #FeatureFlags
I'd love to do the same with #JpegXL BTW but
(1) I don't have images on my website, other than the logo
(2) not even Firefox has official support for the format yet 8-(
I know most people probably don't care about the politics of image formats... but please vote for #JPEGXL in #Firefox. Its good, you'll like its higher quality and replacement of older #jpeg when it's available.
Apple is implementing JPEG XL support in Safari 17 while Chrome is dropping support due to a perceived lack of interest (despite major public support for the codec)? This continues to be the strangest timeline 🤔
If you've never heard of JPEG XL before, this site hits all the highlights about why it's such a great codec to replace JPEG (and a lot of other codecs too...): https://jpegxl.info/why-jxl.html
I'm generally not a big fan of #Apple (understatement of the century), but I've read about the next version of #Safari officially supporting #JpegXL and I'm really glad that this is happening. I'm looking forward to the associated changes to #WebKit making it into the engine as it is used by other #FLOSS browsers too —and hopefully this will finally push @Mozilla into enabling #jxl in mainline #Firefox OOTB.
The Google Chrome team rejected JPEG XL image support, but the next Safari adds it. Along with, somewhat surprisingly given patent constraints, HEIC. Perhaps easier for Apple since they build support into the OS so no extra licensing hurdles.
(edited to fix a missing word)
I just realized that #Google killing #JpegXL has a direct negative impact on the #Fediverse, by imposing higher bandwidth and storage requirements for anyone hosting media. Platforms like #PixelFed in particular would greatly benefit from being able to transcode everything to #jxl for storage (with no additional loss of quality thanks to the possibility to transcode directly from #jpeg in most cases), reducing storage and bandwidth by 10% or more, easily.
(And yes, that was really aimed at @mozilla as an invitation to bring back #RSS support in #Firefox, and to openly promote #JpegXL instead of keeping it hidden in @FirefoxNightly, and more in general to go against everything that #Google's chokehold on the web currently represent. Support user choice instead of crippling it. Prove that you are different.)