Compressing a run of 10 to 20 highly redundant images with which compression library?

views:

answers:

+3 Q:

Compressing a run of 10 to 20 highly redundant images with which compression library?

I am going to be generating images once every minute or so from a low resolution camera. I would like to take runs of 10 to 20 images and compress them for transmission over a very bandwidth limited channel. I have looked at using x264 but it feels like over kill.

Given that my images are 320x240, with high level of redundancy between frames, what would be the best way to go?

The encoding does not have to be particularly fast, its more about finding a balance between difficulty in implementing on an embedded device, and the reduction in total file size.

I will have full control over the viewing software, so using a modified version of some compression scheme would be ok.

I will be using freeRTOS

+1 A:

A simple and robust way to do this is to just encode each frame as a JPEG. This may be presented as an M-JPEG stream. Compression usually is decent, even if not optimal. If this is good enough for you, go for it.

kotlinski 2010-10-27 00:20:34

This is the baseline method. I am exploring methods that add even better compression due to the high temporal redundancy.

michael 2010-10-27 01:45:47

But you are right, going with JPEG has the biggest first impact on reducing the total file size.

michael 2010-10-27 01:46:31

One simple idea that will give you more bang for the buck: Merge the ten frames to one large frame (e.g. 3200x240) before making a JPG of it.

kotlinski 2010-10-27 14:57:23

...in effect, this will enable basic inter-frame compression.

kotlinski 2010-10-28 06:48:12

Is there a port of libavcodec to that device? I think it has a h.264 encoder built in. I don't think that h.264 is overkill.

Define "bandwidth limited", though. If you have enough bandwidth to transmit at 1 bit per pixel (that would be 160 bytes per second at 1 frame/minute frequency), you don't need to go beyond jpeg. If you have even less than that, temporal compression (some kind of MPEG) is warranted.

2010-10-27 00:29:13

Well, we are transmitting 250 bytes every couple seconds. So 1 320x200 jpeg image is usually around 12KB. It would be awesome if we could get 10 frames for the price of 3~4 jpegs.

michael 2010-10-27 01:48:06

A cheap and easy thing to try is to compute frame differences in software and then pas them to the jpeg library. See how much that gives you.

2010-10-27 02:01:32

you mean pass the first frame and then the diff frames? With the diff frames having less bit depth?

michael 2010-10-27 16:08:58

Yes. Diff frames will have very little information in them and they should compress well. It will be almost like MPEG, but without motion compensation.

2010-10-27 20:29:19

Why is x264 overkill? It's a really efficient encoder and if you want to exploit spatio-temporal redundancy, you need to use compression algorithms like H.264 instead of a bunch of JPEGs.

Jacob 2010-10-27 03:31:45

hmm, ya maybe i should look into it. Really what I need to do is look at a comparison of MJPEG against other encoding scheme to see what gains I make (right now I have a bunch of jpegs, so MJPEG is a good baseline comparator)

michael 2010-10-27 16:11:27

ansaurus

tags:

views:

answers:

Compressing a run of 10 to 20 highly redundant images with which compression library?

related questions