WebP naar TIFF omzetten

Wie dit paar opzoekt, gaat er vaak van uit dat TIFF het hogekwaliteitsformaat is en dat omzetten een upgrade betekent. TIFF kan inderdaad 16 bits per kanaal, CMYK en meerdere pagina’s dragen zonder iets te comprimeren, maar het is geen restauratie.

Was de WebP verlieslatend — wat bij vrijwel elke webserved WebP het geval is — dan zijn de artefacten daarvan gewoon wat de afbeelding nu is, en ze worden trouw en tegen hoge kosten in bytes in de TIFF geschreven.

Vier kanalen van elk 8 bit, onbewerkt, fotometrisch RGB, opgeslagen in strips, met de resolutietag op 72 dpi. Onbewerkt is een bewuste keuze: LZW is vrijwel universeel, Deflate niet, en wie naar TIFF omzet voedt vaak een specifieke machine.

De kosten zitten in de omvang. Vier bytes per pixel betekent dat een afbeelding van 12 megapixel ongeveer 48 MB wordt vóór de header — de inhoud maakt daarin geen verschil.

Het resolutieveld in de TIFF staat op 72 dpi en is niet afgeleid van iets in de WebP, die geen equivalent veld heeft om van af te leiden. Een drukker die die tag leest, meldt een lage resolutie — de meest voorkomende verwarring op deze pagina.

Wat de afdrukbare grootte echt bepaalt is het pixelaantal. Bij 300 dpi heeft een afdruk van 10 cm ongeveer 1180 pixels nodig, een A4-pagina ongeveer 2480. Meet je afbeelding tegen die getallen voordat je iets inlevert.

TIFF ondersteunt CMYK, en dat is een groot deel van waarom drukwerkflows er om vragen. Deze converter schrijft alleen RGB, omdat de hele beeldpijplijn hier naar 8-bit RGB decodeert.

Staat er «CMYK TIFF» in de specificatie, dan voldoet dit bestand niet en verandert geen instelling dat. De scheiding moet gebeuren in software met het juiste profiel — Photoshop, Affinity Photo of GIMP.

De TIFF krijgt een vierde kanaal, dus een WebP met alfakanaal komt met zijn transparantie aan. Voor werk dat later gecomponeerd wordt, is dat precies goed.

Voor een inzending kan het een probleem zijn: sommige portals en oudere archieftools wijzen TIFF’s met alfakanaal af of interpreteren het verkeerd. Vraagt de eis niet om transparantie, plat de afbeelding dan eerst op wit.

TIFF kan meerdere pagina’s, lagen, 16-bit-kanalen, steunkleuren en een ICC-profiel dragen. Een WebP heeft daar niets van bij te dragen: het is een enkele 8-bit RGB-afbeelding met optionele alfa.

Metadata reist ook niet mee. Elke beeldomzetting hier decodeert naar rauwe pixels en codeert opnieuw, dus EXIF, XMP of een ICC-blok in de WebP gaat verloren. Vereist een inzending ingesloten copyrightinformatie, dan moet die achteraf worden toegevoegd.

WebP bevat een stilstaand beeld of een animatie, en de gebruikte decoder leest alleen het eerste soort. Een geanimeerd bestand wordt geweigerd met een leesbare melding, niet omgezet naar het eerste frame.

Is één frame wat je nodig hebt, open de animatie dan in een browser, pauzeer en maak een schermafbeelding. Gaat het om de beweging, dan zijn WebP naar GIF of WebP naar MP4 de juiste pagina’s.

Is het doel een exacte kopie in een formaat dat alles opent, dan is WebP naar PNG op elk vlak beter: verlustloos, transparantie intact, een fractie van de omvang.

Gaat het naar een gewone printdienst, dan is WebP naar JPG wat men verwacht. Gaat het om een documentinzending, dan voldoet WebP naar PDF vaak aan dezelfde portals die TIFF vermelden en is veel kleiner.

libwebp, gecompileerd naar WebAssembly, decodeert het bestand en utif2 schrijft de TIFF, beide alleen opgehaald wanneer nodig en beide draaiend in het tabblad. Er wordt niets geüpload.

De gratis grens is 100 MB voor het invoerbestand, dus de praktische beperking is geheugen: een grote afbeelding kost meerdere bytes per pixel terwijl hij geschreven wordt. Batches werken, maar de uitvoer is onbewerkt, dus honderd afbeeldingen leveren een ZIP van gigabytes op.