Réparer une capture d'écran PNG endommagée

Tout PNG commence par la même signature de 8 octets — 89 50 4E 47 0D 0A 1A 0A —, une empreinte délibérément truffée de pièges : l'octet à bit de poids fort 0x89 détecte les canaux limités à 7 bits, le 0D 0A et le 0A isolé détectent la conversion de fin de ligne, et le 1A (fin de fichier sous DOS) arrête une commande type négligente avant qu'elle ne déverse le reste. Vient ensuite une série de chunks, chacun formant un paquet bien rangé : une longueur de 4 octets en big-endian, un type ASCII de 4 octets, les données, puis un CRC-32 de 4 octets calculé sur le type et les données (jamais la longueur) à l'aide du polynôme réfléchi standard 0xEDB88320.

Trois chunks portent l'image. IHDR vient en premier et occupe toujours 13 octets : largeur (u32), hauteur (u32), puis des octets isolés pour la profondeur de bits, le type de couleur, la méthode de compression, la méthode de filtrage et la méthode d'entrelacement. Une capture issue d'un système d'exploitation moderne est presque toujours en 8 bits, non entrelacée, avec un type de couleur 2 (couleurs réelles) ou 6 (couleurs réelles avec alpha). IDAT contient l'image, parfois répartie sur plusieurs chunks IDAT consécutifs ; à l'intérieur se trouve un flux zlib (octet d'en-tête 0x78) de lignes de balayage filtrées compressées avec DEFLATE — chaque rangée précédée d'un octet de filtre 0–4 (None, Sub, Up, Average, Paeth), écrites de haut en bas. IEND est le marqueur de fin vide, doté d'un CRC fixe de AE 42 60 82.

Les captures portent aussi des chunks auxiliaires reconnaissables — leur première lettre en minuscule les désigne comme facultatifs — tels que pHYs (densité de pixels, pour qu'une capture Retina indique son échelle), iCCP ou sRGB (profil colorimétrique), tEXt/eXIf (métadonnées estampillées par l'outil de capture). Ceux-ci peuvent être endommagés ou disparaître sans perdre un seul pixel, car un décodeur est autorisé à ignorer tout chunk auxiliaire qu'il ne comprend pas.

Comme chaque chunk se vérifie lui-même, toute une catégorie de dégâts du PNG a une réponse connaissable plutôt qu'une supposition :

• Somme erronée, données correctes. La fausse alerte la plus courante : les octets d'un chunk sont intacts mais son CRC stocké ne correspond plus, si bien que les décodeurs stricts (et pngcheck) rejettent le fichier avec CRC error in chunk IDAT. Recalculer le CRC-32 à partir des données et le réécrire revalide le fichier avec zéro perte : la somme de contrôle était la seule chose défaillante.
• Dimensions à zéro ou brouillées. Si la largeur ou la hauteur de l'IHDR est à zéro, aucun décodeur ne peut allouer de zone de dessin et le fichier ne s'ouvre pas. Mais l'IHDR porte son propre CRC, calculé à l'époque où les nombres étaient corrects. Cela permet à la réparation de retrouver la géométrie par force brute : essayer des valeurs candidates de largeur/hauteur, recalculer le CRC du chunk pour chacune, et s'arrêter dès qu'il correspond à la valeur stockée. Les dimensions d'origine tombent directement de l'arithmétique — sans deviner.
• Corruption par sauts de ligne / mode texte. Une capture passée par un client FTP en mode ASCII, une passerelle de messagerie ou un script qui l'a réécrite comme du texte remplace chaque 0D 0A par un 0A isolé (ou l'inverse), corrompant des octets dans tout le fichier. La signature est conçue pour détecter précisément ce cas, et quand la substitution est cohérente elle peut être annulée octet par octet.
• IEND absent ou cassé. Un fichier par ailleurs complet mais qui a perdu son marqueur de fin déclenche des avertissements de type « fichier incomplet » ; réécrire un IEND valide permet à un décodeur strict d'accepter l'image qui est déjà entière.

Les limites honnêtes commencent là où les données de pixels elles-mêmes ne sont plus là, et les captures tombent dans les deux cas.

Troncature : le haut revient. C'est la manière la plus fréquente dont une capture se casse : un enregistrement interrompu par un disque plein, une copie coupée au débranchement d'un téléphone, une synchronisation dans le cloud arrêtée à 80 pour cent. L'avant du fichier est intact et la fin — d'ordinaire y compris l'IEND — est tout simplement absente. Comme les lignes de balayage s'écrivent de haut en bas, un PNG tronqué se récupère dans la partie supérieure de l'image : de vrais pixels jusqu'à l'endroit où les données s'arrêtent. La réparation réécrit une clôture valide pour qu'un décodeur accepte le fichier et dessine ce qui a survécu. Les rangées situées sous la coupure ne sont pas endommagées, elles sont absentes : aucun outil ne peut donc les rendre — le résultat est un fichier partiel honnête.

Dégât en plein milieu de l'IDAT : le bas est du bruit. Quand la corruption tombe à l'intérieur du flux DEFLATE plutôt qu'à la fin, la raison pour laquelle elle est irrécupérable tient à DEFLATE lui-même : c'est un flux continu unique où chaque partie dépend de la précédente, sans marqueurs périodiques permettant de se resynchroniser. Dès que le décodeur bute sur le mauvais octet, il perd le fil (zlib signale incorrect data check / invalid distance too far back), et tout ce qui suit se décode comme du bruit. Un seul octet altéré à mi-hauteur peut vous coûter toutes les rangées en dessous, pas seulement une ligne : l'image est nette au-dessus de l'impact et illisible en dessous. C'est pourquoi une capture s'ouvre avec un haut net et une moitié inférieure floue ou grise, exactement la même forme de résultat qu'un JPEG tronqué.

Comparez avec les formats qui conservent un index séparé de leurs données — le moov d'une vidéo QuickTime, un b-tree de SQLite —, où reconstruire la carte sauve le fichier entier. Le PNG range ses pixels dans un unique flux DEFLATE indivisible : une blessure à mi-hauteur est donc permanente en dessous de la coupure.