MATLAB Answers

0

realtime data streaming between matlab and opencv, visual c++

newbie 님이 질문을 제출함. 22 Jun 2012
My C program tracks any particular colour in a video and prints the coordinates of that point. I want to write a matlab program which can take these coordinates as input and analyse them.I am doing all this in windows XP. I have read about mex files and also about the memory mapping but, nothing is working.
When I build my mex file, it shows many errors with the core.hpp file like:
"ptrdiff does not belong to the class std"
can anyone help?

  댓글 수: 0

로그인 to comment.

답변 수: 1

Geoff 님의 답변 24 Jun 2012

How "realtime" do you need? If you were polling a file multiple times a second, would that be sufficient? Can you do your analysis in blocks, or must it be live? After analysis in MatLab, do you need to deliver a result back to the C++ program? How complicated is your analysis - ie is there any reason not to do it in C++?
The best option in my opinion would be to try and get UDP communication going. Have your tracking application simply fire off the coordinates to localhost using UDP on some port. If your MatLab script is listening, it will start receiving the data and can do something with it. If it needs to communicate back, have it fire off UDP packets on a different port, which your tracker is listening on.
Presumably you are comfortable with threading, synchronisation and network communications?
A quick Google search pulled up something vaguely promising:
Or there is TCP/IP code if you feel like bashing your head against a wall:
But if polling a little file is responsive enough, do that. I would just use binary so I could be sure I had read the entire co-ordinate. I'd know how many bytes to expect and, if I appended to the file (preferable to avoid syncronisation issues or data corruption) it would contain a complete record for post-analysis if necessary.

  댓글 수: 9

표시 이전 댓글 수: 6
I'm not thinking so much about the caching as about the problem of having a file open in two places. Even if you did open/read/close cycles since the two ends operate at different speeds you risk trying to open while the other process has it open. So you need a mutex implemented somehow, which is tricky to do right via file-system (especially on a networked filesystem.) Semaphore would probably be the most secure... provided the two processes are executing on the same computer.
A bunch of this can be alleviated if you can defeat the automatic locking mechanism that MS Windows uses that prevents a file that is opened for reading from being opened by another process. I don't know how to do that: the existence of that lock is not ISO compliant, and when I read the MSDN documentation about open() options and fctl() and the other standard mechanisms for controlling such matters, I cannot find any reference to that automatic lock existing at all. :(
Walter, I didn't believe you about having file locking problems, and I expect this is to be run on a local machine and local disk. So I decided to benchmark it. I made a simple source/sink console application using stdio functions, and had it output packets containing the performance counter value at the source. The sink would read these immediately after querying the performance counter and output the packet lag. Source and sink ran as two separate processes. At 30fps, including a 1ms Sleep in the read loop, the lag peaked at 3% of a frame. I ran it at 500fps with no Sleep and the peak was about 7% lag (with the Sleep it was around 60%, which is to be expected). In short: communication via file is perfectly viable. At least, in C. I did not test this using MatLab as the reader, but I don't see why it would be a problem. Just make sure you call fflush() after writing. You can have the file open for write on the source and read on the sink simultaneously with no problems.
Okay, had some more fun with this. I ported my Sink code to MatLab and confirmed this method works fine - average lag was 0.05% of a frame with very occasional peaks up to about 2%. No frame dropping observed. Caveat is that you need to busy-wait (ie poll the file stupidly fast) or MEX a better pause() function. I would take the simplest route and poll very fast, because this at worst is only going to max out one core. Anyway, that core is going to spend the rest of its time processing co-ordinates, so getting hold of a co-ordinate ASAP means you have about 30ms to process it.

로그인 to comment.



Translated by