问题描述
我希望在一系列相似的灰度图像中具有最佳的压缩率。我注意到我需要一个绝对无损的解决方案（这意味着我应该能够使用哈希算法进行检查）。
我尝试过的事情
我的想法是将图像转换为视频，因为图像之间存在年代顺序。编码算法将使用并非所有场景都在2张图片之间变化的事实进行压缩。所以我尝试使用ffmpeg，但是由于sRGB-> YUV颜色空间压缩，我遇到了几个问题。我一无所知，但这似乎是一场噩梦。
使用的代码示例：
ffmpeg -i %04d.png -c:v libx265 -crf 0 video.mp4 #To convert into video
ffmpeg -i video.mp4 %04d.png #To recover images
我的第二个想法是用imagemagik手工完成。因此，我以第一张图像作为参考，并创建了一个新图像，该图像是image1和image2之间的区别。然后，我尝试将差异图像与图像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/
解决方法
我尝试了一些关于您的数据集的想法，并总结了以下发现的内容。我的计算和百分比假设578kB是代表图像大小。
方法1-粉碎-69％
我只是在您的其中一张图片上运行了pngcrush，
pngcrush -bruteforce input.png crushed.png
输出大小为400kB，因此您的映像现在仅占用磁盘上原始空间的69％。
方法2-旋转并压碎-34％
我将您的图片旋转了90度并粉碎了结果：
magick input.png -rotate 90 result.png
pngcrush -bruteforce result.png crushed.png
旋转的粉碎图像占据了磁盘上原始空间的34％。
方法3-旋转和差异-24％
我使用ImageMagick旋转了您的图像，然后对系列中的两个相邻图像进行了差分处理并保存了结果。然后，我将其“ pngcrushed”了142kB，即原始空间的24％。
方法4-合并为RGB-28％
我将您的三个单通道图像合并为一个3通道RGB图像，并png粉碎了结果：
magick 000[123].png -combine result.png
pngcrush -bruteforce result.png crushed.png
这导致一个490kB文件包含3张图像，即每张图像163kB或原始大小的28％。
我怀疑具有“运动”估计/检测功能的视频如果能够无损地进行下去，将会获得最佳效果。
,