Olimex Support Forum

OLinuXino Android / Linux boards and System On Modules => iMX233 => Topic started by: normad on October 01, 2013, 10:54:31 pm

Title: olinuxino-mini performance
Post by: normad on October 01, 2013, 10:54:31 pm
Hi guys,

I recently got the olinuxino-mini and i'm working on an image processing application. Currently im using the arch image with the 3.7 kernel. My application requires me to capture an image from a usb camera (im currently using a cheap webcam) and do some processing on it (object detection).

fswebcam takes approximately 2seconds to do a capture and save. Although most that time should be on the jpeg compression assuming my processing would be equivalent thats a framerate of 0.5fps  :-\.

ultimately i need my application to run at 10fps. so although i can develop my application on the mini i will need a different embedded platform to deploy it on(unless there is a way to speed up things on the mini?)

so what do you guys think would be the ideal embedded linux board for me to get to achieve such performace? easy portability from mini to the x platform would be nice :)

thanks in advance
Title: Re: olinuxino-mini performance
Post by: tselmeci on October 27, 2013, 11:36:27 am
We have made some measurements on iMX233 to get a clear picture of its performance when it comes to image processing. We have a special OpenCV application and we had created a benchmark utilizing that application.

It turned out that iMX233 has very few computing power for image processing; no wonder: ARMv5, no floating point, 4xx MHz etc. This board is simply not determined for this purpose.

On the other hand, what would affect you as well: (I don't know fswebcam) the webcams I have seen in my life can usually operate in two modes:
-1) provide a video stream e.g. via HTTP, RTSP;
-2) provide a JPEG capture "interface", usually via HTTP;

1) in this case the capture tool (in our case it was ffmpeg) has to wait until an I (key) frame arrives, decode it and encode it into JPEG. If the video stream is e.g. in h264, it can take a lot of time to decode it to a raw picture, and the to encode it into JPEG. If you sum up the time spent waiting for a keyframe, decoding it and encoding it, you get a value which can be several seconds (as was in our case too);

2) this may be the better approach in your case. If the camera can provide you with single JPEG frames, you definitely should get that. Maybe with CURL, wget, not with fswebcam (although I'm not aware with its capabilities);