Riparare uno screenshot PNG danneggiato

Ogni PNG si apre con la stessa firma di 8 byte —89 50 4E 47 0D 0A 1A 0A—, un'impronta deliberatamente carica di trappole: il byte con il bit alto 0x89 intercetta i canali a soli 7 bit, il 0D 0A e l'0A isolato intercettano la conversione di fine riga, e l'1A (fine file di DOS) ferma un type distratto prima che riversi il resto. Dopo viene una serie di chunk, ognuno un pacchetto ordinato: una lunghezza di 4 byte big-endian, un tipo ASCII di 4 byte, i dati e un CRC-32 di 4 byte calcolato sul tipo e sui dati (mai sulla lunghezza) con il polinomio riflesso standard 0xEDB88320.

Tre chunk trasportano l'immagine. IHDR viene per primo e occupa sempre 13 byte: larghezza (u32), altezza (u32), poi byte singoli per la profondità di bit, il tipo di colore, il metodo di compressione, il metodo di filtro e il metodo di interlacciamento. Lo screenshot di un sistema operativo moderno è quasi sempre a 8 bit, non interlacciato, con tipo di colore 2 (colore reale) o 6 (colore reale con alfa). IDAT contiene l'immagine, a volte suddivisa in più chunk IDAT consecutivi; al suo interno c'è un flusso zlib (byte di intestazione 0x78) di linee di scansione filtrate compresse con DEFLATE — ogni riga preceduta da un byte di filtro 0–4 (None, Sub, Up, Average, Paeth), scritte dall'alto verso il basso. IEND è il marcatore di fine vuoto, con un CRC fisso di AE 42 60 82.

Gli screenshot portano anche chunk ausiliari riconoscibili —la prima lettera minuscola li marca come opzionali— come pHYs (densità di pixel, così una cattura Retina indica la sua scala), iCCP o sRGB (profilo colore), tEXt/eXIf (metadati che lo strumento di cattura imprime). Questi possono danneggiarsi o andare persi senza perdere un solo pixel, perché a un decodificatore è consentito saltare qualsiasi chunk ausiliario che non comprende.

Poiché ogni chunk si autoverifica, un'intera classe di danni del PNG ha una risposta conoscibile invece di una congettura:

• Somma errata, dati corretti. Il falso allarme più comune: i byte di un chunk sono intatti ma il suo CRC memorizzato non coincide più, così i decodificatori severi (e pngcheck) rifiutano il file con CRC error in chunk IDAT. Ricalcolare il CRC-32 a partire dai dati e riscriverlo rende di nuovo valido il file con zero perdite: la somma di controllo era l'unica cosa sbagliata.
• Dimensioni azzerate o alterate. Se la larghezza o l'altezza di IHDR è azzerata, nessun decodificatore può allocare una tela e il file non si apre. Ma IHDR porta il proprio CRC, calcolato quando i numeri erano corretti. Questo permette alla riparazione di forzare la geometria a forza bruta: provare valori candidati di larghezza/altezza, ricalcolare il CRC del chunk per ciascuno e fermarsi quando coincide con il valore memorizzato. Le dimensioni originali escono direttamente dall'aritmetica — senza indovinare.
• Corruzione da fine riga / modalità testo. Uno screenshot passato attraverso un client FTP in modalità ASCII, un ponte di chat o uno script che l'ha riscritto come testo cambia ogni 0D 0A in un 0A isolato (o viceversa), corrompendo byte in tutto il file. La firma è progettata per rilevare esattamente questo, e quando la sostituzione è coerente si può invertire byte per byte.
• IEND assente o rotto. Un file per il resto completo ma che ha perso il suo marcatore di fine fa scattare avvisi di "file incompleto"; riscrivere un IEND valido permette a un decodificatore severo di accettare l'immagine che è già tutta lì.

I limiti onesti iniziano dove i dati dei pixel stessi non ci sono più, e gli screenshot cadono in entrambi i casi.

Troncamento: la parte superiore torna. È il modo più comune in cui uno screenshot si rompe: un salvataggio interrotto da un disco pieno, una copia tagliata quando un telefono viene scollegato, una sincronizzazione cloud che si è fermata all'80 per cento. La parte anteriore del file è intatta e la coda —di solito incluso IEND— è semplicemente assente. Poiché le linee di scansione sono scritte dall'alto verso il basso, un PNG troncato si recupera nella parte superiore dell'immagine: pixel reali fino a dove finiscono i dati. La riparazione riscrive una chiusura valida affinché un decodificatore accetti il file e disegni ciò che è sopravvissuto. Le righe sotto il taglio non sono danneggiate, sono assenti, quindi nessuno strumento può restituirle: il risultato è un parziale onesto.

Danno a metà di IDAT: la parte inferiore è rumore. Quando la corruzione cade dentro il flusso DEFLATE invece che alla fine, la ragione per cui è irrecuperabile è lo stesso DEFLATE: è un unico flusso continuo in cui ogni parte dipende da ciò che l'ha preceduta, senza marcatori periodici su cui risincronizzarsi. Non appena il decodificatore incontra il byte danneggiato perde il filo (zlib segnala incorrect data check / invalid distance too far back), e tutto ciò che viene dopo si decodifica come rumore. Un solo byte alterato a metà altezza può costare ogni riga sottostante, non solo una linea: l'immagine è pulita sopra il colpo ed è spazzatura sotto. Ecco perché uno screenshot si apre con una parte superiore nitida e una metà inferiore sbavata o grigia, la stessa forma di risultato che dà un JPEG troncato.

Confrontalo con i formati che tengono un indice separato dai loro dati —l'atomo moov di un video QuickTime, un b-tree di SQLite—, dove ricostruire la mappa recupera l'intero file. Il PNG conserva i suoi pixel in un unico flusso DEFLATE indivisibile, quindi una ferita a metà altezza è permanente sotto il taglio.