WebM naar JXL omzetten

Elk ander stilstaand formaat op deze site heeft iemand die het eist. Een dossiersysteem specificeert TIFF. Een prestatiebudget dwingt AVIF af. Een e-mail heeft een JPG nodig en een bugrapport een PNG. JPEG XL heeft geen achterban: geen uploadformulier noemt het, geen archiefstandaard vereist het, en geen collega heeft ooit om een gevraagd.

Dat betekent dat deze pagina je een beoordeling verschuldigd is en geen instructies. Je hebt gelezen dat JXL beter comprimeert dan wat je nu gebruikt en overweegt over te stappen, wat een redelijke afweging is en de moeite waard om te maken met het echte gedrag van deze omzetting voor je in plaats van de specificatie van het formaat.

De reputatie van JPEG XL steunt grotendeels op verliesvrije codering — het kan een beeld exact opslaan, en het kan een bestaande JPEG verliesvrij en kleiner herpakken. Geen van beide gebeurt hier. Beeldextractie biedt één optie, de tijdsaanduiding, en geeft het gedecodeerde beeldje door aan de gedeelde beeldencoder, die een vaste kwaliteit van 82 gebruikt.

Tweeëntachtig is een verstandig getal voor een foto en toch verliesgevend. Een JXL gemaakt op deze pagina is dus een gecomprimeerde benadering van een beeldje dat al een gecomprimeerde benadering was, en het als archiefmaster omschrijven zou tweemaal fout zijn. Was dit niet wat je verwachtte, dan is het beter dat in een alinea te ontdekken dan over drie jaar.

Mag er verder niets weg, dan is de PNG-route wat dat levert. PNG bewaart precies wat de decoder produceerde en houdt daar op, en het resulterende bestand gaat daarna door een verliesvrije optimalisatiepas die het efficiënter herschrijft zonder een beeldpunt te veranderen.

De ruil zit in de omvang, en bij schermeninhoud is die kleiner dan mensen verwachten, want grote vlakke gebieden van één kleur zijn precies waar PNG voor bedacht is. Neem de JXL wanneer je duizenden beeldjes hebt en de omvang per beeld de beperking is die je beheert; neem de PNG wanneer het beeldje bewijs, documentatie, of de enige kopie van iets is.

Eén beeld iets kleiner is niet de moeite waard om je gereedschap voor te veranderen. Duizend beelden is andere rekenkunde, en dat is het geval waar deze omzetting voor past: een monitoringarchief met een beeldje per opname, een onderzoeksset bemonsterd over honderden sessies, een persoonlijke verzameling waar de opslagrekening een echt getal is.

Op die schaal is een moderne codec tegenover een oudere een betekenisvol deel van een schijf, en dat weinig dingen een JXL openen doet er minder toe, want de bestanden worden gelezen door je eigen scripts en niet doorgegeven aan anderen. Zodra een ervan naar iemand gestuurd moet worden, keert de rekensom volledig om.

Het register noteert browserondersteuning voor JPEG XL als gedeeltelijk in plaats van universeel, en noemt GIMP en ImageMagick als de software die het leest. Beide kloppen en beide onderschatten hoe onhandig het in de praktijk is: op een JXL kun je niet rekenen om in een webpagina te renderen, te tonen in een bestandsbeheerder, of te openen op andermans machine.

Plan daarop in plaats van het te ontdekken. Bewaar een JPG of een PNG naast alles dat aan een mens getoond zou moeten kunnen worden, en behandel de JXL als de bewaarde kopie en niet als de werkkopie. Een archief waarvan niemand het formaat kan lezen is een back-up met extra stappen.

Het beeld komt uit op de eigen pixelafmetingen van de video zonder iets te schalen, en elke omzetting levert er precies één op. Een set opbouwen betekent herhaaldelijk omzetten met verschillende tijdsaanduidingen — een getal typen, omzetten, downloaden, het getal veranderen — wat een paar seconden per keer kost omdat er tussendoor niets geüpload wordt.

Dat is een redelijke manier om een dozijn stills uit een sessie te halen en een slechte manier om er duizend te halen. Voor een echt grote bemonsteringsklus is een opdrachtregelgereedschap met een beeldsnelheidsvlag het juiste gereedschap, en dat zeggen is nuttiger dan doen alsof een browserformulier daarnaar opschaalt. Gebruik dit voor de beeldjes die iemand al gekozen heeft.

JPEG XL is, net als de andere moderne stilstaande codecs, afgesteld op fotografische inhoud: verlopen, textuur, detail dat vloeiend verandert. Schermopnames zijn het tegenovergestelde — harde randen, vlakke panelen, dunne lijnen en klein lettertype — en verliesgevende encoders zetten een vage halo precies rond die overgangen.

Op kwaliteit 82 is die halo licht en toch aanwezig, en hij landt op het deel van een schermafbeelding dat iemand daadwerkelijk moet kunnen lezen. Bestaat het beeldje omdat een foutmelding, een veldwaarde of een menu-item leesbaar moet zijn, dan is dit de verkeerde omzetting ongeacht hoe de bestandsomvangen zich verhouden. Die lezer is beter geholpen met de verliesvrije route.

Het meeste dat JPEG XL interessant maakt gaat over foto's. Hoge bitdiepte voor rawomzettingen, een alfakanaal, EXIF en ICC-profielen die door een bewerkingsketen meegedragen worden, verliesvrije herpakking van een bestaande JPEG-bibliotheek. Dat zijn echte voordelen en geen ervan is bereikbaar vanuit een videobeeldje.

Het beeldje komt door een canvas op acht bits per kanaal binnen, volledig ondoorzichtig, zonder cameragegevens, geen opnametijdstip en geen kleurprofiel — want een browseropname had die nooit. Wat er van het argument van het formaat hier overblijft is compressie-efficiëntie alleen, wat een smaller argument is dan wat mensen doorgaans overhaalt het te adopteren.

De WebM wordt in het tabblad gedecodeerd met de codecs die de browser al aan boord heeft, één beeldje wordt gecodeerd, en er wordt niets met de video meegestuurd. Er is geen account en geen daglimiet, en de gratis laag accepteert bestanden tot 100 MB.

Voor deze lezer is dat meer dan een principe, want de opnames die bemonsterd worden zijn meestal schermopnames — sessies, dashboards, interne tools, wat er ook zichtbaar was. Een hele opname uploaden om één beeldje terug te krijgen is een slechte ruil, nog voordat iemand vraagt waar hij heenging.