Reparar una captura de pantalla PNG dañada

Todo PNG empieza con la misma firma de 8 bytes —89 50 4E 47 0D 0A 1A 0A—, una huella deliberadamente cargada de trampas: el byte con el bit alto 0x89 detecta canales de solo 7 bits, el 0D 0A y el 0A suelto detectan la conversión de fin de línea, y el 1A (fin de archivo de DOS) frena a un type descuidado antes de que vuelque el resto. Después viene una serie de chunks, cada uno un paquete ordenado: una longitud de 4 bytes big-endian, un tipo ASCII de 4 bytes, los datos y un CRC-32 de 4 bytes calculado sobre el tipo y los datos (nunca la longitud) con el polinomio reflejado estándar 0xEDB88320.

Tres chunks llevan la imagen. IHDR va primero y siempre ocupa 13 bytes: anchura (u32), altura (u32) y luego bytes sueltos para la profundidad de bits, el tipo de color, el método de compresión, el método de filtro y el método de entrelazado. Una captura de un sistema operativo moderno es casi siempre de 8 bits, sin entrelazar, con tipo de color 2 (color verdadero) o 6 (color verdadero con alfa). IDAT contiene la imagen, a veces repartida en varios chunks IDAT consecutivos; dentro hay un flujo zlib (byte de cabecera 0x78) de líneas de barrido filtradas comprimidas con DEFLATE — cada fila precedida por un byte de filtro 0–4 (None, Sub, Up, Average, Paeth), escritas de arriba abajo. IEND es el marcador de final vacío, con un CRC fijo de AE 42 60 82.

Las capturas también llevan chunks auxiliares reconocibles —la primera letra en minúscula los marca como opcionales— como pHYs (densidad de píxeles, para que una captura Retina indique su escala), iCCP o sRGB (perfil de color), tEXt/eXIf (metadatos que estampa la herramienta de captura). Estos pueden dañarse o perderse sin perder un solo píxel, porque a un decodificador se le permite saltarse cualquier chunk auxiliar que no entienda.

Como cada chunk se autoverifica, toda una clase de daños del PNG tiene una respuesta conocible en lugar de una conjetura:

• Suma incorrecta, datos correctos. La falsa alarma más común: los bytes de un chunk están intactos pero su CRC almacenado ya no coincide, así que los decodificadores estrictos (y pngcheck) rechazan el archivo con CRC error in chunk IDAT. Recalcular el CRC-32 a partir de los datos y reescribirlo vuelve a validar el archivo con cero pérdidas: la suma de comprobación era lo único que fallaba.
• Dimensiones a cero o alteradas. Si la anchura o la altura de IHDR está a cero, ningún decodificador puede reservar un lienzo y el archivo no abre. Pero IHDR lleva su propio CRC, calculado cuando los números eran correctos. Eso permite a la reparación forzar la geometría por fuerza bruta: probar valores candidatos de anchura/altura, recalcular el CRC del chunk para cada uno y detenerse cuando coincide con el valor almacenado. Las dimensiones originales salen directamente de la aritmética — sin adivinar.
• Corrupción por saltos de línea / modo texto. Una captura pasada por un cliente FTP en modo ASCII, un puente de chat o un script que la reescribió como texto cambia cada 0D 0A por un 0A suelto (o al revés), corrompiendo bytes por todo el archivo. La firma está diseñada para detectar justamente esto, y cuando la sustitución es consistente se puede revertir byte a byte.
• IEND ausente o roto. Un archivo por lo demás completo pero que perdió su marcador de final dispara avisos de "archivo incompleto"; reescribir un IEND válido permite a un decodificador estricto aceptar la imagen que ya está entera.

Los límites honestos empiezan donde los propios datos de píxeles ya no están, y las capturas caen en ambos casos.

Truncamiento: la parte de arriba vuelve. Es la forma más común en que se rompe una captura: un guardado interrumpido por un disco lleno, una copia cortada al desconectar un móvil, una sincronización en la nube que se detuvo al 80 por ciento. La parte delantera del archivo está intacta y la cola —normalmente incluido IEND— simplemente falta. Como las líneas de barrido se escriben de arriba abajo, un PNG truncado se rescata en la parte superior de la imagen: píxeles reales hasta donde terminan los datos. La reparación reescribe un cierre válido para que un decodificador acepte el archivo y dibuje lo que sobrevivió. Las filas por debajo del corte no están dañadas, están ausentes, así que ninguna herramienta puede devolverlas: el resultado es un parcial honesto.

Daño en mitad de IDAT: la parte de abajo es ruido. Cuando la corrupción cae dentro del flujo DEFLATE en lugar de al final, la razón de que sea irrecuperable es el propio DEFLATE: es un único flujo continuo donde cada parte depende de lo anterior, sin marcadores periódicos con los que resincronizar. En cuanto el decodificador topa con el byte malo pierde el hilo (zlib informa de incorrect data check / invalid distance too far back), y todo lo que viene después se decodifica como ruido. Un solo byte alterado a media altura puede costarte todas las filas de debajo, no solo una línea: la imagen está limpia por encima del golpe y es basura por debajo. Por eso una captura abre con una parte superior nítida y una mitad inferior emborronada o gris, la misma forma de resultado que da un JPEG truncado.

Compáralo con los formatos que mantienen un índice separado de sus datos —el moov de un vídeo QuickTime, un b-tree de SQLite—, donde reconstruir el mapa rescata el archivo entero. El PNG guarda sus píxeles en un único flujo DEFLATE indivisible, así que una herida a media altura es permanente por debajo del corte.