The jpeg library found in the uClinux distribution is the industry standard version from the Independent JPEG Group, latest release was done 27-Mar-1998.
There is an FAQ about jpeg which can be found at: www.faqs.org
There are a few examples using the libjpeg library which can be found in the uClinux-dist/lib/libjpeg
directory:
Each application most likely has a man page installed on your host - check there for options.
The example applications have included help, just add the flag -?
to the command:
root:~> /usr/bin/cjpeg -? usage: /usr/bin/cjpeg [switches] [inputfile] Switches (names may be abbreviated): -quality N Compression quality (0..100; 5-95 is useful range) -grayscale Create monochrome JPEG file -optimize Optimize Huffman table (smaller file, but slow compression) -progressive Create progressive JPEG file -targa Input file is Targa format (usually not needed) Switches for advanced users: -dct int Use integer DCT method (default) -dct fast Use fast integer DCT (less accurate) -dct float Use floating-point DCT method -restart N Set restart interval in rows, or in blocks with B -smooth N Smooth dithered input (N=1..100 is strength) -maxmemory N Maximum memory to use (in kbytes) -outfile name Specify name for output file -verbose or -debug Emit debug output Switches for wizards: -baseline Force baseline quantization tables -qtables file Use quantization tables given in file -qslots N[,...] Set component quantization tables -sample HxV[,...] Set component sampling factors -scans file Create multi-scan JPEG per script file
root:~> for i in 20 40 60 80 95 ; do echo $i ; time cjpeg -quality $i mandrill.bmp > mandrill.jpg ; ls -l mandrill.jpg ; time djpeg mandrill.jpg > /dev/null ; done 20 Caution: quantization tables are too coarse for baseline JPEG real 0m 0.21s user 0m 0.20s sys 0m 0.01s -rw-r--r-- 1 root root 27440 Jun 27 12:22 mandrill.jpg real 0m 0.12s user 0m 0.12s sys 0m 0.00s 40 real 0m 0.24s user 0m 0.23s sys 0m 0.01s -rw-r--r-- 1 root root 43667 Jun 27 12:22 mandrill.jpg real 0m 0.14s user 0m 0.14s sys 0m 0.00s 60 real 0m 0.24s user 0m 0.23s sys 0m 0.01s -rw-r--r-- 1 root root 58338 Jun 27 12:22 mandrill.jpg real 0m 0.14s user 0m 0.12s sys 0m 0.01s 80 real 0m 0.27s user 0m 0.24s sys 0m 0.03s -rw-r--r-- 1 root root 88762 Jun 27 12:22 mandrill.jpg real 0m 0.15s user 0m 0.14s sys 0m 0.00s 95 real 0m 0.35s user 0m 0.32s sys 0m 0.03s -rw-r--r-- 1 root root 190020 Jun 27 12:22 mandrill.jpg real 0m 0.20s user 0m 0.19s sys 0m 0.00s
If we examine the -quality 95
output, since the image is the standard mandrill, which is 512×512
pixels, (262,144 pixels), 0.35s (1.33514404296875 useconds per pixel) for encode and .20s (0.762939453125 useconds per pixel)for decode. Based on a processor speed of 525(MHz CCLK):
root:~> cat /proc/cpuinfo processor : 0 vendor_id : Analog Devices cpu family : 0x27de000 model name : ADSP-BF548 525(MHz CCLK) 131(MHz SCLK)That is around 700 clocks per pixel for encode, and 400 for decode. This is about 5.3x (700/131) encode and 2.2x (400/179) for decode what a hand optimized assembly version can provide (based on results from ADI's proprietary JPEG software module.
We are currently working on improving that and will update things here as that is done.