Google stopt na enkele maanden al met ondersteuning voor JPEG XL in Chromium

Google is van plan het JPEG XL-bestandsformaat uit te faseren uit Chromium. Het bedrijf ziet 'niet genoeg interesse vanuit het ecosysteem' om het relatief jonge bestandsformaat nog langer te ondersteunen.

Google begon in februari van dit jaar met de ondersteuning van JPEG XL. Dat is een nieuw codecformaat voor afbeeldingen, waarmee afbeeldingen veel kleiner kunnen worden opgeslagen zonder veel kwaliteitsverlies. De standaard is onder andere in het leven geroepen voor afbeeldingen als 360-gradenfoto's en panorama's of voor printafbeeldingen. Google gaf aan dat de 60 procent afbeeldingcompressie en de ondersteuning voor hdr en animatie in afbeeldingen in een enkele codec reden waren om de standaard in Chromium te implementeren.

Nu schrijft het bedrijf in een update dat het toch gaat stoppen met de ondersteuning. JPEG XL was vooralsnog alleen via een experimentele flag aan te zetten. "Dat moet niet onnodig blijven gebeuren", schrijft een van de ontwikkelaars van de browser. Die zegt ook dat er 'niet genoeg interesse vanuit het volledige ecosysteem is om met JPEG XL te blijven experimenteren'. Daarnaast zegt de ontwikkelaar dat het nieuwe bestandsformaat 'niet genoeg incrementele verbeteringen van bestaande formaten' bevat om JPEG XL standaard in te schakelen. Door de flag en de code uit Chromium te verwijderen, zouden de ontwikkelaars daar minder werk aan hebben.

Het besluit komt voor veel ontwikkelaars als een verrassing, met name vanwege de reden. In de issuetracker vragen veel gebruikers zich af hoeveel onderzoek Google heeft gedaan naar het gebruik, aangezien JPEG XL nog amper praktisch bruikbaar is. Veel bedrijven zoals Adobe of Facebook hebben al gezegd naar JPEG XL-implementaties te kijken, maar doen dat in de praktijk nog niet. Google lijkt de codec nu al te verwijderen voordat die in de praktijk kon worden getest. Enkele jaren terug schreef Tweakers een achtergrondartikel over potentiële opvolgers van JPEG, zoals WebP, Heic en JPEG XL.

Reacties (91)

[grootrde]

Deze beslissing zal mede gedaan zijn door een patentaankoop van Microsoft van een belangrijke techniek in JPEG.

Google heeft waarschijnlijk geen zin in een juridisch steekspel en stop hierom de ontwikkeling van hun jpeg xl.

Dus voordat iedereen weer losgaat op Google omdat ze weer een ontwikkeling stoppen is dit gevolg van een dubieuze patentaankoop van Microsoft.

[Reactie gewijzigd door grootrde op 22 juli 2024 21:48]

[DdeM]

En voordat je losgaat op Microsoft:
"Jon Sneyers, senior image researcher at Cloudinary and editor of the JPEG XL spec, told The Register in an email message, "As far as I know, this patent doesn't affect JPEG XL. At least Microsoft has not declared to ISO that it does, even though they have had plenty of time to do so if they thought it did, and Microsoft is participating in JPEG so they are aware of the technology used in JPEG XL. But of course I am not a lawyer.""

[Temenes]

Misschien nog een belangrijkere opmerking, ook van Jon Sneyers:

The specific variant of ANS coding that is used in JPEG XL is basically the same as what was used in pik: https://github.com/google...cd314d85241e/ans_encode.h

The pik source code was published in the summer of 2017. Microsoft filed the patent in June 2019.

Just by that timeline alone, I think it's safe to conclude that whatever the novel thing is in the patent, it is not applicable to JPEG XL.

[Cerberus_tm]

Tja, een groot Amerikaans bedrijf zegt het één, maar doet misschien op een dag het ander. Het rechtssysteem is daar ook vrij onzeker. Zo zie je maar weer de remmende werking van octrooien en auteursrecht: ze zorgen voor een angstcultuur en claimcultuur in één.

