Neuros Technology Forums

Quite by chance I recieved an email ths morning re:

http://www.1394imaging.com/en/products/converters/dfgusb2lt/overview/

Cheers

Now there we go-- that and a decent SBC with USB 2.0 might do it, providing the latency isn't too bad--- thanks for the link...

Apologies if you have already seen this device:

http://www.seattlerobotics.com/cmucam.htm

Camera can output raw frames via serial port @115kBd and seems to be quite adept at many other vision related functions. At least this would provde a possible front end to your system with just the other half to worry about...

Price is around $100 - seems to be too good to be true !.

Cheers

Pretty cool, and probably worth playing around with but the problem with it is it only tracks one object at a time, and uses only brightness or color to determine the object.  Even their version 2 seems to fall a little short of the mark, though the resolution at least is probably acceptable (version 1 is only 356x292 which is probably not enough).   I need to support several more sophisticated motion tracking capabilities-- multiple objects, determined either by motion (difference from previous frame), or optionally by difference from a background.   Thus, multiple objects are detected either by their motion, or simply by their presence because it differs from the background (either a captured background, or an adaptive averaged background).    Also motion direction is useful to me as well-- the ability to track not only that objects have moved, but what direction they moved.   This requires a little more storage and processing than this little camera appears to be capable of, and also the cameras firmware  doesn't appear to be open source.

And frankly, I'd prefer a vision processor that's separate from the camera because then one can select from a variety of cameras, cheap or expensive, with zoom lenses or whatever.   And, a lot of people already *have* NTSC cameras and other NTSC sources, so a SBC with a decent NTSC capture is more flexible.  Still, if the above camera *could* do what I'm looking for for <$200 that would be pretty darn exciting as it could be an entry level setup (providing it was open source that is so I could customize the firmware as necessary)...


Again,it's something that is *close*, but there's a lot of things that are *close* including the OSD, that's the problem...

Thanks for the ideas-- however the 1394 cameras at the site you referenced are a bit pricey considering they have no processing power available for my application-- the primary PC in my application needs to *take* the motion information provided externally and do some interesting things with it which tend to require significant horsepower-- and sometimes include timing-critical graphics operations that would be adversely affected by tracking processing done on the same box-- in fact my first incarnation worked like that and I quickly realized that the display side needed to be separated from the aquisition side, as the more aquisition activity that occured the worse the display performed.  Consequently, as I've mentioned I've moved to a dual-PC setup.  However, if I could find a combination camera/programmable controller OR frame capture box/programmable controller (preferred, due to the possibility  of using existing cameras and/or prerecorded material) then the solution has the possibility for commercial success-- right now it's a tough sell as a two-PC solution.

A 1394 solution would still require the second PC to do the tracking processing, so it's not substantially different than the two-PC witn frame-grabber solution.  And while there may be a greater possibility of finding a microcontroller with a 1394 interface, the problem then is the camera cost is pretty darn expensive, around $250 when a cheap Chinese-made composite color camera can be had for less than $50 (and no doubt even less in quantity).

With regards to USB2.0-- the problem appears to be not that USB2.0 isn't capable of the datarates necessary to send uncompressed video, but that virtually ALL of the capture products I've found DO compress and ONLY compress,  in order to reduce the bandwidth.    And with conversion of VHS to DVD which is usually what these things are sold for, latency is not a problem.  Consequently, all the USB2.0 capture devices I've found require decompression of the video and thus the undesirable impact on the latency...


At any rate, I've been patient so far, and figure eventually the right device will turn up.   Certainly, if you hear of a USB capture device that doesn't compress, I'd like to hear about it..


Thanks a lot for the help and ideas...

I wonder if you could get more functionality from the camera itself. I cannot recommend anything but I do know there are digital devices out there that should allow you to access raw pixel data. If this is the case then there are many microcontrollers that shoud be able to crunch the numbers is almost real time. Sounds like you have sorted the code to detect moving objects so half the battle is won.

There are IP cameras that come close-- but few are hackable, and those that are are usually not very open (using Linux, but otherwise undocumented so must be reverse-engineered) and are often pretty expensive.    The problem is finding a good microcontroller development system or hackable peripheral product that includes video frame grab, and at least 8M RAM.    I haven't found much in that regard.  It's certainly *possible* for such a device to be constructed but finding one *for sale* has been pretty elusive-- board layout is not a business I want to get into.  That is why I perked up when I heard about the OSD because here we have some video grab and processing power in an affordable and compact package-- the thing is, erroneous assumptions are often made with such devices that fly in the face of my application-- in particular that you always want to compress the video, a second is that latency isn't a big deal-- both of which are true if you are recording to disc, but NOT true with my application.

 I have to do the best I can with available parts, so right now that's why I'm using a PC with a PCI capture card-- overkill because I'd rather not have things like the disk drive, fans, other peripherals such as keyboard, mouse, CD drives,  and misc "compatibility" junk.   While it is possible to set up a small diskless and fanless PC, the price tends to add up compared to a single-board microcontroller which as you point out, *should* be capable of meeting my needs, if I could only find one with capture.  Also, finding a turnkey box that could be programmed with my capture software could present an opportunity to make it available commercially-- I doubt I'm the only one who might find such a thing useful and I have some interesting ideas about how it could be marketed, should I finally find an inexpensive box that I could buy and install my software on and resell without a lot of hardware hacking-- but PC compatibility prices it out of the market, as do many IP cams.   The OSD with an inexpensive security camera has more power than a typical IP cam but would be cheaper than most of them, but again, compression and latency are issues for me beyond that, which is why I'm trying to find out more of the elusive gory details about the OSDs capabilities...

