Re: Help: a handheld image processing device
- From: Paul Carpenter <paul@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 18 Oct 2008 19:19:40 +0100
In article <0001HW.C51ED09C00920CF4F02845B0@xxxxxxxxxxxxxxxxxxxxxx>,
RAM@xxxxxxxxxxxx says...
On Fri, 17 Oct 2008 08:47:34 -0700, Paul Carpenter wrote
(in article <MPG.2362c3f42ee0121f9896b3@xxxxxxxxxx>):
In article <U_adnUb8Xre4A2XVnZ2dnUVZ_hCdnZ2d@xxxxxxxxxxxx>,How many do you have to make? If only one or a couple, search eBay for "ARM9"
whyyjq@xxxxxxxxx says...
Subject: Re: Help: a handheld image processing device.....
From: cressw <whyyjq@xxxxxxxxx>
Date: Fri, 17 Oct 2008 09:16:05 -0500
Newsgroups: comp.arch.embedded
In article <68adnTfwZsrTGWrVnZ2dnUVZ_jOdnZ2d@xxxxxxxxxxxx>,The
whyyjq@xxxxxxxxx says...
I was asked to design and implement a handheld image processing device.
somefunction of the device is that the camera captures an image,then do
thissimple image processing, and then display the result on a LCD. Repeat
rateprocesure. The maxium resolution of the image is 1280x960, the frame
10fps. the image is black and white.
Is that black and white - binary, 8bit, 10bit, 12bit, 16bit or some
other value?
Thank you very much for your reply.
Please interleave your replies in the places in the article
(preferably removing old signatures and trimming), it makes it
easier to read and in future trim sections no longer relevant.
1.The image is about particles such as dust etc. The function of the
device is to calculate the sizes of the particles in the image, and then
display the distribution of the numbers of the different size particles.
It is black and white: 8bit
So the image itself is NOT displayed only the stats from the
cell/blob counts. You will need a fairly substantial processor
and memory to keep up with that frame rate and then do all the
processing required, between and after frame captures.
2.The system has been implemented based on NI CVS1455, programmed in
LabVIEW, and Vision Assitant which has all image processing functions,such
as threshold, fill hole and counting pixels. They can transferd to C code (
I think).
Yes it can be transferred to C, but you would need to read up on the
system requirements for the software, and what the current system does
considering that the system is efefctively a PC in a box already with
Approx 1GHz processor
RAM 128MB
Video out VGA
Video 3 plus camera interfaces
NV Storage
3.The LCD only displays the numbers of differnt size particles, probably
in graphic style.
I would imagine with some min/max/average figures for each size group.
You really need to know how much data MUST be displayed and in what
format, to work out system requirements.
At the moment buy any desktop LCD monitor is your best solution.
4. The device only works for about a few minutes, then switch off.
Considering the system you are curently using is a 20-50W power block
without the screen power and camera, you are being asked to fit a gallon
in a teacup.
5.>Using a camera chip direct will be a LOT smaller and less
power drain. Think of mobile phones with cameras in, they do
NOT have a USEB/IEEE1394/or other interface.
That is a very good suggestion. But I don't want to start from scratch.
Any development board which I can use?
Any development boards won't be in a box, and will be basically
the same issues as the CVS-1455 system you currently have.
6.>I think you have been given or taken on more than you
are capable of.
I totally agree with it. My boss is not familiar with embedded sytems, and
said the device should be very easy to implement. The time buget is two
months. But i don't think so. I only have experience with designing simple
embedded system, don't have experience with camera/image processing etc.
I have spent many years with embedded systems, cameras and video/image
processing and this CANNOT be done in two months.
There is no simple handheld device that could do this without a LOT
more information. Information like
and 2440V3. It is a 400 MHz ARM9 with 64MB of RAM (32 bits wide) and FLASH
(NAND and NOR) often used in teaching in China. LCD interface and camera
interface. Comes with Linux and WinCE, USB, Ethernet, the works. It is about
10 by 12 centimeters which is bigger than a blackberry and smaller than a
paperback. In fact there is a version in a white plastic housing with a small
LCD display and fairly high res CMOS cameras that will plug in to the 20 pin
interface are about $30. I think Sparkfun has some now.
Which are meant for grabbing one image, and possibly doing something with
it like storage. Then several minutes later you might want another image.
10 frames per second is a different kettle of fish.
The processing you describe is pretty simple and is used a lot in image
processing called stereology. Your dust motes can be thought of as a
projection of 3D objects onto a 2D plane and you are seeing a slice through
the greatest cross section of each.
It is nothing like grab one frame and you have hours to calculate any
answers. Stereology is one of the many sciences that often look down
microscopes and take one image only.
A 400 MHz ARM will rip though that at low power and on the cheap. The code
will be lots of loops and they will end up in cache and go full speed. Data
from the SRAM is only 100 MHz but if three rows of the image fit in cache
(they should) you are golden. Almost everything happens in 3x3 pixel groups.
When you move down one row, you essentially abandon that data and only one
new row gets read into cache. It should be very fast.
If it was one image, MAYBE! Cell/blob counting stats is a little bit more
than 3 x 3 convolution operations. We have nop idea if the stats look at
overlapping particles or not (overlapping cells/blobs).
At the original 10 frames per second of 1280 x 960 images I doubt the ARM
would be that effective. Even if only 10 frames were acquired.
There is so much missing from the request to make any useful
recommendations.
-- Charlie Springer
--
Paul Carpenter | paul@xxxxxxxxxxxxxxxxxxxxxxxxxxx
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
.
- Follow-Ups:
- Re: Help: a handheld image processing device
- From: Charlie Springer
- Re: Help: a handheld image processing device
- References:
- Help: a handheld image processing device
- From: cressw
- Re: Help: a handheld image processing device
- From: Paul Carpenter
- Re: Help: a handheld image processing device
- From: cressw
- Re: Help: a handheld image processing device
- From: Paul Carpenter
- Re: Help: a handheld image processing device
- From: Charlie Springer
- Help: a handheld image processing device
- Prev by Date: Re: STM32 ARM toolset advice?
- Next by Date: Re: Help: a handheld image processing device
- Previous by thread: Re: Help: a handheld image processing device
- Next by thread: Re: Help: a handheld image processing device
- Index(es):
Relevant Pages
|