[Yoshi]

Dus dan kunnen we het binnenkort verwelkomen in Edge? Ja klinkt als een goede reden. Los van het feit dat ze dan best gewoon open zijn, en dat zijn ze dan ook altijd niet. En ik zou die reden dan eerder verwachten van een managen ipv ontwikkelaars.

En het is niet dat Google geen 'dubieuze' patenten koopt en maakt. Niet meer of minder dan de andere tech giganten. En zoals ms de laatste tijd toch wel wat het open source gegeven omarmt heeft, hoeft het zelf niet eens slecht te zijn maar kan je het evengoed zien als bescherming van diezelfde open source gemeenschap

[dasiro]

het zou kunnen, aangezien chromium open source is en edge daar een implementatie van is, maar in de praktijk zie ik het niet zo direct gebeuren, aangezien je dan met een fork zit die weer onderhouden moet worden door microsoft zelf en de feature nog niet genoeg draagwijdte heeft

[SuperDre]

Mwa, denk dat dat niet de reden zal zijn. Er zijn inmiddels genoeg andere formaten die wel breder gesteund worden en dezelfde features hebben, en daarmee heeft JPEG XL dan dus nog weinig toegevoegde waarde.

[aaahaaap]

Dat wordt alleen niet door Google genoemd als een/de reden.

[Kevinp]

Als het in Chromium zit heeft MS zelf ook problemen dat Chorme het er nu weer uit haalt.

[TheVivaldi]

Nee, want MS kan het zelf weer toevoegen aan hun fork genaamd Edge.

[Kevinp]

dat snap ik, maar de kans dat dat success heeft is 0. Ow ja je kan het gebruiken, maar slechts in een browser. En dan is Chrome de enige die dat mogelijk zou lukken. (helaas)

[TheVivaldi]

Falkon ondersteunt het ook, in ieder geval in mijn tests. Goed, dat is niet veel qua marktaandeel, maar het zijn wel 2 browsers. En Firefox ondersteunt het Nightly, dus dat zal ook wel breder gaan worden uitgerold en dan is het aantal al 3. En Edge en Firefox bij elkaar hebben toch wel wat marktaandeel.

[Jerie]

Zoe kunnen maar... zeg dat dan.

[swhnld]

Een van de potentiële problemen met dit formaat is een patent die toegewezen is aan Microsoft.
https://www.theregister.com/2022/02/17/microsoft_ans_patent/
Door dit patent is er het risico dat betaald moet gaan worden voor het formaat, al is er discussie of het wel of niet toepasbaar is. Waarom investeren in iets waar je geen vrijstelling voor hebt bij voorbaat?

[recyclebin]

