Dennis Ranke wrote:
>
> Hmm, I have now implemented AAN DCT and my decoder now takes on a 233Mhz
> StrongARM 2.9cs to decode a 17kb 240x160 Jpeg to 32768 colours with
> ordered dithering. This speed comes quite near to another jpeg
> implemenation on this computer which i believe is quite good optimized.
> When I take only the difference in clock speed into account, it would
> take about 0.4s on gba.
> This is of course somewhat different to your figures, therefore i am
> wondering if you just stated the speed of your dct core or that of
> the complete decoder.

Nope, I meant the entire kaboodle. Though my file format is not a true JPEG
compliant stream, I still feature all the essentials, but no dithering. I
keep quantisation down just sufficiently to make sure we never comprise the
destination colour range after colour space conversion.
As a point of reference regards the speed, the JPEG library that ARM sells
(circa $60,000 iirc) does about 0.55 MegaPixels on a 40Mhz ARM7. On a 200Mhz
StrongArm their decoder rates at 4.0MegaPixels which is roughly 9.6ms for
240x160 image and approx.
I'm guessing my coder clocks in faster than theirs purely down to the
shortcuts I've taken given the target platform display. If I supported the
full range of options, mine would be marginally slower than theirs right
now, but since I don't need to I'm not bothering. Ask yourself do you really
need all that extra fluff?

> My dct core seems to take about 0.3cs for the above picture, which means
> that there is certainly still a lot of room for optimisation in other
> areas...

An 8-point DCT cannot be done in less than 11 multiplies, it is possible to
arrange the computation so that many of the multiplies are simple scalings
of the final outputs. These multiplies can then be folded into the
multiplications by the JPEG quantization table entries. The AAN method
leaves only 5 multiplies and 29 adds to be done in the DCT itself.

A big boost can be achieved by short circuiting the DCT for any column that
has its AC terms at zero. This occurs at lot more frequently than might be
expected due to quantisation. If the AC term of any column is zero then the
output is equal to the DC coefficient, with scale factor as needed. You'll
find that in typical images half or more of the columns can be handled in
this fashion.

And once you do all that and are sitting back smiling thinking how cool is
this and maybe starting to think that maybe an MPEG player on that wee
little 16Mhz ARM7 wouldn't be so impossible after all, go lookup Fast DCT
'Approximations'. There you'll discover a whole new avenue of DCTs that use
*ZERO* multiplies, just shifts and adds and go very, very, very fast :)

AndyM