All Activity

My debt is debt The problem here is weird and interesting. Gribo I agree with what rolfk said here. I tried something like this and got no results. I tried to capture the image for the whole Main VI screen, everything is showing but the video in the picturebox area is not showing, interesting thing. I was wondering how it would be with the VI screen, but of course the result is disappointment

It wasn't me who brought that back into the discussion. I was under the strong impression that we were already working for some time on the PictureBox solution as drawing canvas area. alvise suddenly brought this Empty.vi subpanel solution back into the picture.

That callback will almost certainly never get triggered! The SDK is not aware about that it is drawing into a .Net PictureBox. It only sees the window handle that is used by the PictureBox for its drawing canvas. And that works on a level way below .Net in the Windows window manager inside the kernel. If you would try to do anything with that PictureBox such as drawing lines or anything into, it you would get very nasty flickering as the SDK function trying to bitblit into the windows device context (HDC) will fight with the PictureBox functions who tries to do GDI drawing into the same HDC. We are abusing here the PictureBox simply as a container to provide a window handle. In this way we can let Windows window clipping handle all the issues about making sure that the SDK can't draw beyond that area provided by the PictureBox control. But for the rest we are not really using any functionality from the PictureBox .Net control. Respectively when we tried to retrieve the image, that failed since the PictureBox control is not aware about what was drawn into its window. And the same applies for the LabVIEW Get Image control function.

I have nothing to add to this thread, other than @alvise I think if you get this working you owe a few people some beer 🙂 To those patiently contributing to this thread, I sincerely thank you. This community is so much stronger due to you folks. Please never leave!

You can copy the snippet. Explanation: The Bitmap is a constructor node, and you give it the image reference. Then you get the data, in this case, one RGB pixel at 0,0. If this works, the bitmap object has a method that returns the handle to the data. Edit: The Bitmap constructor is in System.drawing. If you are worried about tearing (capturing data from 2 different frames) you can use the PictureBox' VisibleChanged LoadCompleted callback.

No I haven't tried it, how exactly should I do it?

Probably not the first one and most likely not the last?

Did you try this method?

I have no idea how to do this, if anyone guides me I can go step by step

There exists an easier callback variation, that doesn't involve calling PostLVUserEvent. I have used it few times in the projects with VLC video streaming from several cameras. It's an asynchronous method too, but it works for sure. The main point is that on the diagram we call DSNewPtr and pass new pointer to the library. When the callback is called, it just writes data by that pointer. In LabVIEW we just read the data by the pointer constantly and process it, if necessary. It's good for common video translation or for simple image processing, when not each video frame is required. Still needs the DLL to be written/compiled though.

I meant this part: It just makes no sense to capture Empty.vi window and a little sense to capture the whole main VI window, when a concrete .NET window region is wanted. Ok, when drawn onto Empty.vi panel, the whole window must be captured.

Although it is a different alternative for image processing, I don't want to deal with the callback function. But as far as I understand, there is no alternative way.

I would not recommend you to do it. But It is your time and frustration.

Seven years later, another incarnation of VPN and ubuntu 20.04, still the very same problem hit me again for LV14.0: immediate crash if started while Checkpoint snx is running, no crash if snx is started afterwards Not with LV2019, not 2021 in the same conditions... Since I need specifically LV14 for a legacy project, I have to remember where I put the 14SP1 installation media.

It's definitely bad luck. I have no luck I don't believe my luck at all. I guess I'll have to tinker with the callback function again.

That's bad luck.

I guess it only shows the picturebox itself and not the data inside

There definitely is data in the "Image Data" Cluster. Of course you forgot again to show the part of the screen where it would display the "new picture" to proof your claim that there is nothing shown. So we can not tell what is captured but something for sure is captured. You may also want to remove the Draw Unflattened function. It adds nothing anymore.

I did as below and 2D picture image is not taken.

Fun! Good luck in your new endeavor. But the LabVIEW development team loses a very valuable and important member for sure.

Of course you do as you use the VI refnum. Right click on your PictureBox control in the LabVIEW front panel and select Create->Reference. Connect that reference to the Method node instead of the VI reference. And of course you need to use the VI with the PictureBox that you had earlier, not the one trying to use the subPanel.

That code does not exist yet (in a public location)! So yes it is impossible. More precise: That code does not exist yet in a public location! It for sure has been developed numerous times for various in house projects, although almost 100% certainly not for the HikVision SDK. But in-house means that it is not feasible or even possible to publish it because of copyright, license and other issues. And even if those issues would not exist, nobody is going to search his project archives for the code to post here.

What I'm really wondering is if we use the callback function, will it solve the Image display problem? -Because I don't know how to write the dll file that will make the callback function, I need to find a ready dll file. This situation is close to impossible. If I can find a piece of code that will work just fine, I can compile it here.

Doesn't matter. The SDK draws asynchonously into the Picture Box window. No matter which window handle you use, the moment you cause the screen capture from the window handle to occur is totally and completely asynchronous to the drawing of the SDK. And there is a high chance that the screen capture operations BitBlit() or PrintWindow() will capture parts of two different images drawn (blitted into the window) by the SDK function. So yes after all these troubles we may have to consider that what we did so far is perfectly fine for displaying the camera image on a LabVIEW panel. You can also cause the SDK to write the image data into a file on disk. But if you want to get at the image data in realtime into LabVIEW memory to process as an image, you won't get around the callback and that is where I stop. This would be a serious development effort even if I did it all here on my own system for a real project. With the forum back and forth and the fact that it is advanced callback programming that even seasoned C programmers usually struggle with, it's simply unfeasible to continue here. And I already see the next request: You did it with IMAQ Vision images but that comes with a license cost. Please I want to do it with OpenCV to save some dollars! And a multiday development job turns into a multi week development job with one single sentence!

Dadreamer, if you're talking about something like this, I tested it and couldn't get a picture. With get image, I get the image of the VI that I am trying to get the image from, everything works fine, but it does not get the image. If I take a numeric and change it on the viewing screen, the change is immediately visible on the 2D picture screen, but the camera image is not visible.