Convertir TIFF en GIF

La fameuse limitation du GIF est 256 couleurs, et le matériel qui domine cette page s’en moque. Un fax, un scan Groupe 4, un formulaire rempli, un dessin au trait ou un document noir sur blanc utilise deux de ces 256 emplacements, donc la palette n’impose aucune perte — chaque pixel passe exactement, et le fichier est petit parce que la compression LZW du GIF est très bonne sur les longues suites de pixels identiques.

C’est le cas qui vaut d’être sur cette page, et il est courant : le bitonal est le mode par défaut de presque tous les scanners de documents jamais vendus. Un scan en niveaux de gris est presque aussi bon, puisque 256 gris est précisément ce qu’une image en niveaux de gris 8 bits a. Les ennuis commencent avec la couleur et avec la trame, et ils commencent brusquement plutôt que graduellement.

Quelque chose doit décider quelles couleurs survivent, et ici c’est gifenc, qui construit une palette par regroupement nearest-neighbor par paires — un port de PnnQuant.js — plutôt qu’à partir de la fréquence d’apparition. La palette est choisie dans un espace colorimétrique réduit plutôt que dans les seize millions complets, ce qui coûte un peu de précision et économise plusieurs secondes sur un grand scan ; pour un format qui finit à 256 entrées c’est le bon arbitrage.

Le résultat en tons continus n’est l’idée de personne du beau et il n’est pas non plus manifestement abîmé. Un ciel devient une série de paliers visibles, les tons de peau deviennent tachés, et un original imprimé en trame prend un moiré qui n’était pas dans le scan. Sur les échantillons de ce site la photographie fait 37 227 octets en GIF contre 14 700 en WebP — plus gros et moins bon en même temps, ce qui est le signe le plus clair possible que c’est l’exigence de la destination plutôt que l’image qui vous a amenés ici. Aucun contrôle de qualité n’est proposé sur cette paire, et il n’y a rien à faire pour un — le seul vrai levier d’un encodeur GIF est lesquelles 256 couleurs garder, et ce choix est fait par le quantificateur plutôt que par un nombre que vous réglez.

Le GIF supporte la transparence d’une manière limitée : une entrée de palette peut être nommée invisible. L’encodeur utilisé ici n’en nomme aucune, donc rien dans la sortie n’est transparent. Ce que deviennent les pixels transparents est la couleur de fond du panneau d’options, appliquée avant que la palette soit construite, et elle commence au blanc.

Réglez-la à ce que la destination montre derrière l’image avant de convertir un lot. Un logo scanné enregistré avec un détouré, ou un TIFF exporté depuis un outil de design avec un canal alpha, revient sur un rectangle plein de cette couleur, et le bord anti-aliasé est mélangé dedans — donc un détouré aplati sur du blanc puis posé sur une page sombre porte une frange pâle. Si la transparence elle-même fait partie de l’image, TIFF en PNG et TIFF en WebP la gardent tous deux, et TIFF en ICO aussi si la destination est un favicon.

Deux faits de conteneur se télescopent sur cette page et ni l’un ni l’autre n’est évident. Un TIFF peut contenir plusieurs images et le lecteur ici prend la première ; un GIF peut contenir plusieurs images et l’écrivain ici en émet une. Donc un fax scanné de six pages devient une image fixe unique de la page une, silencieusement.

Cela enterre aussi un espoir qui amène certaines personnes à cette paire : un TIFF multi-pages ne devient pas un GIF animé. Rien ici n’assemble des images à partir de pages, et même si c’était le cas, une animation est le mauvais conteneur pour un document. Scindez le TIFF dans ImageMagick ou IrfanView et convertissez chaque page, ou utilisez TIFF en PDF, qui est la seule conversion de cette famille qui garde toutes les pages dans un seul fichier.

De beaucoup, parce que le point de départ est non compressé. Les échantillons de ce site font 615 400 octets en TIFF à 480 par 320 dans tous les cas, et en GIF ils font 6 326 octets pour la scène type capture d’écran, 7 688 pour le graphique plat et 37 227 pour la photographie.