Echter, AV1(F) — het formaat dat Google nu liever wilt pushen — heeft hier ook last van doordat een bedrijf genaamd Sisvel een betreffende patent pool in handen heeft. Google heeft zelf hier (https://www.webmproject.org/about/faq/#patent-pool-questions) ook aangegeven dat er het risico is dat betaald moet worden voor het formaat.
Dit is dus precies hetzelfde verhaal met JPEG-XL, waarbij open-source technologieën gemaakt door anderen gepatent-trolled kan worden.

[mphilipp]

Kan altijd nog een keer terugkomen als de rest van de wereld besluit JPEG XL alsnog te gaan gebruiken. Ze waren een beetje te vroeg. Als er bij Adobe en Facebook al niets wordt ondernomen heeft het voor Google ook weinig nut om het nu al te ondersteunen.

[Balance]

Uit de officiële Chromium JPEG XL tracking bug:

• Comment 61 by Eric Chan
• Comment 16 by Erika
• Comment 64 by Roland Wooster

Eric Chan is een Adobe Fellow. Roland Wooster is Principal Engineer van de Intel Client Computing Group / Display Architecture en VESA DisplayHDR Chairman. Geen idee wie Erika was, maar van een officieel @fb.com e-mailadres.

En er zijn meer, comment 67 van Mariot Chauvin, de Director of Engineering van Guardian News & Media en comment 69 van John Cupitt, de maintainer van libvips.

FFmpeg ondersteunt JPEG-XL. GIMP ook.

Er is draagvlak, er is momentum en het is echt een goed nieuw image formaat, wat alle sterkte punten van JPEG, GIF en PNG samen voegt in één formaat, wat zowel lossy als losless ondersteund, transparantie, animatie, HDR, progressive decoding.

Er moet haast iets geks aan de hand zijn bij Google, een of andere politieke push richting een eigen formaat ofzo. Want er is geen enkele logische technische reden voor Google om op dit moment JPEG-XL te laten vallen.

[Reactie gewijzigd door Balance op 22 juli 2024 21:48]

[Terry A Davis]

Op Phoronix heeft iemand een test gedaan met verliesloos (lossless) en dan doet JPEG-XL het bizar goed, beste van allen zelfs. Hij/zij heeft daarna de invoer en uitvoer hash van de bestanden vergeleken en die waren gelijk dus inderdaad lossless. Van 8 Megabyte verliesloos naar 6 Megabyte verliesloos is een grote stap. Wat wel opgemerkt werd, was dat JPEG tegenwoordig hardware acceleratie heeft. Maar ik zou me niet verbazen als je een videokaart kan programmeren om JPEG-XL te gaan doen bij het uitpakken.

[mphilipp]

Ik baseer mij op het artikel waarin staat dat Adobe en Facebook in de praktijk niets ondernemen.

[Yoshi]

Av1 heeft last van knal hetzelfde fenomeen (patent van sisvel). Opensource wilt ook niet automatisch betekenen dat er geen patenten op rusten. Integendeel zelf, je kan het patent dan bv gebruiken om het gratis te houden etc. Het open source gedeelte zorgt ervoor dat je een patent grant krijgt als je die sofware gebruikt (wat kort door de bocht, maar ik kan het anders niet zo kort houden 😅)

[Reactie gewijzigd door Yoshi op 22 juli 2024 21:48]

[supersnathan94]

Maar help dan mee om de adoptie beter te maken. Google heeft overal een vinger in de pap. Kijk naar android foto’s en sla fotos die met google fotos gesynced worden op in JPEG XL. Of gewoon al on device. Mocht je ze willen delen kun je altijd nog converteren. Doet Apple ook met HEIC. Als android alles in JPGX opslaat dan zullen FB, Insta en Adobe heel snel een oplossing vinden hoor.

Of OSS zaken als wordpress. Maak plugins beschikbaar of native ondersteuning zodat je het op het web goed kan gebruiken. Genoeg wordpress blogs die hier wat aan hebben.

[keejoz]

Alsof HEIC hier een goed voorbeeld is.. nog steeds niet te bekijken op Android telefoons.

Mijn Sony A7IV verbinden met een Android telefoon kan wel maar heeft geen enkel nut omdat die geen HEIC kan lezen.

[s_schimmel]

Dat is niet het probleem van HEIC maar van Android. HEIC is vrijgegeven in 2015 en wordt sinds 2017 door Apple ondersteund in iOS. Het wordt sinds 2018 in Windows ondersteund. Het is ontwikkeld door de Moving Picture Experts Group en daar zal het probleem zitten, nl: licentiekosten. Die wil Google niet betalen en dan wordt het maar niet ondersteund.

Het probleem met Google is dat ze weinig doorzettingsvermogen hebben. Er wordt een hoop geïnvesteerd in ontwikkeling maar als er binnen zes maanden geen mega omzet uit komt wordt een project al weer gestopt. Op de zoekmachine en maps na maak ik geen gebruik meer van Google spul. Het is de moeite niet waard om ergens op over te stappen want binnen de kortste keren gaat de stekker er uit.

In dit geval zat JPEG XL achter een experimental feature flag. Hoeveel gebruikers van Chrome weten uberhaupt dat die er is en zullen dat aanzetten? Waarom zou je als publicatie JPEG XL gaan ondersteunen op je website als geen van je bezoekers ze kan bekijken?

Het probleem is dat Google dit niet als normale feature heeft ingebouwd en standaard aanzet. Dan kan 90% van de internetgebruikers het formaat gebruiken en dan heeft het zin om aan de publicerende kant het ook in te gaan zetten.

[batjes]

Het wordt in Windows ondersteund. Je moet hiervoor wel een app downloaden uit de store.

HEIC ondersteuning heeft licentie nodig.

[page404]

Dus geen native ondersteuning in Windows. Wat wel zo zou moeten zijn.

[batjes]

Nope, ik krijg op werk wel eens foto's toegestuurd van iPhones. Maar ja, de store is uitgeschakeld dus dikke pech. Mensen moeten op de iPhone de foto delen, dan wordt het omgezet naar jpeg. Niet uploaden als bijlage.

[page404]

Ik let er altijd op dat ik jpeg opstuur, want ik realiseer me dat het formaat nog niet breed ondersteunt wordt. Gek eigenlijk, iedereen mekkert altijd over het gesloten karakter van Apple, maar als ze een open standaard gebruiken dan doet iedereen ineens of het vies is. Juist Microsoft en Google lijken een voorkeur te hebben voor allerlei gesloten en gelicentieerde standaarden.
Wacht, zeg je nu dat Heic ook onder een betaalde licentie valt? Van wie dan?

[Reactie gewijzigd door page404 op 22 juli 2024 21:48]

[batjes]

https://www.hackerfactor....chives/833-HEIC-Yeah.html
Het is niet gedocumenteerd dus er wordt veelal gebruik gemaakt van bestaande libraries en daar zitten licenties aan vast. Nokia heeft een gratis library op Github staan, voor niet commercieel gebruik.

Microsoft zal waarschijnlijk die van Nokia gebruiken of de Opensource GNU libheif en het daarom als losse download beschikbaar stellen in de store.

[EraYaN]

De meeste laptops/pre-builds met een moderne GPU hebben die wel gewoon out of the box, omdat er dan door de OEM voor de licentie betaald is.

[supersnathan94]

Tging niet om het formaat t ging om de tussenoplossing. Als android over gaat naar JPGX is er heel snel een reden voor apps en services om het ook te ondersteunen.

[Chris_147]

Rare opmerking, want de camera app op mijn Samsung A52 heeft de optie om in heic te bewaren.
Moest zelf wel op Windows een extra codec installeren om ze te kunnen bekijken.
Wat aangeeft dat dit zoiets is dat gewoon door het OS geregeld moet worden, niet door iedere applicatie apart.

[Klaus_1250]

De zoveelste JPEG opvolger die voortijdig sneuvelt. Ik kan me JPEG2000 nog herinneren (inmiddels alweer 25 jaar oud!) die het uiteindelijk ook nooit gehaald heeft - tenminste, niet voor opslag van foto's.

[Amorphis]

JPEG2000 wordt erg veel gebruikt (volgens mij de standaard in de erfgoedwereld voor opslaan van scans) om grote inzoombare bestanden op het web te publiceren. Als opvolger van JPEG is het idd niet echt gelukt.

[willieverhoef]

En voor de pasfoto in de chip van je paspoort

[aldieaccounts]

Jammer. Het leek mij een interessante opvolger voor JPEG.

- Betere compressie.
- Hogere kleurdiepte.
- Veel betere progressive decoding.

What's not to like?

[NLxDoDge]

Zaten er niet licentiekosten aan vast?
Dan zal adoptie ook niet zo snel gaan.

.webp was open source en dat wordt al wat meer gebruikt. Net als dat AV1 wordt gepushed tegn opzichte van H264/H265 puur omdat dat ook "gratis" is.

Edit .avif is het formaat wat ik zocht.

[Reactie gewijzigd door NLxDoDge op 22 juli 2024 21:48]

[Jantimon]

WEBP wordt in Nederland door 91,57% van de browsers ondersteund. Deze standaard bestaat al sinds 2010.

AVIF is jonger, maar heeft weer betere compressie dan WEBP. Deze bestaat sinds 2019, daarom zat die ook nog niet bij het gelinkte artikel van tweakers uit 2018. In Nederland ondersteund al 69,94% van de browsers dit.

Met behulp van het picture element kun je AVIF en WEBP gebruiken en aan browsers die dat niet aan kunnen gewoon een JPEG of PNG geven.

Andere formaten zoals HEIC/HEIF en boven genoemde JPEG XL lijken de race al een beetje verloren te hebben.

[EraYaN]

JPEG-XL is ook royalty free natuurlijk (afgezien van de potentiele microsoft bullshit nu) en heeft ook nog wel wat extra features boven op bijvoorbeeld WebP of AVIF, het is net jammer dan men het er niet in laat zitten voor even, maar goed Google gonna Google.

[snollygoster]

Wellicht is het een idee om wat meer ruchtbaarheid aan zo'n nieuwe feature te geven alvorens te concluderen dat er te weinig animo voor is.

[Raem]

https://caniuse.com/?search=jpeg%20xl

Geen enkele browser die het standaard ondersteunt. Dan is inderdaad de motivatie om het actief te gaan gebruiken ook een stuk lager lijkt me.

[jaenster]

Gelukkig maar. Chrome pusht altijd van dit soort dingen, en de rest moet maar volgen omdat de meeste mensen chrome(ium) gebruiken. En vervolgens zie ik tweakers klagen dat firefox niet "alles" support.

Of dat ze iets nieuws maken, een mega trage polyfill maken, en het gelijk gebruiken. Dan lijkt opeens youtube traag in firefox, dat is het ook, maar niet omdat firefox slecht is. (shadow dom is een voorbeeld IIRC)

Chrome moet zich keertje aan de standaarden houden en niet zelf allerlei dingen verzinnen en pushen. Verzin iets, leg het voor aan de standaarden commissie en maak dan pas de feature.

[keejoz]

Firefox biedt tot op vandaag nog steeds geen 100% support voor bv. WebRTC.

In tegenstelling tot Chrome vind ik dat het tijd wordt dat Firefox zich aan de standaarden houd en niet zelf allerlei dingen verzinnen en pushen.

[jaenster]

Dit is een typisch voorbeeld. Google verzint iets (WebRTC). Brengt gelijk support er voor uit (great), pusht zijn standaard dan pas. Het word een standaard doordat het al gebruikt word en gepusht word door google. Vervolgens begint de rest (firefox/safari) met een achterstand. Dit is gewoon iexplore gedrag.

Kijk eens bij je caniuse en je ziet dat het allemaal chromeium based browsers zijn die het volledig supporten (ook de experimentele dingen). Kijk eens op de website van webRTC, volledig van google, al dan niet open source. Firefox support wat is afgesproken, chromium verzint er dingen bij. En yet op tweakers klaagt iemand dat firefox niet alles support

[calvinturbo]

Tja en dan wat? Ik vraag me af wat je dan zou willen? Doordat Google (en MS) zo snel doorpakken met nieuwe features, kunnen we steeds meer zaken binnen de browser doen. Uiteindelijk worden die nieuwe features vanzelf in standaarden verwerkt. De vergelijking met IE gaat dan ook volledig mank.

[Hakker]

Het gaat niet om het doorpakken het gaat erom dat Google dingen in het wild uit brengt en dan pas besluit van "oh laten we het voorleggen als een standard" in plaats van eerst de voordracht te doen en het dan te implementeren. Google doet precies hetzelfde wat Microsoft deed met zijn Internet Explorer in het verleden. Toen liep iedereen te zeiken op MS, maar nu is het Google die geweldig is

Laten ze het maar eerst voorleggen zodat elke ontwikkelaar de tijd heeft om het te implementeren voor men iets final maakt. Om dit soort fratsen alleen al zal ik niet naar een chromium browser stappen buiten het feit dat het alles doorstuurd wat je doet zelfs in privacy mode.

[Reactie gewijzigd door Hakker op 22 juli 2024 21:48]

[Remzi1993]

Het grote verschil is dat Microsoft in het verleden met IE dingen dan ook niet eens voorlegde als standaard en het ook niet open source was. Dan kon je echt pech hebben als ander bedrijf en beetje in het stof.

[batjes]

Tot en met IE5 klopt dat een beetje, vanaf IE4 is Microsoft zich juist heel erg open gaan gedragen omtrent de webstandaarden. Microsoft heeft alle standaarden die het in IE5-6 gebruikt heeft voorgelegd bij het W3C. Zelfs ActiveX is ooit aangedragen als standaard.

Mozilla, Opera en Sun hebben de kont tegen de kribbe gegooid en er voor gezorgd dat ze bijna allemaal afgewezen werden of dat ze net wat anders geïmplementeerd werden. Een groot deel van de initiële HTML5 specsheet heeft zijn oorsprong in IE6 te vinden.

[s_schimmel]

Microsoft is overgestapt op Chromium en kunnen daarom sneller mee. In plaats van vier zijn er nu dus maar drie browsers. Als er eentje bij is die dan denkt dat ze het hele internet zijn dan gaat het mis. Precies hetzelfde is met IE gebeurd in de begin dagen van het internet. Iedereen had IE en dus richtte alle ontwikkelaars op de mogelijkheden van IE. Dat je vervolgens niks kon met ActiveX componenten in Netscape of Firefox maakte niet uit. Moet je maar IE gebruiken. Nu doet Google met Chrome hetzelfde.

Prima als je wat nieuws bedenkt maar maak er een een open standaard van, zorg dat iedereen die ondersteund en houd jezelf ook aan die open standaard en ga er niet vanalles bij in bouwen dat weer niet in de standaard zit.

[Bender]

Verzin iets, leg het voor aan de standaarden commissie en maak dan pas de feature.

Hoe wel ik het begrijp, zijn dit ook wel extreem vertragende factoren.. waardoor een implementatie jaren kan duren zodat het al weer ingehaald wordt door iets nieuws (waar dan ook weer jaren overheen gaat).

[Vexxon]

Weet je nog toen IE verguisd werd om het niet volgen van standaarden?
Chrome zit nu in exact dezelfde positie en flikt precies hetzelfde als IE destijds deed.

[blorf]

Firefox is niks beter. Die gaan evenmin standaarden 100% navolgen want dan komt naar voren welke 95% van de functionaliteit eigenlijk niemand nodig heeft. Einde imperium...

[Hakker]

noem eens een paar voorbeelden alsjeblieft

[blorf]

JavaScript warning: htt.ps://www.google.com/js/bg/7JEUJG1jVChIMuhiOxVurQN9pIQLeBNKr_aiZz5iC5Y.js line 2 > eval line 5590 > eval line 1 > eval line 1 > eval, line 1: WEBGL_debug_renderer_info is deprecated in Firefox and will be removed. Please use RENDERER.
[2022-11-01T11:55:02Z ERROR mp4parse] Found 2 nul bytes in "\0\0"
console.warn: LoginRecipes: "Falling back to a synchronous message for: https://tweakers.net."

Waarschijnlijk precies zoals het bedoeld was. Ze zitten duidelijk niet te wachten op modulariteit en de bemoeienis van ongewenste partijen als gevolg daar van.
In de praktijk zou het een opsomming van ondersteunde webstandaarden met preset-vinkjes kunnen zijn, maar het is een inconsistente monoliet die "bijzondere" permissies van elk OS krijgt en het verbergt als deze worden gebruikt. Naar mijn idee vooral veroorzaakt door reclame-belangen van bepaalde multinationals.

[Reactie gewijzigd door blorf op 22 juli 2024 21:48]

[geert1]

Chromium is zelf een browser-engine. Het overzicht van Can I Use zal alleen verbeteren wanneer browsers juist wel beslissen dit formaat te gaan ondersteunen. En Google is daar zelf (helaas) leidend in.

Het is wel zo dat er ook ondersteuning nodig is vanuit foto- en design-software, serversoftware en andere plekken waar afbeeldingen verwerkt worden. Maar browsers zijn een enorm belangrijk deel daarvan. Google is nogal snel met deze beslissing.

Voor ons als eindgebruikers zou het vooral mooi zijn als de beste formaten winnen. Met de beste compressie en features, zodat het internet snel blijft en tegelijk niet te korrelig. Of dat nu WebP is, of JPEG XL, of AVIF: ik vind het prima, maar liever niet alle drie. We zullen zien hoe het gaat de komende jaren.

[Reactie gewijzigd door geert1 op 22 juli 2024 21:48]

[TheVivaldi]

Lijkt bij mij anders prima te werken in Falkon (webbrowser). Heb er niks voor hoeven doen.

Het zit volgens mij ook in QtWebEngine: https://doc.qt.io/qt-6/qt...mage-decoder-library.html
Dus dat zal wel de reden zijn dat Falkon het ondersteunt.

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 21:48]

