Using the DLL files of an application compiled with C# with labview

[alvise]

I started to understand some things, but not completely.Any ideas what to do now in this situation?

[dadreamer]

28 minutes ago, alvise said:

Any ideas what to do now in this situation?

Your diagram still doesn't look like I'd like to see it.

- You read the image in frame named "1", whereas it should be named "1.." (with two dots after 1), that means "greater than or equal to 1"

- The other frame should be named as "..0" or "0, Default", that means it will proceed values other than positive ones.

Do you receive the same error message after these modifications?

[alvise]

it still keeps getting error.

[dadreamer]

Ok, try then to replace this NULL Handle check with another one shown here: https://forums.ni.com/t5/LabVIEW/How-to-extract-image-from-VLC-active-x-to-LabVIEW-image-JPEG-or/m-p/4117244#M1187715 Take a look at the condition below "Check to see if the Image passed in exists." comment. If that also is of no help, then you need to search for another way of getting the image (say, save a snapshot to the drive first and read out the file second).

Edited May 26, 2022 by dadreamer

[alvise]

I tried something like the image below and now I don't get an error but I can't get the image either. It can only read the picture at the added address.

 

I think you suggested the method used with VLC, I'm trying it right now, recording jpeg and reading it again later, but the display speed is quite low.Again, thanks for your suggestion.

Edited May 26, 2022 by alvise

[dadreamer]

14 minutes ago, alvise said:

you suggested the method used with VLC

No actually. Only this piece.

 

[alvise]

It gave the same error again.Using VI reference instead of picturebox won't work, right?I guess there is no other way.

[dadreamer]

You forgot brown error wire. 🙂

[alvise]

I connected it, no error, but no picture either

[dadreamer]

Then it should be that HCNetSDK.dll draws on the window canvas directly, not dealing with any related objects. I don't see, how you could easily intercept the data. If you are serious about HikVision image processing in LabVIEW, you'll have to return to the callback attempts.

[Rolf Kalbermatter]

22 minutes ago, dadreamer said:

Then it should be that HCNetSDK.dll draws on the window canvas directly, not dealing with any related objects. I don't see, how you could easily intercept the data. If you are serious about HikVision image processing in LabVIEW, you'll have to return to the callback attempts.

That's definitely the case. He only passes the window handle of the Picture box into the HikVision camera. And the SDK then directly bitblits into that window surface. It does not know about PictureBox or anything, only the window handle. The PictureBox really just is placeholder to provide a handle. It would likely better work if you actually called the LabVIEW VI Server Method "Get Image" on the LabVIEW .Net Container Refnum rather than the PictureBox .Net  refnum. Yes it is not exactly intuitive but fairly consistent with other LabVIEW controls. The terminal is the data (for a .Net control its contained object class refnum) but the VI server interface has to be retrieved either from a Reference node or the Property/Method needs to be implicitly linked to the control

 

Edited May 26, 2022 by Rolf Kalbermatter

[Gribo]

Where does the ugly font and background noise come from? If you want to convert a .NET picture box to LV picture, you can construct a .NET Bitmap object with the image, and read its pixels.

Edited May 27, 2022 by Gribo

[Rolf Kalbermatter]

27 minutes ago, Gribo said:

Where does the ugly font and background noise come from? If you want to convert a .NET picture box to LV picture, you can construct a .NET Bitmap object with the image, and read its pixels.

The problem is that the .Net PictureBox does not contain an image. It is just used to get a window handle to pass to the SDK library which then draws the image data directly onto the window surface. And the PictureBox knows nothing about that and therefore won't return any pixel images for the non existing image it has.

The LabVIEW control method Get Image on the other hand should simply take a screen shot of the control screen area. It's the only way to get an image for LabVIEW as it does not know what object control is displayed in it and most classes do not have a GetBitmap method anyways. For native controls it may use a control method, which redraws the control into a bitmap, but for the .Net and Active X Control that certainly won't work and the only way to get an image is by doing a screen capture of the area.

Edited May 27, 2022 by Rolf Kalbermatter

[dadreamer]

I'm not a big fan of Get Image method, because it has a whole load of disadvantages:

