Блог

Я хотел бы иметь наилучшую степень сжатия последовательности похожих изображений в оттенках серого. Я отмечаю, что мне нужно решение без абсолютных потерь (это означает, что я должен иметь возможность проверить его с помощью алгоритма хеширования).

Что я пробовал

У меня была идея преобразовать мои изображения в видео, потому что между изображениями существует хронология. Алгоритм кодирования будет сжимать, используя тот факт, что не все сцены меняются между 2 изображениями. Итак, я попытался использовать ffmpeg, но у меня возникло несколько проблем из-за сжатия цветового пространства sRGB -> YUV. Я не все понял, но это похоже на кошмар.

Пример используемого кода :

 ffmpeg -i d.png -c:v libx265 -crf 0 video.mp4 #To convert into video
ffmpeg -i video.mp4 d.png #To recover images

  

Моей второй идеей было сделать это вручную с помощью imagemagik. Поэтому я взял первое изображение в качестве эталона и создал новое изображение, которое является разницей между изображением1 и изображением2. Затем я попытался добавить изображение разницы к изображению 1 (пытаясь восстановить изображение 2), но это не сработало. Заметив размер воссозданного изображения, становится ясно, что изображение не то же самое. Я думаю, что во время процесса произошло нежелательное сжатие.

Пример используемого кода :

 composite -compose difference 0001.png 0002.png diff.png #To create the diff image
composite -compose difference 0001.png diff.png recover.png #To recover image 2
  

У вас есть какие-либо идеи о моей проблеме?
И почему мне не удается выполнить идеальное восстановление с помощью iamgemagik?

Спасибо

Вот 20 образцов изображений: https://cloud.damien.gdn/d/f1a7954a557441989432 /

Я попробовал несколько идей с вашим набором данных и обобщил то, что нашел ниже. Мои расчеты и проценты предполагают, что 578 КБ является репрезентативным размером изображения.

Способ 1 — раздавить — 69%

Я только что запустил pngcrush одно из ваших изображений следующим образом:

 pngcrush -bruteforce input.png crushed.png
  

Размер выходного файла составлял 400 КБ, поэтому ваше изображение теперь занимает только 69% исходного места на диске.

Способ 2 — поворот и сжатие — 34%

Я повернул ваши изображения на 90 градусов и изменил результат:

 magick input.png -rotate 90 result.png
pngcrush -bruteforce result.png crushed.png
  

Повернутое измельченное изображение занимает 34% исходного места на диске.

Способ 3 — поворот и разница — 24%

Я поворачивал ваши изображения с помощью ImageMagick, затем различал два соседних изображения в серии и сохранял результат. Затем я «pngcrushed», что привело к 142 КБ, или 24% исходного пространства.

Способ 4 — объединенный в RGB — 28%

Я объединил три ваших одноканальных изображения в 3-канальное RGB-изображение и png-обработал результат:

 magick 000[123].png -combine result.png
pngcrush -bruteforce result.png crushed.png
  

В результате получился файл размером 490 КБ, содержащий 3 изображения, т.е. 163 КБ на изображение или 28% от исходного размера.

Я подозреваю, что видео с оценкой / обнаружением «движения» даст наилучшие результаты, если вы сможете сделать это без потерь.

Вы можете получить некоторый выигрыш от MNG, который предназначен для сжатия анимации без потерь. Вы можете использовать libmng, чтобы попробовать это.