[jeroen7s]

Qt WebEngine integrates Chromium's fast moving web capabilities into Qt.

Logisch dat Falkon dit dan ondersteunt, Falkon is uiteindelijk ook een chromium-based browser

[GertMenkel]

Was de feature ooit standaard aan in ook maar enig product dan ook? Voor zover ik weet zat het altijd achter een flag. Dit is niet echt weghalen denk ik, eerder het annuleren van een idee waar men mee speelde.

Er is geen enkele browser die dit formaat ondersteunt dus er is ook niemand die het gebruikt. Formaten als AVIF en WEBP die wel door de meeste programma's ondersteund worden zijn daarom ook veel betere keuzes voor webontwikkelaars.

Omdat de wereld duidelijk niet genoeg Javascript heeft zijn er wel manieren om via WASM een enigszins snelle image decoder in je webpagina te zetten die JPEG-XL ondersteunt (of enig ander formaat dat een browser misschien niet heeft). Zo zou je de standaard wel al kunnen gebruiken voor websites, al is de performance slechter. Met de mate van compressie die dit formaat toestaat is het misschien het overwegen waard voor bijvoorbeeld foto's.

[Reactie gewijzigd door GertMenkel op 22 juli 2024 21:48]

[TheVivaldi]

Ik kan in Falkon jpeg-xl-foto's bekijken en heb daar niks voor hoeven doen. Ik denk omdat er jpeg-xl-ondersteuning in QtWebEngine is, dat Falkon het standaard kan:
https://doc.qt.io/qt-6/qt...mage-decoder-library.html

