Se trata de un gran archivo de imágenes satelitales de la Tierra, cada una de ellas tomadas con 15 minutos de diferencia sobre la misma zona, por lo que son bastante similares entre sí. Dos contiguos se ven así:
Los algoritmos de vídeo funcionan muy bien comprimiendo varias imágenes similares. Sin embargo, estas imágenes son demasiado grandes para video (10848x10848) y el uso de codificadores de video eliminaría los metadatos de las imágenes, por lo que extraerlas y restaurar los metadatos sería engorroso incluso si consigo que un codificador de video funcione con imágenes tan grandes.
Para hacer algunas pruebas he reducido las 96 imágenes de un día a 1080x1080 píxeles, totalizando 40,1 MB y probé diferentes compresiones con los siguientes resultados:
- zip: 39,8 MB
- rar: 39,8MB
- 7z: 39,6MB
- tar.bz2: 39,7 MB
- zpaq v7.14: 38,3MB
- fp8v2: 32,5MB
- paq8pxd v45:30,9MB
Se supone que los últimos tres aprovechan mucho mejor el contexto y, de hecho, funcionan mejor que la compresión tradicional, pero la relación de compresión sigue siendo bastante pobre en comparación con el vídeo mp4 que puede llevarlo a 15 MB o incluso menos preservando la calidad de la imagen.
Sin embargo, ninguno de los algoritmos utilizados por esas utilidades de compresión parece aprovechar la similitud de las imágenes como lo hace la compresión de video. De hecho, usandopaqueteJPG, que comprimen cada imagen por separado, el conjunto se reduce a 32,9 MB, bastante cerca de fp8 y paq8pxd pero sin aprovechar en absoluto las similitudes entre imágenes (porque cada imagen se comprime individualmente).
En otro experimento, calculé en Matlab la diferencia de las dos imágenes de arriba y se ve así:
Al comprimir ambas imágenes originales (219,5 + 217,0 = 436,5 kB en total) con fp8, las reduce a 350,0 kB (80%), pero al comprimir una de ellas y la imagen diferente (como un jpg de la misma calidad y usando 122,5 kB), el resultado en un archivo de 270,8 kB (62%), así que nuevamente (como lo revela la comparación de mp4 y packJPG), fp8 no parece aprovechar mucho las similitudes. Incluso comprimida con rar, una imagen más la diferencia funciona mejor que fp8 en las imágenes originales. En ese caso, rar lo baja a 333,6 kB (76%).
Supongo que debe haber una buena solución de compresión para este problema, ya que puedo imaginar muchas aplicaciones. Aparte de mi caso particular, supongo que muchos fotógrafos profesionales tienen muchas tomas similares debido al disparo secuencial, o imágenes en lapso de tiempo, etc. Todos los casos se beneficiarían de dicha compresión.
Además, no necesito una compresión sin pérdidas, al menos no para los datos de la imagen (los metadatos deben conservarse).
Entonces... ¿Existe algún método de compresión que aproveche las similitudes entre las imágenes comprimidas?
Las dos imágenes de la prueba anterior se pueden descargar.aquí, y las 96 imágenes de la primera prueba.aquí.
Respuesta1
No conozco ningún software específico que haga esto, pero hay algunas investigaciones sobre el tema. Por ejemplo, vea los artículos.Compresión de conjuntos de imágenes similarespor Samy Ait-Aoudia, Abdelhalim Gabis, Amina Naimi yComprimir conjuntos de imágenes similares utilizando un modelo de compresión híbridopor Jiann-Der Lee, Shu-Yen Wan, Chemg-Min Ma, Rui-Feng Wu.
En un nivel más práctico, podrías ampliar tu técnica de resta, por ejemplo, escribiendo un guión que utiliceImagenMagiapara calcular la diferencia entre imágenes consecutivas, guardando el resultado como un jpeg (o un png comprimido si lo desea sin pérdidas). Obtendrá una imagen base y un conjunto de imágenes "delta" comprimidas que deberían ser mucho más pequeñas. Para calcular la diferencia usando ImageMagick:
convert image2.png image1.png -compose MinusSrc -composite -depth 24 -define png:compression-filter=2 -define png:compression-level=9 -define png:compression-strategy=1 difference-2-1.png
Para volver a calcular agregando nuevamente:
convert image1.png difference-2-1.png -compose Plus -composite image2-reconstructed.png
(Puedes hacer lo mismo usando jpg y ahorrar mucho espacio).
Respuesta2
Con la esperanza de que otras personas que quieran comprimir imágenes/PNG similares y encuentren su camino hasta aquí mediante búsquedas:
No estoy seguro de cómo se aplicaría el caso de uso en el que trabajé para comparar a las fotografías de operaciones, ya que el enlace ya no funciona. Mi caso de uso fue similar pero no igual: estaba buscando comprimir capturas de pantalla de programas de computadora que son muy similares, por lo que potencialmente son mucho más comprimibles que simplemente comprimir los archivos PNG. No pude encontrar ninguna solución mediante la búsqueda, así que se me ocurrió la mía propia y terminé con una increíble relación de compresión del 4,4% (a diferencia del 96% mediante el uso ingenuo de simplemente comprimir los PNG):
Mi conjunto de datos eran 300 archivos PNG a 1920x1080, con un tamaño sin formato de 431,8 MB que se comprimía a solo 417,4 MB con la mejor configuración que pude encontrar para bz2, 7z y herramientas similares. Tengo entendido que los archivos fuente no estaban idealmente comprimidos a nivel PNG, ya que varias herramientas minimizadoras de PNG lograron reducir el tamaño sin formato de aproximadamente 1,4 MB a 900 kb por archivo.
Mi pensamiento era que el problema era que las herramientas de compresión no podían darse cuenta de que los datos ya estaban comprimidos y que pequeños cambios en los datos sin procesar podían generar archivos comprimidos muy diferentes. Entonces descomprimí los archivos usando ffmpegconfiguraciones que, según tengo entendido, no resultan en ninguna pérdida de datos:
for FILE in screenshot-2024*; do ffmpeg -loglevel error -i $FILE -vframes 1 -compression_algo raw -pix_fmt rgb24 $FILE.tiff; done
Esto aumentó el tamaño de los archivos individuales de 1,4 a 6 MB, pero la compresión con 7z/LZMA2 dio como resultado un archivo resultante con un tamaño increíblemente bajo de 19.175.127 bytes, lo que significa una compresión de solo el 4,4% del tamaño original.
La reconversión de los .tiffarchivos .pngse puede realizar con:
for FILE in screenshot-2024*.tiff; do ffmpeg -loglevel error -i $FILE $FILE.png; done
Por supuesto, los finales de archivos duplicados se pueden corregir, pero de esta manera no sobrescribirán las fuentes originales durante la prueba.
Las configuraciones que utilizamos para la compresión fueron las siguientes; y la Solid block sizeconfiguración aparentemente tiene el mayor efecto en el tamaño de salida:
- Nivel de compresión: 9/Ultra
- Método de compresión: LZMA2
- Tamaño del diccionario: 512 MB
- Tamaño de palabra: 256
- Tamaño de bloque sólido: 512 MB
- Uso de memoria para comprimir: 12 GB
Dado que para nosotros el objetivo era el almacenamiento a largo plazo, los aros adicionales y el tiempo de compresión no fueron un factor importante; por supuesto, su kilometraje puede variar.