AVI Frames Being Overwrittten

[SoheylV]

Hi everyone,

For a vision application, I'm trying to stream the image date, as well as create an AVI. For some reason, I have to first flatten images to string, and then unflatten for both creating a picture, as well as adding frames to the AVI. In the attached VI (simplified version of my application), when the Record button is pressed, the last 50 frames are written to a text file. When the Create AVI button is pressed, that file is converted into an AVI.The stream boolean determines if a stream of images is shown to the user or not.

The problem is if the Create AVI button is pressed, when the Stream is on, some of the frames in the AVI are overwritten, I assume by the latest values of streaming images. If I turn off the streaming before pressing the Create AVI button, the video is OK. How can I avoid this? 

 

Thanks,

Soheyl

[ijustlovemath]

You could set the Disabled property on the Create AVI button using the value of Stream. That way it's not possible to run into this error while streaming.

[SoheylV]

That would be a workaround, but I'm curious to know what is happening, and a more fundamental solution.

[Bob_Schor]

What you are doing seems very strange to me.  You create IMAQ Images at some Frame Rate with Cam0.  These Images can be directly viewed (without any conversions) in an IMAQ Display (rather than as a Picture).  Similarly, the Image can be directly saved in an AVI file, no flattening or other conversion needed.

We have an application where the Camera is viewing a subject at 30 frames per second and showing us the video.  When a specified "event" happens, an AVI is created from the Images so that we can save video snippets surrounding the Event.  It's been a few years since I looked at that code, but as I recall, it was very straight-forward, no special conversions, no "flattening", no JPegs, and no Picture objects (just IMAQdx stuff).

Bob Schor

[SoheylV]

Hi Bob,

Thanks for the reply. As I had mentioned in my first post, this VI is a simplified version of our application. In the real application, there is a need for all these components. For example, frames are captured on a CVS and streamed over TCP to a PC server. You cannot create AVI on the real time target that we use. And we need the picture indicator for some further processing. So we cannot change the code architecture.

Even for this simplified code, I still don't understand why this problem should occur.

Thanks,

Soheyl

[Bob_Schor]

---

@SoheylV wrote:

Thanks for the reply. As I had mentioned in my first post, this VI is a simplified version of our application. In the real application, there is a need for all these components. For example, frames are captured on a CVS and streamed over TCP to a PC server. You cannot create AVI on the real time target that we use. And we need the picture indicator for some further processing. So we cannot change the code architecture.

---

I'm not sure what you mean by "Frames are captured on a CVS and streamed over TCP to a PC Server".  I also think you may be unnecessarily complicating life for yourself by deciding in advance on data formats (such as the Picture indicator).

I think I noted that we use the IMAQ Display to see, in "real-Time", the video coming from the camera.  We also have other sensors that we are monitoring that says "OK, save 5 seconds of video on-the-fly to an AVI file".  What I didn't say was that the camera(s) and sensor(s) are four floors away from the host PC, are communicating with the Host using TCP/IP (the cameras are Ethernet cameras, not USB), and we're monitoring 24 Camera/Sensor pairs in parallel with a 5-year-old Dell Precision Workstation.

What are your frame rates?  I would think if we could handle 24 cameras running simultaneously at 30fps (though we are probably only writing a few AVI file snippets at the same time), you should be able to do the same, provided (a) you aren't "wedded" to the current method that you are using that you say doesn't work, (b) your hardware isn't an order of magnitude slower/older than ours, and (c) your data stream isn't an order of magnitude higher than ours.

Bob Schor

[Hatef.fouladi]

ok what I guess with your code you are trying to sending some hidden data inside the image
test this i think it could solve your problem
when you use read from binary file
change your data type to array of u8 array instead of using array of string and then wipe unfilatten vi and use array to image vi

[Hatef.fouladi]

ok sorry for my short answer 
I modify your vi to solve your problem but still some useless part in your code that you have to change them 
indeed your problem is that when you want convert your file to avi and in the same time use streaming you use two unflatten vi in same time and it make buffer Interference