TIFF naar WebP omzetten

TIFF is nooit een webformaat geweest. Het bestaat van voor het web, geen browser heeft het ooit omarmd, en een pagina naar een .tif-bestand wijzen download hem in plaats van hem te tonen. Daarom kwam het bestand binnen en werkt niets erna mee: een CMS weigert het bij uploaden, een winkelplatform wijst het af, een paginasjabloon laat het stilzwijgend vallen.

WebP is precies het tegenovergestelde ontworpen — een leveringsformaat van Google, gestandaardiseerd als RFC 9649, gelezen door elke huidige browser zonder terugval. De omzetting hier is dus geen kwaliteitsbeslissing maar een compatibiliteitsbeslissing, en het is de minst omstreden omzetting in deze familie: het bestand wordt zichtbaar, wordt klein, en behoudt de transparantie die het voor de hand liggende alternatief zou vernietigen.

Een TIFF geschreven door een scanner of een drukwerkstroom slaat zijn pixels meestal ongecomprimeerd op, wat vier bytes per pixel is met een alfakanaal en drie zonder. De eigen steekproef van deze site maakt het getal concreet: op 480 bij 320 pixels is de TIFF 615.400 bytes voor elke scène, want de inhoud maakt geen verschil voor een bestand dat niet gecomprimeerd is.

Dezelfde drie beelden als WebP op de standaardkwaliteit zijn 14.700 bytes voor de foto, 10.830 voor de schermafbeelding en 4.428 voor de vlakke tekening met transparantie. Dat is tussen de veertig en honderdveertig keer kleiner. Schaal het op naar een echte scan en dat effect is wat de pagina überhaupt laat laden: een kleurenscan van A4 op 300 dpi is ruwweg 26 megabyte als ongecomprimeerde TIFF en enkele honderden kilobyte als WebP, nog voor je de pixelafmetingen hebt teruggebracht.

WebP slaat breedte en hoogte op in veertien bits, dus kan geen WebP langer zijn dan 16.383 pixels op een rand. Dat is het formaat zelf en elke encoder die bestaat deelt dat. Gemeten tegen de hier gebruikte: een beeld van 16.383 pixels breed codeert normaal, en hetzelfde beeld op 16.384 faalt met een coderingsfout.

Gewone foto’s komen er nooit bij in de buurt en scans regelmatig wel. Een A1-tekening op 600 dpi is ongeveer 14.000 bij 19.900 pixels en een A0-vel op 400 dpi zo’n 13.200 bij 18.700; een scan van een A4-pagina op 1.200 dpi is 10.200 bij 13.200 en past er nog net in. Weigert een grote scan om te zetten, dan is dit vrijwel altijd waarom, en de oplossing staat op hetzelfde scherm: stel een maximale breedte onder 16.383 in en hij gaat door. Een beeld voor een webpagina verkleinen is sowieso geen verlies — bijna niets op het web wordt boven de 3.000 pixels breed geserveerd.

De kwaliteitsinstelling loopt van 1 tot 100 en begint op 82. Dat is een goede standaard voor een fotografische scan, waar de lossy-modus van WebP doet waarvoor hij is ontworpen: 82 oogt visueel schoon op normale kijkafstand en het bestand is een fractie van alles verliesvrij.

Het is een slechte standaard voor een gescand document, een lijntekening of een schermafbeelding, waar harde zwart-op-wit-randen precies zijn waar lossy compressie het slechtst mee omgaat — het symptoom is een vage grijze waas rond tekst en lijnen. Zet de kwaliteit voor dat materiaal naar 90 of hoger en de wazen verdwijnen, tegen een kosten die nog steeds niets is naast de TIFF. Moet het document pixel-exact blijven, dan is dit het moment waarop TIFF naar PNG de betere pagina is: PNG behoudt elke pixel en is bij vlakke, interface-achtige inhoud vaak zelfs kleiner dan een WebP van hoge kwaliteit.

Een TIFF is een container in plaats van een afbeelding, en verschillende dingen erbinnen hebben nergens heen. Meerdere pagina’s: alleen de eerste wordt gelezen. Lagen: er komt een platte compositie uit. Zestien bits per kanaal: teruggebracht naar acht door de hoge byte te behouden, wat onzichtbaar is in een afgewerkt beeld en wel doet als je een bewerkbaar master bedoelde. CMYK: omgezet via een formule in plaats van via het profiel in het bestand, dus verschuiven kleuren.