[GertMenkel]

Ik heb nog nooit eerder van Falkon gehoord, misschien dat zij wel de standaard hebben ingebouwd. Wellicht dat ze inderdaad de Qt-bibliotheek gebruiken om dat toe te voegen waar andere browsers daar liever geen afhankelijkheid voor toevoegen aan hun project.

Op zich mooi dat het formaat in elk geval ergens is aangezet, al is het een nicheproduct binnen een nichemarkt.

[TheVivaldi]

Zeker! Verder is het overigens beschikbaar in Edge en Firefox en daar blijft het allebei ook in, maar het zit daar wel achter een flag (edge://flags en about:config resp.). Ik denk dat Falkon de enige browser is waar het standaard aan staat.

Verder inderdaad nog vrij niche, maar je moet natuurlijk ergens beginnen. Tesla boorde eerst ook een nichemarkt met hun elektrische auto's aan, maar nu zijn ze niet meer weg te denken, om maar even een zijsprongetje te maken.

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 21:48]

[Rob Coops]

Google kondigt een nieuw image formaat aan dat ze willen gaan ondersteunen in hun Chrome browser.
Microsoft koopt patent dat ze de mogelijkheid geeft om deze nieuwe image standaard ten gelde te maken.
Google kondigt aan dat er te weinig mensen interesse toonde in de nieuwe image standaard.