I did note that Gumstix recently announced a "tiny PC" that runs linux for about $189-- if it only supported cardbus that would do the trick, but it doesn't-- just compact flash and ethernet (I'm not sure that it really qualifies as a "PC," rather than a pocket linux box but that's what they're calling it).  Getting close though, they might come up with something before long, or someone will-- I figure it's only a matter of time.  I've been on the lookout for the right one for a couple of years now though, and I got excited when I heard about the OSD-- it seems to be pretty darn close too,  but I get the feeling its video input may be limited by an assumption made in the DM320 design that pipes the video through a DSP in a way optimized for compression.  At least it appears it supports different codecs, so I would think it is at least possible that a non-compression codec could exist and should be easy to write-- but if we can't write our own stuff for the DSP (or we have to buy some horribly expensive SDK) and it hasn't occured to them that a non-compressing codec might be useful, the OSD may fall short of the mark as well...

Sounds interesting, what is your application?.

I can think of several, but my primary one is to replace a second PC that's being used for motion tracking.  The video is not being recorded at all, I need the capture box to process the video in order to identify moving objects, and then all that is sent out is just the coordinates of the objects, not the video itself so the output data is extremely small.   Consequently, I need a couple of in-memory buffers the size of a single-frame capture and a little CPU power that is constantly processing the incoming data, and that's the extent of the requirements.   Sounds easy, BUT- latency is an issue, as it is for a near-realtime application,  the output can't be delayed more than a couple of video frames at the most (faster is better)-- and that is why decompessing something that didn't need to be compressed in the first place is just useless overhead.

I'd consider using something like a "gumstix" product, but nothing they have will support video capture at the moment-- if they come up with a cardbus slot at some point that would probably do the trick as I could plug in a cardbus capture card which will grab uncompressed.  USB video capture is out because it compresses and introduces too much latency (I've tried it).   

Another set of applications that would be relevant here are robotic vision processing where a small SBC with an efficient video capture,  or as I've already mentioned, near-real-time video effects, given both video input and output.

I think there is a huge vacuum in the marketplace right now, as just try to find an SBC that supports efficient capture (i.e., no USB, no compression), and there's basically NOTHING except fairly large and expensive full PC compatibles.   If the OSD can capture uncompressed into an in-memory buffer efficiently, then I see a lot of new applications opening up for it when frankly, there's nothing else out there that does it that's less than an entire PC...

What is RAW?  I haven't heard of it, so I doubt its supported, do you have a link for it so we can look into it?

Raw video.  You know, uncompressed.    At 720x480x4 (full DVD resolution), we're talking 1382400 bytes per frame, not 6M.    As far as specific codec implementations, I don't care which uncompressed format (they tend to differ mainly in the pixel format), but here's a specific one from the Microsoft AVI registration database:

  Compression Code or FourCC Codec ID:    IRAW
  Codec ID in the IANA Namespace:         video/vnd.avi;codec=IRAW
  Description:                            Intel YUV uncompressed
  Contact:
  Intel Corporation
  5200 NE Elam Young Parkway
  Hillsboro, Oregon 97124 USA
  503-696-2448

There also are several raw formats listed on this codec index page:

http://www.fourcc.org/indexcod.htm?main=codecs.php


ANY raw format will do for my application, I don't care which one as long as it's uncompressed as I need to do processing IN THE CAPTURE DEVICE directly on the uncompressed video pixelmap.  Grabbing frames in MPEG4 or something and then having to decompress them in software in the capture device is completely unnecessary overhead and introduces unwanted latency.  A RAW format will dump the pixels into a buffer uncompressed ready for processing without the overhead of a decompression step.

For example, I've tried to run my application with a PC and a USB capture device.  Problem is, USB capture devices cannot send the data uncompressed over USB so they must compress it.  So, the cycle is capture->compress->usb transmit->uncompress->process.    I want to reduce that to capture->process in the capture device itself (the OSD).  The results of the processing are statistical and very small compared to the video data itself, so there's no point in compressing the video data for transmission or storage when neither is going to be done with it-- all that's transmitted are the statistics (essentially).   What I'm doing now is using a PC with a PCI capture card that supports uncompressed formats, and it works pretty well but its a load on the PC that I'd rather move into the capture device and free the PC up for other things (at the moment, I'm using two PCs in order to do that, but a PC is kinda overkill for the video processing step).  The OSD *could* be just the thing, if it isn't impaired by compression->decompression like USB video is.


Another interesting application for the box and raw formats could be a simple video-effect box--  capture->process buffer with effect->output to video.




--

Sync

I finally figured out the block diagram page.    Some Firefox settings show no indication that there's anything to download on the page at all...


But does anyone actually know any technical details about this product?   

Like what video codecs are included perhaps?

Any chance that "RAW" is one of them?  That's the mission critical one for my app...


--

Sync