Help: a handheld image processing device

Is that black and white - binary, 8bit, 10bit, 12bit, 16bit or some other value?

What simple image processing could it be done by FPGA/DSP?

Written in C/MatLab/.....

For that resolution of screen, if it has a backlight, that will be the battery drain.

Why not do a direct camera interface from a camera chip?

If you put USB you potentially have to supply 500mA at 5V (2.5W) of power. and as a HOST interface. Why make life difficult for yourself.

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.

I think you have been given or taken on more than you are capable of.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

The

some

this

rate

a

should I

Thank you very much for your reply.

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

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).

3.The LCD only displays the numbers of differnt size particles, probably in graphic style.

1. The device only works for about a few minutes, then switch off.

5.>Using a camera chip direct will be a LOT smaller and less

That is a very good suggestion. But I don't want to start from scratch. Any development board which I can use?

6.>I think you have been given or taken on more than you

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.

Please recommand me some development boards, or give me more suggestions.

Thank you very much!!

.....

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.

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.

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

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.

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.

Any development boards won't be in a box, and will be basically the same issues as the CVS-1455 system you currently have.

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

Size of screen Battery/mains operated Total size of handheld unit How much processing is currently being done. What type of output to screen MUST be there If graphical output is this changed every captured frame or after several frames. What buttons/user controls

This would probably take two weeks to get all the information together to finalise a spec, let alone build.

There is not enough information and currently this looks like put a high end PC and high end camera and high end image processing into a PDA, but have a screen output like a desktop PC.

Do some basic calculations

Frame size 1280 x 960 = 1,228,800 bytes (= 1200KB or 1.172MB) 10 frames per second = 12,288,000 bytes/second

to be captured and transferred to memory

If we only do 10 INTEGER calculations per image byte that gives

122,880,000 calculations per second

Then there is the calculations to perform to collate the statistics and convert this to data/graphs for screen output.

There are a lot of calculations and work to be done, to work out your minimum system requirements, before even looking at any other LabView requirements, and operating systems.

THEN you might be able to work out what your minimum requirements are for your development board.

For most people it would take two or more months to get the case/box design sorted and built.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

On Fri, 17 Oct 2008 08:47:34 -0700, Paul Carpenter wrote (in article ):

How many do you have to make? If only one or a couple, search eBay for "ARM9" 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.

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.

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.

-- Charlie Springer

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.

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.

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.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

On Sat, 18 Oct 2008 11:19:40 -0700, Paul Carpenter wrote (in article ):

10 frames is pretty slow. I did real-time rejection of carbide chips from x-rayed titanium chips on conveyor belts 20 years ago with a PC.

Most stereology uses many slices to recreate the object in 3D. This is much simpler.

Dapple systems did this for SEMs with an accelerated Apple IIe 20 years ago as well. 3.5 MHz 8 bit 65C02. I could do the threshold on an image in about a

10th of a second and that was looking to the image through a 256 byte peephole in frame buffer memory. You may be conditioned to think too big by the insanely poor performance of PC based systems with 3 GHz Intel chips. You realize a Nintendo DS has an ARM7 and an ARM9 running fairly slowly and renders video scenes in 3D? Or look at a Sony PSP with its MIPS processor.

I wonder how they did anything before National Instruments, GBytes of RAM,

3,000 MIPS of processing power, and scripting languages?

For the inexperienced perhaps.

You have inspired me to conduct a survey.

-- Charlie Springer

10 frames is slow if NOT doing anything else, your system 20 years ago for a start was using probably at MOST 640 x 480, and you are not saying how many defects/size/distribution calculated per frame or more likely per minute. Real time can mean a response time of hours, depending on the system requirement.

We have no idea if the cell counting being performed by the user is likely to expect to find stats (and how many stats) for 10, 100, 1000 or 10,000 particles in each frame, over an averaged 10 frames, or even to work out how much movement there is between frames.