Goh, neen joh, je verwacht het niet.

Nu neem ik aan dat Google waarschijnlijk al in de wandelgangen van Microsoft vernomen had dat er kosten verbonden zouden worden aan het gebruik van dit nieuwe image formaat maar dat zullen we waarschijnlijk helemaal nooit horen.
Googles argument dat het onderhouden van de feature te veel zou kosten of te veel tijd in zou nemen in natuurlijk een beetje onzin. Een bedrijf als Google zal echt geen ernstige schade lijden als ze een minder populair bestandsformaat ondersteunen in hun browser. Als de implementatie eenmaal af is is er weinig tot geen onderhoud aan nodig.

Nu maar hopen dat Microsoft volgende week aan kondigt dit patent te schenken aan de wereld en dus nooit kosten te rekenen voor het gebruik er van. Want ik zou heel erg graag willen zien wat Google dan doet als de andere browsers het wel gaan ondersteunen en zij het er juist uitgesloopt hadden.
Gezien de betere compressie en dus lagere kosten voor bedrijven die veel plaatjes serveren (zo als Google bijvoorbeeld) kan ik me best wel voorstellen dat dit een populair bestandsformaat zou kunnen worden als de ondersteuning er is in de browsers.

[Killemov]

Google is steeds meer bezig met de self-fulfilling prophecy van producten lanceren en dan door gebrek aan interesse dat product weer cancellen.

