Re: [SeattleRobotics] monitor output
i think for image processing opencv which is a package
of c++ could be useful
and for capturing image you can use fram grabber
i hope that helps
--- Nate W <delaminator@...> wrote:
> I hit send a little too soon...__________________________________________
> On 1/3/06, Nate W <delaminator@...> wrote:
> > If the goal is to move a series of images from one
> computer to
> > another, it would likely be cheaper and easier to
> connect the
> > computers with ethernet and send the images as
> > VGA capture cards exist, but they're not cheap:
> > http://www.pixelsmart.com/vga.html
> If you don't need high resolution (about 640x480 or
> better), you might
> be able to save money by converting the VGA output
> from the first
> computer into a composite video signal (converters
> are under $100) and
> then capture the composite signal (lots of options
> exist for this,
> less expensive than capturing VGA).
> > On 1/3/06, Bryan <BNHrobotics@...> wrote:
> > > I am thinking about attempting a project where I
> will need to get the
> > > output from a monitor. I have a laptop with a
> monitor port that I was
> > > thinking about using. Does anyone know what I
> need to do to take the
> > > data output and do something useful with it?
> Ideally, I would like to
> > > be able to do image processing on the output
> with a second computer.
> Visit the SRS Website at
> Yahoo! Groups Links
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
> I would like toWhy use two computers?
> be able to do image processing on the output with a second computer.
I've been working on a project in which we store and later analyse
R/G/B/Sync signals (presumably your portable can produce those). It turned
out to be far more difficult that I expected. Most capture cards come with
s/w to capture N frames to disk. Getting the frames into your program as
"live" pictures is harder. In our case, it was particularly hard because we
couldn't afford to lose a single frame and because we had to be able to
synchronise the frames with other incoming data (to the nearest frame). We
have yet to find a suitable card. Cards drop frames. There's a variable
delay between the camera and the input buffer. You probably don't care
about delays or dropped frames so you can buy a cheaper card.
My main advice would be to check what driver s/w and program-interface s/w
the card comes with. What languages do they support? Is there good
technical support from the company? Windows already has a video-input API.
Does the card support it? How well? See if there's a user's forum full of
Another question is: how does their driver s/w buffer the frames? A proper
frame-queue would be good for us (so if we have to rush off and attend to
some other matter, we don't lose frames) but we've only come across
double-buffering. One of the cards we used required a permanent partition
of memory for it's buffers - so we lost memory even when we weren't running
Compared to getting the data into the computer, analysing it was easy.