Я имею дело с большим архивом спутниковых снимков Земли, каждый из которых сделан с интервалом в 15 минут над одной и той же областью, поэтому они довольно похожи друг на друга. Два смежных выглядят так:
Видеоалгоритмы очень хорошо сжимают несколько похожих изображений. Однако эти изображения слишком велики для видео (10848x10848), а использование видеокодеров удалит метаданные изображений, поэтому их извлечение и восстановление метаданных будет обременительным, даже если я найду видеокодер для работы с такими большими изображениями.
Для проведения тестов я уменьшил 96 изображений одного дня до 1080x1080 пикселей, что в сумме составляет 40,1 МБ, и попробовал разные варианты сжатия, получив следующие результаты:
- zip-архив: 39,8 МБ
- rar: 39,8 МБ
- 7z : 39,6 МБ
- tar.bz2: 39,7 МБ
- zpaq v7.14: 38,3 МБ
- fp8 v2: 32,5 МБ
- paq8pxd v45:30,9 МБ
Предполагается, что последние три варианта гораздо лучше используют контекст и действительно работают лучше, чем традиционное сжатие, но степень сжатия все еще довольно плохая по сравнению с видео mp4, размер которого может достигать 15 МБ или даже меньше, сохраняя качество изображения.
Однако ни один из алгоритмов, используемых этими утилитами сжатия, похоже, не использует преимущества сходства изображений, как это делает сжатие видео. Фактически, использованиеpackJPG, которые сжимают каждое изображение по отдельности, весь набор уменьшается до 32,9 МБ, что довольно близко к fp8 и paq8pxd, но при этом не используется сходство между изображениями (поскольку каждое изображение сжимается по отдельности).
В другом эксперименте я рассчитал в Matlab разницу двух изображений выше, и она выглядит следующим образом:
Сжатие обоих исходных изображений (219,5 + 217,0 = 436,5 КБ в общей сложности) с помощью fp8 уменьшает их до 350,0 КБ (80%), но сжатие одного из них и изображения-разницы (как jpg того же качества и с использованием 122,5 КБ) приводит к файлу размером 270,8 КБ (62%), так что снова (как показало сравнение mp4 и packJPG), fp8, похоже, не слишком извлекает выгоду из сходства. Даже сжатые с помощью rar, одно изображение плюс разница работают лучше, чем fp8 на исходных изображениях. В этом случае rar уменьшает его до 333,6 КБ (76%).
Я думаю, что должно быть хорошее решение для сжатия этой проблемы, так как я могу представить себе множество приложений. Помимо моего конкретного случая, я думаю, что у многих профессиональных фотографов есть много похожих снимков из-за последовательной съемки или покадровой съемки и т. д. Все случаи, которые выиграют от такого сжатия.
Кроме того, мне не требуется сжатие без потерь, по крайней мере, для данных изображения (метаданные должны быть сохранены).
Так... Существует ли метод сжатия, который использует сходство между сжатыми изображениями?
Два изображения вышеуказанного теста можно загрузитьздесь, и 96 изображений первого тестаздесь.
решение1
Я не знаю конкретного ПО, которое это делает, но есть некоторые исследования на эту тему. Например, см. статьиСжатие наборов похожих изображенийСами Айт-Аудиа, Абдельхалим Габис, Амина Наими иСжатие наборов похожих изображений с использованием гибридной модели сжатияЦзянь-Дер Ли, Шу-Йен Вань, Чемг-Мин Ма, Руй-Фэн У.
На более практическом уровне вы можете расширить свою технику вычитания, например, написав скрипт, который используетImageMagickдля вычисления разницы между последовательными изображениями, сохраняя результат как jpeg (или сжатый png, если вы хотите без потерь). Вы получите одно базовое изображение и набор сжатых "дельта"-изображений, которые должны быть намного меньше. Для вычисления разницы с помощью 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
Для повторного вычисления путем добавления:
convert image1.png difference-2-1.png -compose Plus -composite image2-reconstructed.png
(Вы можете сделать то же самое, используя jpg, и сэкономить много места).
решение2
В надежде, что другие люди, желающие сжать похожие изображения/PNG-файлы и нашедшие их здесь через поиск:
Я не уверен, как вариант использования, над которым я работал, будет применяться к фотографиям ops, поскольку ссылка больше не работает. Мой вариант использования был похож, но не тот же самый — я хотел сжать скриншоты компьютерных программ, которые очень похожи, поэтому потенциально гораздо более сжимаемы, чем просто архивация файлов PNG. Я не смог найти решения с помощью поиска, поэтому придумал свое собственное и в итоге получил безумный коэффициент сжатия 4,4% (в отличие от 96% при наивном использовании простого сжатия PNG):
Мой набор данных состоял из 300 файлов PNG с разрешением 1920x1080 и исходным размером 431,8 МБ, которые были сжаты до 417,4 МБ с лучшими настройками, которые я смог найти для bz2, 7z и подобных инструментов. Насколько я понимаю, исходные файлы не были идеально сжаты на уровне PNG, поскольку различные инструменты минимизации PNG смогли уменьшить исходный размер примерно с 1,4 МБ до 900 КБ на файл.
Я думал, что проблема в том, что инструменты сжатия не могут понять, что данные уже сжаты, и что небольшие изменения в исходных данных могут привести к совершенно другим сжатым файлам. Поэтому я распаковал файлы, используя ffmpegнастройки, которые, как я понимаю, не приводят к потере данных:
for FILE in screenshot-2024*; do ffmpeg -loglevel error -i $FILE -vframes 1 -compression_algo raw -pix_fmt rgb24 $FILE.tiff; done
Это увеличило размеры отдельных файлов с 1,4 до 6 МБ, но сжатие с помощью 7z/LZMA2 привело к получению файла невероятно малого размера — 19 175 127 байт, что означает сжатие всего до 4,4% от исходного размера.
Обратное преобразование .tiffфайлов .pngможно выполнить с помощью:
for FILE in screenshot-2024*.tiff; do ffmpeg -loglevel error -i $FILE $FILE.png; done
Конечно, можно исправить дублирующиеся окончания файлов, но в этом случае исходные исходники не будут перезаписаны во время тестирования.
Для сжатия мы использовали следующие настройки, причем эта Solid block sizeнастройка, по-видимому, оказывает наибольшее влияние на размер выходного файла:
- Уровень сжатия: 9/Ультра
- Метод сжатия: LZMA2
- Размер словаря: 512 МБ
- Размер слова: 256
- Размер сплошного блока: 512 МБ
- Использование памяти для сжатия: 12 ГБ
Поскольку нашей целью было долгосрочное хранение, дополнительные обручи и время сжатия не имели большого значения, конечно, ваш пробег может отличаться.