[watercoolertje]

Het is geen product maar een implementatie van een een standaard.

[svane]

De standaard is echter wel (deels) ontwikkeld door Google.

De standaard niet ondersteunen in je eigen browser, die ook nog eens het meest populair is, is een prima manier om de standaard effectief te cancellen.

Oftewel, ze cancellen hun 'eigen' standaard met behulp van hun eigen browser.

[Zoop]

Dit is echter geen Google product, Google heeft er enkel support voor in hun browser gebakken en vervolgens van plan dat te stoppen, thats it. JXL blijft gewoon bestaan en wie weet komt dat in de toekomst alsnog terug als het toch populair genoeg blijkt (zoals artikel meld, Facebook en Adobe zijn er ook mee bezig).

[sdziscool]

Dus over een maandje of 2 komt Google met zijn eigen image codec, got it

[KingLeaf]

https://en.wikipedia.org/..._Image_File_Format_(AVIF)

[Reactie gewijzigd door KingLeaf op 22 juli 2024 21:48]

[graey]

Bedoel je WebP?

[keejoz]

JPEG XL is ontwikkeld door Google..

[dipje2]

hmm, nee

[geert1]

Het voorstel dat uiteindelijk de JPEG XL standaard werd, was vooral een combi van twee eerdere voorstellen: PIK van Google en FUIF van Cloudinary. Dus ik denk dat we wel kunnen stellen dat Google in elk geval een flink hand had in de totstandkoming van deze standaard.

Google is ook betrokken bij de soortgelijke AVIF- en WebP-standaarden. Die laatste is het sterkst gelieerd aan Google zelf, maar wordt min of meer voorbij gestreefd door de nieuwere formaten.

Gelukkig zijn alle drie deze standaarden flink beter dan het oude JPEG. Dus verlies voor de eindgebruiker of de makers is er hier niet. AVIF is waarschijnlijk de beste keuze voor het web als geheel, maar het maakt niet enorm veel uit. Ik hoop dat de beste standaard mag winnen, en dat ze niet allemaal blijven vechten om een plek want wildgroei zou vervelend zijn.

[aldieaccounts]

Ik vond jpegXL veel handiger in gebruik dan avif. Voor de progressive decoding is een stuk beter wat ik er van gezien heb.