timing delay caused by showing images

[jwkelly]

We have a system setup where timing is critical (all processing needs to stay below 33 ms for each iteration). In one option for the system, we need to be able to display a series of images. These images can be on a front panel, in a separate window, or wherever they would be viewable by a user. Every method I've tried to display an image causes a delay in the system of at least 100 ms. So far I've tried the following:

1) .NET PictureBox
2) 2D picture control

3) VLC Player ActiveX control

- for 1, 2, and 3, I tried using one control and inserting the new image each time, and I tried creating two controls, one hidden and one visible. The next image is drawn into the hidden control, and then when it needs to be displayed it becomes visible and the other one hidden.
4) Array of 2D picture control, iterating through the array to change the displayed image
5) pict rings, but these apparently can't be programmatically populated
6) 3D picture control
- for 6 I tried making a box object and putting the image on it as a texture, and then changing the texture image when needed. I also tried making separate objects with each image as a texture on a different object, and then moving the camera to the different objects when needed. As would be expected, all the 3D methods I tried had much worse performance than the 2D controls, but at this point I'm willing to try almost anything.

It should also be noted that this delay occurs even if the main execution loop (the time critical one) sets a flag which causes a parallel loop to display the image. Also, this has been attempted across the network, with the image display occuring on a separate instance of LabVIEW on a remote computer. Finally, we would also like to be able to play videos. After trying WMP and QuickTime ActiveX controls I finally got VLC 1.0.5 working bug free, but the same delay occurs. I would be happy just getting the pictures to work right now, but if anyone has any video suggestions I'd love to hear those as well.

[Yamaeda]

I've had similar problems, the base problem is that ActiveX forces execution in the UI thread, how to get around it is alittle tricky.

This is things i tried but i'm not 100% sure of the success of them. 🙂

One way around it should be to bundle it in a subVI and start it in a parallell loop (as you tried) but make sure your processing VI's is in another thread group (like data processing).

Another is to start the sub-vi through VI server which should result in a separate process.

Since i use events alot in my current project the solution i prefer right now would be to generate an event and have the picture control running as a separate process executing the ShowPictureEvent (or what you'll call it). 

/Y

[jwkelly]

Thanks a lot for your quick reply. Is there any way to enforce determinism using this method? Sorry I failed to mention this in my initial post, but I tried the parallel loop thing out of curiosity. For example, if on iteration 100 of the main execution a call is made to show a certain image, I need to know that that image is actually drawn on the display before iteration 101 of the main execution starts. If I used the VI server the only way I could think of doing this is to set a flag in the sub VI saying that the picture is drawn and the caller VI would poll that flag, but then wouldn't I run into the same delay?

Also, I realized ActiveX was probably an issue, but when I tried using a normal 2D picture control (no use of property nodes whatsoever) I really expected that the delay wouldn't occur.

[Joe D.]

Hi jwkelly,

Are you using LabVIEW? if so does this happen if you have an indictor on your front panel? Also could you post the LabVIEW vi?

[Yamaeda]

No, with that technique there's no way to be deterministic. If the drawing of the picture takes 100ms and you want 33ms loop time you're in trouble. 🙂

 Are the picture predetermined? If so you should be able to preload them into a picture ring. I'll have to try that out.

/Y

[Yamaeda]

I just did some testing, and a .NET PictureBox seems rather fast and is easy to implement.

If it's enough is another matter.

/Y

[jwkelly]

@Joe D.

I'm using LabVIEW 2010. The actual VI is part of a large, complex system that there would be no way for me to upload here. I've made a simple, bare-bones VI, though, that simulates what we need to do and reproduces the problem.  The attached VI requires an img1.jpg and an img2.jpg in the same folder as the VI. Note that we could have much more than 2 images, so although in the example VI re-drawing the images in the hidden picture box isn't necessary, it is needed in our actual system.

@Yamaeda

Thanks again for your suggestions. I looked into pict rings, but I couldn't figure out a way to programmatically populate them. It seemed like all the images had to be loaded ahead of time. I tried the .NET PictureBox without success but I'll give it another shot. It just seems unreasonable to me that displaying an image would take that long. It isn't a restriction due to the Computer or OS itself, because I know this can be done in C++ and I think even in MATLAB. It also seems like no matter what I use to draw or show the image, and whether it's in parallel or not, the delay occurs as if's delaying all of LabVIEW's threads no matter what.

[jwkelly]

I think before when I was using the .NET PictureBox I was manually writing to the PictureBox.Image property rather than using the Load method. I didn't notice that method existed, but I imagine it's much better than what I was doing. Using that definitely simplified things over using the 2D picture control and it seemed like it cut the delay down quite a bit (I'm seeing about 125-150 ms now instead of 250-300), but it's still not as fast as what I need. Demo with the .NET PictureBox is attached.

[Yamaeda]

Try the LoadAsync(), it'll load asynchronously (sp?) so you'll get beautiful loop times, although not 100% guaranteed image showing speed. I think it'll be close

enough though. 🙂

On my computer i manage the 33ms loop time down to ~0,06sec switch time. Then it'll start to go up and down.

/Y

[Yamaeda]

I played around some, take a look at this and see how you like it.

/Y