Niets daarvan is een gebrek voor de taak op deze pagina — een webpagina is 8-bit RGB, één beeld en sRGB per definitie, dus de verliezen zijn allemaal dingen die de bestemming toch niet had kunnen gebruiken. Het is wel een gebrek als de TIFF je enige kopie was. Bewaar de TIFF; publiceer de WebP. Dat is de vorm die deze omzetting altijd zou moeten aannemen, en het kost niets omdat het origineel niet wordt gewijzigd.

WebP heeft een echt alfakanaal, dus een TIFF met een uitgesneden onderwerp komt door als een uitsnede. Dat is de enige reden om deze pagina te kiezen boven TIFF naar JPG als de afbeelding een product op een transparante achtergrond is, een logo, of iets dat op een gekleurde pagina moet staan.

De alfa wordt per pixel opgeslagen in plaats van als één transparante kleur, dus zachte randen — een uitgevloeid masker, een geanti-aliaste omtrek, een schaduw die vervaagt — overleven als zachte randen. Hier is WebP ook duidelijk beter dan de oudere optie: dezelfde TIFF naar GIF omzetten zou hem terugbrengen naar 256 kleuren en, zoals de encoder van deze site het schrijft, ondoorzichtig zwart plaatsen waar de transparantie zat.

Een TIFF kan EXIF, XMP, IPTC, een ICC-profiel en GPS-coördinaten bevatten. Niets daarvan komt aan in de WebP, en er is geen instelling die het zou bewaren: elke beeldomzetting aan de browserkant op deze site decodeert naar kale pixels en codeert opnieuw, dus de blokken zijn al weg voor de encoder iets krijgt.

Voor een webafbeelding is dat het gedrag dat je wilt. Een scan publiceren met de opnamelocatie, de naam van de operator en het serienummer van de machine er nog aan is een routineuze en vermijdbare openbaarmaking, en het strippen ervan scheelt ook een paar honderd bytes per bestand. Moet een bijschrift of copyrightregel meereizen met de afbeelding, dan hoort dat in de markup van de pagina in plaats van in het bestand, want de meeste platforms strippen ingebedde metadata bij upload ongeacht wat je opstuurt.

WebP is het veilige antwoord en niet altijd het beste. Op de eigen steekproeven van deze site was AVIF aanzienlijk kleiner op de schermafbeelding — 5.081 bytes tegen WebP’s 10.830 — en iets groter op de foto, op 17.599 tegen 14.700. Voor vlak, gescand, documentachtig materiaal is de omweg naar TIFF naar AVIF dus de moeite waard, en AVIF tilt het groottelimiet ook op naar 65.536 pixels, wat de andere reden is dat een zeer grote scan daarheen zou kunnen gaan.

De afweging is ondersteuning. WebP werkt in elke huidige browser zonder terugval; AVIF werkt in moderne browsers en niet in alles waarmee een bezoeker kan aankomen. En waar de afbeelding een document is dat exact moet blijven — een handtekening, een plan, een tabel met cijfers — is TIFF naar PNG de pagina die elke pixel bewaart, op een omvang die bij vlakke inhoud vaak kleiner is dan een WebP van hoge kwaliteit.

De omzetting draait in je browser. De TIFF wordt gedecodeerd door utif2, opnieuw gecodeerd door libwebp gecompileerd naar WebAssembly, en teruggegeven als download; er gaat niets van het bestand over het netwerk, wat de moeite waard is om te weten als de scans medische dossiers, contracten of onuitgebracht werk zijn. De gratis groottegrens is 100 MB per bestand, ruwweg een A4-kleurenscan op 600 dpi ongecomprimeerd opgeslagen.

Batches werken hetzelfde: sleep een map erin, elk bestand wordt beurtelings omgezet met een eigen voortgangsregel, en de resultaten komen terug als ZIP. Zo wordt deze pagina meestal gebruikt, want scanners produceren reeksen in plaats van losse bestanden. De engine wordt eenmalig opgehaald en voor de rest van de batch hergebruikt, dus honderd bestanden kosten één download van de codec.