Connect with us

Image compression MCU/DSP

Discussion in 'Electronic Design' started by amerdsp, May 12, 2006.

Scroll to continue with content
  1. amerdsp

    amerdsp Guest

    Hello all,
    What would you experts do if you want to perform image compression (I
    am thinking jpeg), on a low power board? The data is captured from an
    image sensor and needs to be transmitted elsewhere. Would you use a
    MCU bundled with a DSP or would you use two separate MCU and DSP chips?
    I was thinking about using a PIC with nano watt technology along with
    a low power DSP from TI. Or should I use a dsPic? Or anything else?

    Thank you for your time and help.

  2. larwe

    larwe Guest

    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.
  3. 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.
  4. Jerry Avins

    Jerry Avins Guest

    Find out what the $35 digicams do.

  5. Predictor

    Predictor Guest

    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
  6. amerdsp

    amerdsp Guest

    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.

  7. Nico Coesel

    Nico Coesel Guest

    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.
  8. jaac

    jaac Guest

    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

  9. Predictor

    Predictor Guest

    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
  10. linnix

    linnix Guest

    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.
  11. amerdsp

    amerdsp Guest

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

    linnix Guest

    ARM, PPC or X86
  13. Rich Grise

    Rich Grise Guest

    How about MP3?

    Good Luck!
  14. amerdsp

    amerdsp Guest

    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.

  15. 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.

  16. linnix

    linnix Guest

    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.
  17. linnix

    linnix Guest

    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
    64MB IDE Compact Flash
    48MB SDRAM
    SAA7130 NTSC Composite
    Linksys WUSB11
  18. amerdsp

    amerdsp Guest

    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,
  19. linnix

    linnix Guest

    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
    200MHz PCs because they are useless for anything else.
  20. amerdsp

    amerdsp Guest

    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
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day