We have no idea of the expected ratio between smallest/average/largest particle and full screen, to know what the maximum non-overlapping particles would be.

We have no idea as to how much work has to be done by some form of operating system or not, what form of display is required, how long the operation period is, what the sampling to display update HAS to be.

We do not know if the LCD display is full of graphics / text or even just simulating traffic light display mnemonics.

Many slices taken over anything up to hours, to be made into some other model/image form, where faster is better. Faster often means faster than the previous model and is rarely take 100 slices in a few seconds and display computed result and update after the first two slices.

How many stereology systems do on the fly pan/zoom of the computed output model/image as the slices are BEING CAPTURED, i.e. each slice is coming at a frame update rate of greater than 5 frames per second.

How many Scanning Electron Microscopes having images that change their content at frame rate? Most SEMs of that period were lucky to have a pixel clock output rate of >1MHz. SEMs often used what was referred to as SLOWSCAN, which is a clocked video input stream. Often at what was regarded as high resolution if the image was 512 x 512.

SEMs do not generally have image content that changes from frame to frame.

If you look at small window you can do all sorts of things, and I have done this on many systems, but gives meaningless results unless that is what you want to do.

No my last REAL TIME video processing times were small devices that in one case was processing real video signals at pixel rate, with ONE pixel time delay between input and output. The size of one PCB including onboard PSU and RGB in/out connectors 9 x 7 inches, with lots of space due to case and user control constraints, could have fitted onto half a Eurocard plus PSU.

Another case worked on REAL TIME 3D dispaly for medical systems and amongst other things converted from interlace to non-interlace for displays and manipulated the images in many ways digitally. Continuous calculation 2GIPS for processing TWO image streams at the same time, with input to output delay time of around 11 INPUT HORIZONTAL line times.

NOT a PC anywhere near it. In those cases dedicated hardware.

In other cases image processing using PCs and other systems, from manual controlled to various systems in various industries.

Graphics render engines or GPUs, do a lot of the work and have done for over 20 years, and the one way output processing is totally different methodology. Apples and Pears.

I also undrestand that it depends on how what is likely to be byte wide input data is manipluated or even upconverted to 32bits/pixel in most systems that causes a lot of slow down in processing. So many people think when in trouble put in bigger processor or more memory.

Depends on a lot of other factors, most of which the original poster has given NO indication of.

Perhaps as you know the FULL system specification and EXPECTATIONS of the other poster and his boss you would like to post it here! ...

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

On Sun, 19 Oct 2008 03:38:34 -0700, Paul Carpenter wrote (in article ):

Sometimes slow scan, sometimes they used my frame graber.

At one op per clock (actually a little faster) and 32 bits the ARM here is only about 1,600 to 4,000 times faster that the old Apple system. I guess it is hopeless. (Quadruple that if you consider the convoluted memory management required on the old system.)

snip

Most of the described processing can stay 8 bit packed 4 to a word and done in parallel. If not, ARM has auto sign extension.

I'm guessing the spec is "simple". Make it work (give similar results) like the other system but hand held. The other system wasn't exactly a supercomputer.

It sounded straight forward. Handheld. Looks at dust for a few seconds or minutes then put it down till the next check. The OLD system that wasn't handheld had the higher res camera and display. The camera isn't a problem anyway. The display shows histograms for something like that. Big deal!

-- Charlie Springer

.....

How often I heard that a design "is simple" from customers when it is nothing like that. That is my experience in over 90% of original 'specs'.

You have made a LOT of assumptions.

My experience with these is it is nothing like that simple, there are too many things you are not told.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

... snip ...

That attitude is largely dependent on the experience of the customer. If he, himself, has actually designed a system, mods to that system will often seem easy to him, because he can see the problems and how they may have been already handled. On the other hand without experience he may have no idea of the work required.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

[snip]

I was involved with a similar project nearly 20 years ago and we used a 68020 to do the 875-line image processing at

30 fps.