压缩三张包含时间冗余的单独 jpeg 图片？
我正在将嵌入式设备与相机模块连接起来，每次触发它时，相机模块都会返回单个 jpeg 压缩帧。
我想连续拍摄三张照片（大约每 1/4 秒 1 帧）并将图像进一步压缩到单个文件中。这里的假设是存在大量时间冗余，因此三个帧之间有大量压缩空间（与发送三个单独的 jpeg 图像相比）。
我将在没有任何库和操作系统的情况下用 C 在嵌入式设备上实现该解决方案。
相机将在一个几乎没有移动的区域拍照（背景中没有游客或屏幕，可能是一棵树枝摇曳的树），所以我认为我关于冗余的假设是相当可靠的。
当文件最终在 PC/Mac 上查看时，我不介意必须编写一些东西来提取三个帧（因此它可能是一个非标准的障碍）
所以我想实际的问题是：鉴于这三个图像已经是 JPEG 格式，将它们压缩在一起的最佳方法是什么（可能会转换回原始图像，但如果我没有的话......）
I am interfacing an embedded device with a camera module that returns a single jpeg compressed frame each time I trigger it.
I would like to take three successive shots (approx 1 frame per 1/4 second) and further compress the images into a single file. The assumption here is that there is a lot of temporal redundancy, therefore lots of room for more compression across the three frames (compared to sending three separate jpeg images).
I will be implementing the solution on an embedded device in C without any libraries and no OS.
The camera will be taking pics in an area with very little movement (no visitors or screens in the background, maybe a tree with swaying branches), so I think my assumption about redundancy is pretty solid.
When the file is finally viewed on a pc/mac, I don't mind having to write something to extract the three frames (so it can be a nonstandard cluge)
So I guess the actual question is: What is the best way to compress these three images together given the fact that they are already in JPEG format (it is a possibly to convert back to a raw image, but if i dont have too...)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我将其添加为第二个答案，因为它与我的第一个答案非常不同，现在我更好地理解了您的问题。
我发现您不太可能直接使用 jpeg 文件。在压缩文件中，微小的更改往往会传播到文件的大部分，从而导致两个文件在许多地方无法进行比较。
我有两个建议。
1：将图像压缩。看起来太简单了，您可能已经想到了，但是 zip 协议是众所周知的并且可以免费使用，并且会自动利用它可以利用的任何相似之处。再次拿起相机拍三张照片；把它们拉上拉链，看看效果如何。
2：稍微复杂一点，但您可以将三个 jpeg 解压缩为 bmp，连接 bmp（将它们一个接一个地排列），然后重新压缩为 jpeg。 jpeg 协议应该充分利用三个图像中的相似性，并且从您的角度来看，工作量相当小。
I'm adding this as a second answer because it's VERY different from my first now that I better understand your problem.
I find it HIGHLY unlikely that you will be able to work with the jpeg files directly. In compressed files, a small change tends to be propagated across a large portion of the file, causing the two files to fail to compare in many places.
I have two suggestions.
1: zip the images up. Seems too simple, you probably already thought of it, but the zip protocol is well known and freely available and will automatically take advantage of any similarities it can. Again just get a camera take three pictures; zip them up and see how it goes.
2: A little more complex but you could uncompress the three jpegs into bmps, concatenate the bmps (line them up one after the other) then re-compress to a jpeg. The jpeg protocol should take full advantage of the similarities in the three images and the work is pretty minimal from your point of view.
对 JPEG 图像进行任何解码/修改/重新编码都可能会降低图像质量，但由于您的相机只能捕获 JPEG，我猜最终图像质量不太可能成为关键要求...
我想不出一个简单的方法您可以在 JPEG 频域中执行此操作，但您可以解压缩 从图像 1 中减去图像 2 和 3 以获得增量图像。这些应该压缩得更好，并且将由接收器添加回图像#1。
事实证明，您可以在压缩域中执行一些操作可能有帮助。您需要解压缩 jpeg 的 Huffman/RLE 阶段，然后直接处理 DCT 系数。您很可能能够以这种方式进行图像减法，并且它不应该引入更多的伪影。
Any decode/modify/recode on the JPEG images may lower the image quality, but as your camera can only capture JPEGs, I'm guessing ultimate image quality is unlikely to be a key requirement...
I can't think of an easy way you can do this in the JPEG frequency domain, but you can decompress then SUBTRACT images 2 and 3 from image 1 to get delta images. These should compress a lot better, and would be added back to image #1 by the receiver.
It turns out there are some operations you can do in the compressed domain that might help. You'd need to uncompress the Huffman/RLE stages of the jpeg, and then work on the DCT coefficients directly. You could well be able to do image subtraction this way, and it should not introduce further artefacts.
虽然我自从大学以来就没有研究过信号，但我认为您正在寻找无损视频编解码器。
Huffyuv 已经存在，并且有源代码。基本概念是预测每帧之间的像素变化，并对预测变化和实际变化之间的差异进行编码（和压缩）。
Lagarith 是另一个开源编解码器。
您需要将解码后的 JPEG 帧输入到每个编解码器中。
While I've not studied signals since uni, I think you're looking for a lossless video codec.
Huffyuv is one that's been around, and has source code available. The basic concept is to predict the pixel changes between each frame, and encode (and compress) the difference between predicted and actual changes.
Lagarith is another open source codec.
You'll need to feed the decoded JPEG frames into each of these codecs.
如果我是您，我现在就会使用您的系统手动拍摄三张照片，以便您可以在进一步操作之前检查您的假设。
我的猜测是，即使您不打算进行任何移动，也需要稍微翻译一下。设备的振动、风甚至热膨胀都可能足以让您偏离一两个像素，从而破坏直接的像素到像素压缩。
其他因素可能是由于云层穿过太阳而引起的光变化或从地面飘散的热放大，甚至是 jpeg 压缩伪影。
我并不是说它不起作用，只是我会先手动运行一个。
存储是如此便宜，通过在相机上添加更大的 SIM 卡（或其他任何东西），您将获得更多的收益。
If I were you, I'd use your system to take three pictures by hand right now so you can check your assumptions before going much further.
My guess is that you will need a slight translation even if you don't intend any movement. Vibration of equipment, wind and even heat expansion might be enough to throw you off by a pixel or two which would ruin a straight pixel-to-pixle compression.
Other factors could be light change due to a cloud passing across the sun or heat magnification wafting off the ground or even jpeg compression artifacts.
I'm not saying it's not going to work, just that I'd run one by hand first.
Storage is so cheap, you are going to get much more bang for the buck by adding a larger sim card (or whatever) to your camera.