Forums

Embedded JPEG compression

Started by Fred May 6, 2004
I have looked for some time at the Independent JPEG Group set of files for
JPEG compression.  These are extremely difficult to transcribe to a C
compiler for a micro. This code seems primarily for Linux and has lots of
bells and whistles which I don't need.  The group use C in a way I am not
use to and my experience is mainly with micros and microcontrollers.

A long shot - but does anyone know of code which would fit my purpose
available on the 'net?


Fred <fred@abuse.com> wrote:
> I have looked for some time at the Independent JPEG Group set of files for > JPEG compression. These are extremely difficult to transcribe to a C > compiler for a micro. This code seems primarily for Linux and has lots of > bells and whistles which I don't need. The group use C in a way I am not > use to and my experience is mainly with micros and microcontrollers.
> A long shot - but does anyone know of code which would fit my purpose > available on the 'net?
The answer depends extremely on what your "micro" actually is. It could range from "plainly impossible" to "just use IJG code --- it works", as the choice micro is tuned through from, say, a classic 8051 or PIC all the way to a current ARM design. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Fred wrote:

> I have looked for some time at the Independent JPEG Group set of files for > JPEG compression. These are extremely difficult to transcribe to a C > compiler for a micro. This code seems primarily for Linux and has lots of > bells and whistles which I don't need. The group use C in a way I am not > use to and my experience is mainly with micros and microcontrollers. > > A long shot - but does anyone know of code which would fit my purpose > available on the 'net? >
I'm not familiar with these technologies. However the first question is : do you have as much memory as is required ? The image plus some for the algorithm. The next question is : how many operations are required for the intended quality, assuming the operations depend on the quality. Can you afford to wait that long for the compression, or would another algorithm be better ? You may have to do some tests on a PC to get the RAM usage and the number of operations. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
> I have looked for some time at the Independent JPEG Group set of files for > JPEG compression. These are extremely difficult to transcribe to a C > compiler for a micro. This code seems primarily for Linux and has lots of
Not really, I've done it three times now :) Use the "no backing store" memory manager, and you go through searching and destroying the calls to malloc and routing them into your own memory manager. With very modest memory requirements, you can handle both compression and decompression of all sequential JPEGs up to very large resolutions (you just need a width x 8-pixel buffer, and some extra storage for the various tables). It is not amazingly _efficient_ but it _works_. Frankly you are unlikely to see much optimization benefit from unrolling it all and turning the indirect calls through pointers into direct function calls. Most of the time is spent actually crunching numbers. I would not suggest using this all-software all-the-time implementation on an 8-bit microcontroller, though. If you are looking for 8-bit solutions, cheap DSC ASICs with on-chip hardware DCT are the route to go.
> I have looked for some time at the Independent JPEG Group set of files for > JPEG compression. These are extremely difficult to transcribe to a C > compiler for a micro. This code seems primarily for Linux and has lots of
Forgot to mention: If you would like JPEG6B _decompress_ tweaked to work on an OSless ARM environment with a proprietary dirt-simple memory manager, please email me privately and I will extract it from the project that contains it. I have not tested the compress side of this and it will certainly require work, but hopefully not too much. You will need to do some legwork. I replaced the file I/O calls with calls to a proprietary filesystem layer, which I cannot give to you (I wrote it, but don't own it). The code, as-is, supports decompressing JPEGs out of a ROM source (could be RAM, of course) or from a filesystem. VERY SIMPLE decimation support is also provided (the ref sources don't implement this).
> I have looked for some time at the Independent JPEG Group set of files for > JPEG compression. These are extremely difficult to transcribe to a C > compiler for a micro. This code seems primarily for Linux and has lots of > bells and whistles which I don't need. The group use C in a way I am not > use to and my experience is mainly with micros and microcontrollers. > > A long shot - but does anyone know of code which would fit my purpose > available on the 'net?
I recently needed to do a similar thing - JPEG compression on an 8 bit micro. I found the IJG code to be confusing and poorly optimized for embedded systems. Tony Lin has taken the IJG code and restructured it to be simpler and more efficient. It still needs some tweaks to fit it into the RAM and ROM capabilities of a small micro, but it's a better place to start than the IJG code. Here's the Code Project link: http://www.codeproject.com/bitmap/tonyjpeglib.asp Scott
"Lewin A.R.W. Edwards" <larwe@larwe.com> wrote in message
news:608b6569.0405060736.10867b4d@posting.google.com...
> > I have looked for some time at the Independent JPEG Group set of files
for
> > JPEG compression. These are extremely difficult to transcribe to a C > > compiler for a micro. This code seems primarily for Linux and has lots
of
> > Forgot to mention: If you would like JPEG6B _decompress_ tweaked to > work on an OSless ARM environment with a proprietary dirt-simple > memory manager, please email me privately and I will extract it from > the project that contains it. I have not tested the compress side of > this and it will certainly require work, but hopefully not too much. > You will need to do some legwork. I replaced the file I/O calls with > calls to a proprietary filesystem layer, which I cannot give to you (I > wrote it, but don't own it). The code, as-is, supports decompressing > JPEGs out of a ROM source (could be RAM, of course) or from a > filesystem. VERY SIMPLE decimation support is also provided (the ref > sources don't implement this).
Many thanks for this offer. You'll be receiving an email from me shortly. The ideal is to compress a YUV file in RAM and placing the result into another area of RAM so your code sounds ideal.