However, this command alone is taking 84 seconds to execute, which is
completely unacceptable. I need something in the range of 5-8 seconds.
I'm using a custom image of Angstrom built using Narcissus.
Any idea how I can achieve speedup? I don't know how to involve the
DSP in this processing, or whether it's even appropriate. Any pointers
on getting the DSP involved would be greatly appreciated.
I've thought of configuring imagemagick with 8-bit quantization, but
apart from that I don't know how to improve the processing speed .
However, this command alone is taking 84 seconds to execute, which is
completely unacceptable. I need something in the range of 5-8 seconds.
I'm using a custom image of Angstrom built using Narcissus.
Any idea how I can achieve speedup? I don't know how to involve the
DSP in this processing, or whether it's even appropriate. Any pointers
on getting the DSP involved would be greatly appreciated.
I would 1st use oprofile or similar to find out what is taking so long.
I've thought of configuring imagemagick with 8-bit quantization, but
apart from that I don't know how to improve the processing speed .
Could try custom C that does just the operation you want, depending on
how imagemagic implements it's pipeline it could be a lot faster, or
maybe only a little. But you'd have the flexibility of algorithms,
ability to remove unnecessary abstractions and so on (i.e. use libjpeg
directly, not some other library, etc). gcc can do some limited
vectorisation stuff help, or there's always direct NEON/SIMD assembly.
A divide operation that works on integers is expensive on omap - no
divide instruction, but that depends on the algorithm used as to
whether this is an issue. I'd probably try to identify which of the
operations is taking all the time by disabling each in turn. e.g. if
no processing apart from image translation is still taking a long time
it doesn't matter how fast you make the middle bit.
Don't have experience with such things yet, but It sounds like a DSP
kind of thing (or gl?), but may, or may not be a lot of work - and the
DSP is coded in C anyway. There's plenty of stuff on the net about
it. I suspect you'll have to write it yourself to do anything with
the DSP.
Out of curiosity, how big is the image? 84s seems slow ...
Quick alternative is just to use a different algorithm.