Analyzing a video-source with propeller

propwell

Hi together,

i've got a video-signal from a camera wich is very sensitiv to IR-wavelengths. Also, i've got anoter signal from a normal camera.
Both PAL/NTSC-based. Now i want to read the pixels of the IR-image where the values are very high (very bright --> much IR-input), maybe by setting a threshold.
I've realized the OSD form Terry Hitt before, but that doesn't read the incoming signal!

Has anyone an idea for that?

Thank you,
Max

Graham Stabler

There was a recent thread discussing an implementation of what Hanno has done:

http://forums.parallax.com/showthread.php?p=878680

It also links to Hanno's article about this.

Basically he uses a ADC to digitize the video signal but keeps only 4 of the bits, these nibbles can then be packed in to longs etc for storage and processing. Generally storing high bit depth high resolution data would be too much for the propeller's RAM so this is a neat fix.

I wonder as well about binning pixels to reduce resolution (and ram needs) for things like blob tracking and the like.

Graham

MagIO2

I think it's definitely not doable. When I remember right the hard work in the OSD has been done by external hardware: mixing 2 signals together. The prop was used to generate the On Screen - text.

I'd think that mixing of 2 independend video signals is not that easy, as they can be totally out of sync.

Hanno

Thanks Graham!

Max,
This is definitively doable- although capturing/processing video with the Propeller is not for the faint of heart...
Download ViewPort here: hannoware.com/viewport

It comes with 2 objects that will help you:
PropCapture: frame grabber that digitizes an incoming NTSC signal into hub ram at configurable resolution with 1 cog
PropCV: pasm kernels to continually filter video signals in a cog to extract information- for example location of the brightest spot

Here's the easiest way to proceed:
- 1 cog running PropCapture to capture the IR camera
- 1 cog running PropCapture to capture the visible light camera
- 1 cog running PropCV to find the brightest spot in either captured frame (wasn't clear which you were referring to..) This will write the location of the spot into a long in ram
- 1 cog continually assembling an image using the two captures frame streams and the location to swap
- (for debugging) 1 cog to run Conduit to share data with ViewPort so you can see what's going on, including the streamed variables and the streamed video
- 1 cog to output the image to TV/VGA

Needless to say, with the Propeller's limited RAM, you won't get HD video... I believe PropCapture's low res is something like 160*100- 4 of these fit into the 32kb.
Again, not easy, but this sounds like a cool project!
Hanno

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer

propwell

Hey Hanno,

thank you for your advise!
I think that normally it wouldn't be necessary to read and output the visible-light image, as i maybe could use the Hitt-OSD. It would be perfect if i could read the IR-Image, find the brightest spots (their koordinates) and draw these spots via the OSB onto the normal Picture!
So the resoultion of the visible-light-picture is not changed, and the resolution of the drawn images doesn't need to be to high...

[noparse]:edit:[/noparse] ah and, what kind of special hardware do i need? is this nearly real-time-possible?

Toby Seckshund

I was pratting about with VB, years ago, in a 1.2GHz P3 laptop. Taking in a webcam with 288xsomething the processing was very slow and the only way around it was to choose a grid pixel points to sample. This was weighted more to the outside edges, to spot new items entering view and as many as poss points within the view, that time would permit.

Varying those points would spot the small things between the original points but could let something moving (in a perfect manor) elude any active samplings. I managed to get it to draw litle white boxes that followed the Guinea Pigs about in their run.

In homage to "The fifth element" it would keep on flaging up "She has no file". The missus just didn't see the funny side.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

Hanno

Very funny! Yes, reducing the number of pixels makes filtering much faster. Although the Propeller running assembly is plenty fast- probably better than your 1.2GHz laptop! I was chaining several filters together with PropCV and still got something like 20fps! Worked well for finding the brightest spot, or following a black line- there's a video on my site somewhere...
Hanno

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer

Cluso99

I just love this forum. Saying something is not doable almost always brings out someone who has an idea on how to do it or has done something similar.
Thanks Hanno
The prop really is versatile! So what are we going to do with Prop II when it arrives... 8x faster, >8x hub memory, vastly improved counters, 2x I/Os !!!

Message for Chip... Back to work !!!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Hanno

Yes, the people on this forum are a treasure. I finally met Bob last night- he made it all the way to New Zealand. Good things coming to C and ViewPort soon... For me PropII means I'll have to redo my video capture+analysis in color!
Hanno

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer

Phil Pilgrim (PhiPi)

propwell,

For overlaying the bright IR pixels atop the visible image, you need to make sure that the fields-of-view for the two cameras are as close to equal as possible. Otherwise (without extra scaling, and neglecting parallax -- the bad kind, not the Rocklin kind), your overlay will be accurate in the center but not at the edges. How do your two fields-of-view compare? If they're off, can you change lenses to correct one of them?

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 2/25/2010 3:29:17 AM GMT

Graham Stabler

Good point Phil, easy to forget the physical realities of these things. There is not much chance of scaling and shifting in software so it has to be right physically.

Perhaps flicking between sources might be more versatile, that's what the predator does [noparse];)[/noparse]

Graham

propwell

Hi together,

thank you for your answers!
@Phil: yeah the two cameras have quite the same field-of-view. I can manage that with some optical stuff.

Has anyone some idea how to do that? I thought about maybe setting up an electrical circuit, which thresholds the video-signal to a Low/High signal, so i could read it without an ADC. Could be much faster. What do you think?

[noparse]:edit:[/noparse] i read about a multiplexer, could that help?

Post Edited (propwell) : 4/15/2010 3:00:43 PM GMT