Image compression MCU/DSP

If it was really JPEG, I would try to use a DSC ASIC[ASSP]. These are optimized specifically for that task, and also for low power consumption. Any other solution leaves you powering general-purpose data paths that you aren't using.

It's a bit application-dependent, though. If power is the most important factor, you need to weigh data tx energy cost vs. compression cost. At some point in the compress vs. raw tx curve you'll hit a break-even point; below that point, it takes so long to compress the data that you're wasting power; above that point, it takes so much energy to transmit the [low-compression] data that you'd be better to compress harder.

Before resorting to a 'PEG compression, you may want to look at some other approaches. If you must resort to fancy compression, there are chips and FPGA codes to do that. If you must stay with processors, someone else should recommend. It sounds like you're at the board design stage.

I suggest trying a simple RLE. If you have color, then you will RLE the color and the grayscale separately. You may find a very simple compression that meets your needs.

With a slight sacrifice of fidelity, you can make your RLE codes unique - not to be confused with uncompressed data. This can guarantee a minimum of zero compression, as compared to inflation when the RLE codes cannot be made unique.

Find out what the $35 digicams do.

Jerry

Can you characterize the task a little more clearly? How big are the images? What color depth is involved? Does the compression need to be lossless? What kind of throughput (images per time) is needed?

-Will Dwinnell

The images are 640 by 480 and they are monochrome. The compression does not have to be lossless as long as details, such as faces can still be recognized. The compressed images will be saved on a flash card such as SD or CF. I would like to be able to capture an image once every 5 secs. The transmitted images would be a subset of the acquired ones only because the transmission link is slow. I think that the transfer rate between the MCU and the flash memory is fast enough to acheive this throughput.

The reason I mention a dsPIC is that I am already using a MCU to control other stuff. I am not bound to any specific architucture yet. I am still in the research phase, so any suggestion will be very helpful. I am looking into image compression chips, but so far I have not been very successful I must admit.

Thank you.

If you want to use an available JPEG compression library, stick to processors with a linear address space (which TI dsps and PIC aren't). You can look into an processor based on the ARM architecture.

Still better, go for a Blackfin DSP. For instance BF531 is low cost, still very powerful and with very good power management features, besides impressive computational power and microcontroller-like features.

JaaC

You might consider the method described in the article "Block Truncation Compression", by Anton Kruger, published in the April, 1992 issue of "Dr. Dobb's Journal". See:

-Will Dwinnell

A 16 bit image buffer would be 600K bytes. You need at least one, possibly two image buffers.

It will be hard to find a PIC with enough memory.

If not a PIC, then what do you suggest? For personal and affordable prototyping, how would one go about it?

ARM, PPC or X86

How about MP3?

Good Luck! Rich

Thank you for your helpful insight. I am leaning towards an ARM solution, do you have any preference about which one to choose from? It is so confusing with all the choices available.

Thank you.

Any ARM7tdmi MCU can easily deal with your resolution and framerate using only a few MHz to do JPEG compression (a well optimised JPEG is extremely fast on ARM). However it will be difficult to do this just using on-chip SRAM, and using external SDRAM means power consumption may become a problem. It may be good enough if you can collect, process and transfer the image in small strips though, so you'd want to look for an ARM7 MCU with a lot of on-chip SRAM.

If you want to do JPEG or similar compression and need SDRAM then it might be better to go for an ARM9 with cache, for example LPC3180, AT91RM9200 or AT91SAM9261. The caches and higher performance of ARM9 will significantly lower power consumption.

Wilco

Yes, they all work the same, just differently. MP3 works in single dimensional voice freqence. JPEG works in two dimensional color spectrum. MPEG works in three dimensional color and temporal spaces. They can all be handle with the same Si + O compound.

I would suggest at least 32MB SDRAM, but depends on your sensor resolutions.

For a secured site, we are using a K6 for capturing, compressing and wifi-ing aproximately 4 frames per second at 592x480 12 bits YUV to JPEG

You can plan your hardware by my example:

K6 233MHz

Thats would be great except that I am unable to sun power to the site, it has to run of a battery.

I found an epson network camera controller that has ar ARM MCU built in with a hardware jpeg encoder. Has anyone used one of these before? I am waiting until after the weekend to check where I can get a couple for prototyping.

Thank you, A

Yes, we can run it off battery, with a 50W solar panel charger. Our setup takes about 20W, wuth the rest saved for overnight.

Did a quick check on the spec. It can do 7 fps on VGA, with the hardware JPEG encoder. That part is good. But...

Epson/Arm7 vs. Phillips/PC

1. 8 bits LUV vs. 12 bits LUV
2. 640x480 vs. 582x480
3. 50MHz vs. 200MHz to 4G

In fact, we might run it on a faster PC. We are using the

How large is your setup?

I have other restrictions inclduing size, the smaller the better. In fact all the restrictions are competing with each other.. power, efficiancy, size, battery life.. etc..

It is great that you can use obsolete equipment for something beneficial.