L’ordre de ces trois est la part utile. Le GIF est à son meilleur sur du matériel plat, à bords nets — ce qu’est un document scanné — et à son pire sur les tons continus, ce qui est l’exact opposé du comportement du JPEG. C’est pourquoi un vieux système qui accepte le GIF et le JPEG gérera votre formulaire scanné mieux en GIF et votre photographie scannée mieux en JPG, et pourquoi faire passer les deux par la même voie est une erreur qui mérite d’être évitée.

Tout sauf les pixels de la première page, en pratique. Seize bits par canal sont ramenés à huit avant la quantification, qui les ramène ensuite à 256 couleurs au total. Le CMJN est converti en couleur d’écran par formule plutôt qu’à travers le profil ICC embarqué, donc un scan d’impression se décale. Les couches sont aplaties. EXIF, XMP, IPTC, le profil ICC et tout bloc GPS sont abandonnés, sans réglage qui les garde : la conversion décode en pixels et encode à partir de pixels, donc au moment où le GIF est écrit il ne reste rien à porter.

Pour le travail pour lequel cette page existe, aucune de ces pertes n’a d’importance : la destination est un système qui voulait une image 8 bits d’un document. Cela compte si le TIFF est votre seule copie, ce qui est le conseil permanent sur toutes les pages de cette famille — gardez le TIFF, téléversez le GIF. L’original n’est jamais modifié par sa conversion.

Le GIF stocke ses dimensions en seize bits, donc une image peut faire jusqu’à 65 535 pixels sur une arête. C’est quatre fois le plafond de WebP à 16 383 et confortablement au-dessus de tout ce qu’un scanner de documents produit, donc contrairement à la voie WebP cette conversion n’échoue pas sur un grand scan.

Ce qui mord sur un grand scan, c’est la mémoire et la patience plutôt que le format. Quantifier une image de 20 000 pixels de large veut dire examiner plusieurs centaines de millions de pixels dans l’onglet, et le GIF résultant, tout en étant beaucoup plus petit que le TIFF, restera un fichier substantiel que le système de destination peut lui-même refuser pour des raisons de taille. Réduire la largeur d’abord — l’option est sur le même panneau — est en général le geste sensé, et un document regardé sur un écran a rarement besoin de plus de 2 000 pixels de large.

PNG, dans presque tous les cas. TIFF en PNG garde chaque pixel sans palette du tout, est lu par tout ce qui a été écrit depuis les années 1990, et sur du contenu scanné plat est en général aussi plus petit que le GIF — l’échantillon type capture d’écran de ce site fait 2 608 octets en PNG contre 6 326 en GIF. Si la liste acceptée inclut le PNG, il n’y a pas d’argument pour le GIF.

Si la destination est une page web que vous contrôlez, TIFF en WebP est encore plus petit et universellement supporté. Si le scan est un document qui sera classé ou transmis, TIFF en PDF garde toutes les pages et est ce que le destinataire attend. Le GIF est la bonne réponse seulement quand une liste quelque part le dit, et cette page est écrite en supposant qu’une liste le fait.

Toute la conversion tourne dans l’onglet : utif2 décode le TIFF, gifenc construit la palette et écrit le GIF, et tous deux ne sont chargés que quand ils sont nécessaires. Rien du fichier n’est téléversé, ce qui est le point quand les scans sont des archives, de la correspondance ou quoi que ce soit avec un nom dessus.

La limite gratuite est de 100 Mo par fichier, ce qui représente à peu près un scan A4 couleur à 600 dpi non compressé. Les lots fonctionnent de la même manière — déposez un dossier, regardez les lignes, prenez un ZIP — et le quantificateur est l’étape lente, donc une série de grands scans couleur prend notablement plus de temps qu’une série de bitonaux. Convertir quelques fichiers d’abord et les vérifier dans le système de destination vaut les deux minutes avant de confier tout un dossier à un format que personne ne choisirait librement.