VI snippets and security

[Rolf Kalbermatter]

I've been playing around with the possibility to create VI snippets even in older versions than 2009 and during that work I was suddenly wondering about the security for this.

I'm pretty sure NI has thought about this, (it's probably another reason why a VI snippet only includes the top level diagram and no subVIs) and has implemented the dropping of a VI snippet in such a way that there can not be any automatic execution of code.

However trying to implement that with the available LabVIEW API methods in LabVIEW < 2009 might be more tricky. I have not yet tackled the problem of turning a diagram selection into a new VI, to create a VI snippet from and also not the problem of dropping the VI contained in a snippet into a diagram, but the latter could supposedly reuse a lot of the techniques used in the inlining tool posted elsewhere here.

But in order to do any of these one has first to instantiate the VI code from a snippet in memory and that is where I started to wonder if there is any kind of VI type, XNode, XControl, X anything, that does do code execution as soon as it is opened in the LabVIEW editor. I know that some of them will execute code when they are dropped to a diagram but do any of you know of cases where even opening such VIs (through VI server, not interactively) would execute something automatically?

The reason I ask this, is that if the chance for something like this exists, I will abandon this idea.

Rolf Kalbermatter

[Yair]

There are the callbacks you have when LabVIEW does certain operations (e.g. opening), which might also apply when opening a reference using VI server, but those are VIs located in a specific location in the LabVIEW folder, not the actual VI you open.

Also, I'm not sure, but I think XControls also call their init ability not just when dropped, but when first loaded. If the VI loads the FP (e.g. if it has property nodes), it might call this init ability as well, but I'm not sure. This would presumably appear in the documentation and a simple test can also give the answer.

Regardless, as I've already mentioned in the emails, I don't think this is a project worth spending time on, but it is your time to spend as you wish.

[Rolf Kalbermatter]

There are the callbacks you have when LabVIEW does certain operations (e.g. opening), which might also apply when opening a reference using VI server, but those are VIs located in a specific location in the LabVIEW folder, not the actual VI you open.

Also, I'm not sure, but I think XControls also call their init ability not just when dropped, but when first loaded. If the VI loads the FP (e.g. if it has property nodes), it might call this init ability as well, but I'm not sure. This would presumably appear in the documentation and a simple test can also give the answer.

Thanks I will probably do some tests with this, eventhough I do not know much about XControls yet. But it's a good way to get acquinted with them.

Regardless, as I've already mentioned in the emails, I don't think this is a project worth spending time on, but it is your time to spend as you wish.

I know . In any case it has given me already a nice VI library that can read and write PNG files both from disk as directly into a memory stream. Something the built in LabVIEW solution can't do. And it even supports alpha channels although the picture control doesn't support this yet.

Rolf Kalbermatter

[vugie]

... And it even supports alpha channels although the picture control doesn't support this yet.

You probably know that, but LV PNG functions supports alpha channel for both reading and writing (it is stored within image data). The Picture control uses it, but applies a threshold for alpha to create mask. I wrote a VI (it's included in BitMan) which combines picture with full alpha with part of front panel laying below Picture control in order to simulate full alpha blending with front panel.

PS. Your project idea is not clear enough for me... Do you want to create VI back from image for LV<2009?

Edited August 28, 2009 by vugie

[Rolf Kalbermatter]

You probably know that, but LV PNG functions supports alpha channel for both reading and writing (it is stored within image data). The Picture control uses it, but applies a threshold for alpha to create mask. I wrote a VI (it's included in BitMan) which combines picture with full alpha with part of front panel laying below Picture control in order to simulate full alpha blending with front panel.

PS. Your project idea is not clear enough for me... Do you want to create VI back from image for LV<2009?

I wanted to create a possibility to create a VI snippet in LabVIEW versions prior to 2009 and in fact I can go as far back as to 7.1, although I haven't really tackled the entire problem to turn a diagram selection into a VI Snippet, only for an entire existing VI so far. The main motivation would be to add this to the CCT as an extra possibility.

Turning an existing VI Snippet from LabVIEW 2009 into a VI before 2009 is not an option as I have no way to back-convert VIs. For VI Snippets created with that tool turning them back into a VI of the same or newer LabVIEW version is of course not difficult either, but the direct dropping into a diagram is no option due to the lack of suitable drag and drop hooks into the diagram.

And I'm not sure how you do get at the alpha channel data in the normal LabVIEW PNG File functions. As far as I could see you only have a threshold to apply to the alpha channel and the VI returns simply a on off mask only.

Rolf Kalbermatter

[vugie]

And I'm not sure how you do get at the alpha channel data in the normal LabVIEW PNG File functions. As far as I could see you only have a threshold to apply to the alpha channel and the VI returns simply a on off mask only.

The image cluster you get after loading PNG still contains 32-bit image data. All you have to do is to extract from it each fourth byte and it's an alpha channel. Also when you preapare image cluster with such a data PNG will be saved with correct transparency. I don't have LV now to show an example, but check BitMan's (from CR) VI "LV image to Bitmap", "Bitmap to LV image" and "Bitmap to Picture with Alpha"

[PJM_labview]

I also have been using this method for years to simulate alpha blending in a picture control. Another use case for this is in a tree control where you could get (png) glyphs to perfectly blend with the tree control background color. I am very glad that the alpha channel was left in the png image data.

PJM

[Rolf Kalbermatter]

The image cluster you get after loading PNG still contains 32-bit image data. All you have to do is to extract from it each fourth byte and it's an alpha channel. Also when you preapare image cluster with such a data PNG will be saved with correct transparency. I don't have LV now to show an example, but check BitMan's (from CR) VI "LV image to Bitmap", "Bitmap to LV image" and "Bitmap to Picture with Alpha"

Ahhh I see. That works of course for RGBA images but PNG also supports an alpha channel for 2, 4, and 8 bit color and gray scale images with palette (and a variant with a single mask value defining a specific color to be treated as fully transparent).

Maybe that LV PNG translates any lower bit image into a 32 bit RGBA image, but I'm not sure about that. My tests with using the automatic transforms of the PNG library to turn everything into a 32 bit RGBA image did show some strange results with certain input images. So I simply read in any PNG image into the closest image depth that the LabVIEW picture control supports without trying to transform everything into RGBA.

I was also surprised that the LVPNG.DLL seems to be around 565 kB. My complete PNG library does not even take 140kB but a short look into the DLL seems to indicate that they distribute the DEBUG version of that DLL .

Rolf Kalbermatter