• runs in UI thread only;
• requires a front panel to be open (and visible to reflect the changes);
• redraws an image after the control modified it (i.e., scaling, cropping etc.), so if you have the original image of 1024*1280 pixels and it's rendered into the control of 10x10 pixels, you'll get those 10x10 pixels instead;
• draws control's label/caption additionally (sometimes it's wanted, sometimes not);
• doesn't work for some third party ActiveX/.NET controls (maybe, because they all use different rendering techniques);
• sometimes lags / doesn't capture the image.

When it goes to capturing the window contents by its HWND, I prefer this self-written VI (based on WinAPI calls).

Get Image By HWND.rar

And I'm using it that way.

Maybe in alvise's case it will suit as well - the chances are slim, but real. 🙂

Note also: the CLFN's in Get Image By HWND.vi are set to UI thread now, but it's safe to set them to any thread, if desired.

Edited May 27, 2022 by dadreamer

[alvise]

I tested this example you shared, if I use it with a VI with no display screen it's fine, everything works fine but when I try to use it with live video streaming it causes the display to be choppy and not capture the whole screen.

I'm trying to do what Rolfk said, but I don't understand exactly how it can be done.

[dadreamer]

15 minutes ago, alvise said:

I tested this example you shared, if I use it with a VI with no display screen it's fine, everything works fine but when I try to use it with live video streaming it causes the display to be choppy and not capture the whole screen.

Share your VI or a snippet.

[alvise]

The code is the same as here . I just added the example you shared.

[Rolf Kalbermatter]

34 minutes ago, alvise said:

I tested this example you shared, if I use it with a VI with no display screen it's fine, everything works fine but when I try to use it with live video streaming it causes the display to be choppy and not capture the whole screen.

I'm trying to do what Rolfk said, but I don't understand exactly how it can be done.

Yes, this choppyness is of course expected and there is nothing you can do about it with this method. The SDK function draws into that window handle when it pleases and how it pleases. Your Get Image function copies the screen pixel into its own buffer when it pleases and how it pleases. No synchronization whatsoever. And there is no trivial synchronization possible.

If you were old enough you would know a similar effect from television when a TV screen was captured by a TV camera. Since the two never ever work exactly with the same picture frequency you get stripes and flickers across the screen as the camera picture takes part of one image and then part of the next image in each image shot and the dysonchron frequency causes the stripes and flickers to wander up or down on the screen.

[Rolf Kalbermatter]

2 minutes ago, Rolf Kalbermatter said:

Yes, this choppyness is of course expected and there is nothing you can do about it with this method. The SDK function draws into that window handle when it pleases and how it pleases. Your Get Image function copies the screen pixel into its own buffer when it pleases and how it pleases. No synchronization whatsoever. And there is no trivial synchronization possible.

If you were old enough you would know a similar effect from television when a TV screen was captured by a TV camera. Since the two never ever work exactly with the same picture frequency you get stripes and flickers across the screen as the camera picture takes part of one image and then part of the next image in each image shot and the dysonchron frequency causes the stripes and flickers to wander up or down on the screen.

The LabVIEW Get Image method may look slightly better since LabVIEW has minimal control over when someone may draw into that control. But it most likely won't avoid the problem completely.

[dadreamer]

I assumed, you would feed the PictureBox handle into Get Image By HWND.vi instead of feeding a panel window handle. No need to use FP.NativeWindow here. Just typecast the handle refnum to U64 and wire to that VI.

[alvise]

Dadreamer, if you're talking about something like this, I tested it and couldn't get a picture.

 

 

38 minutes ago, Rolf Kalbermatter said:

The LabVIEW Get Image method may look slightly better since LabVIEW has minimal control over when someone may draw into that control. But it most likely won't avoid the problem completely.

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.

 

[Rolf Kalbermatter]

39 minutes ago, dadreamer said:

I assumed, you would feed the PictureBox handle into Get Image By HWND.vi instead of feeding a panel window handle. No need to use FP.NativeWindow here. Just typecast the handle refnum to U64 and wire to that VI.

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!

Edited May 27, 2022 by Rolf Kalbermatter

[alvise]

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.

[Rolf Kalbermatter]

6 minutes ago, alvise said:

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.

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.

Edited May 27, 2022 by Rolf Kalbermatter

[Rolf Kalbermatter]

31 minutes ago, alvise said:

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.

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.

Edited May 27, 2022 by Rolf Kalbermatter