PJM_labview

I think the misunderstanding might not be with us.

The method I described earlier works regardless how many transparent area there are in the image.

Below is another short video using a more complex (transparency wise) image.

PJM

Interesting Trick Norm!

Thanks for sharing.

PJM

QUOTE (Yair @ Dec 20 2008, 08:27 AM)

Philippe, as I mentioned in the other thread, my code which worked fine in 7.0 doesn't really work in 8.6 and sort of messes up the picture. I didn't look into this, so I don't know the details, but did you run into anything like that?

Nope. Still works fine for me (see below).

Note: Watch the little gradient block as I move it in the image.

PJM

QUOTE (asbo @ Dec 19 2008, 07:01 AM)

I've gotten this message too and the only way I can see this possible is that if a dependency of that VI somehow got unloaded from memory (which it shouldn't do while the parent VI is open, right?) and when you save, LV had to load that VI back into memory as part of dependency checking nonsense.

This was my initial though, but I don't see why doing a "save as>>copy>>create unopened disk copy" would do such a thing.

May be this has something to do with a VI in the clipboard...

PJM

QUOTE (Cool-LV @ Dec 18 2008, 04:24 PM)

Hi PJM,

Then, would you share that simple code for study ? thanks ?!~

I am sorry, but I can't share this code.

Here is more info that should help.

As other have mentioned, after reading a PNG file the image data cluster does has the alpha blending info in the image array as [ARGB] (Alpha Red Green Blue).

Once you got the image data of the pixels directly "behind" you new image, you could now recompute each new pixel color with:

ResultingColor = SourceColor × alpha / 255 + BackgroundColor × (255 - alpha) / 255

Note: You need to operate on color plane not on LV color.

I hope this help.

PJM

QUOTE (Ton @ Dec 16 2008, 11:04 PM)

Or you could build your own, the image data returned from a read png file contains the alpha blending info, if you really want to you could write your own alpha-blending routine.

You would need to get the image behind the picture control and do your calculation but that should be doable.

Ton

Ton, is correct.

I have code that I wrote a while ago that do just that and it works like a charm.

PJM

After doing a "save as>>copy>>create unopened disk copy" I got the following error messages. I am not entirely clear about the meaning of this message.

PJM

I can see this as being useful if you do not have a palette for all your wrapper members. If you do have a palette, LV give you very quick access to all the member of the same palette (see screenshot) and I do not see any advantage to wrap everything in a polymorphic VI (neither do I see any inconvenient to have a palette with a "lot" of items). Additionally, in my opinion, maintaining polymorphic VI is a pain (this is a cumbersome process).

So, I will add another con:

• Maintaining polymorphic VI is a pain.
  

They are good! :thumbup:

What you want to do is pre-load your images prior to really communicating with simulink (see screenshot).

Attached is the code that do this.

Download File:post-121-1228502405.zipLV 7.1

Enjoy

PJM

QUOTE (Cool-LV @ Dec 2 2008, 10:41 PM)

Hi, PJM, and how to enable the ini keys? add what? append to LabVIEW.ini file? help to tell, many thanks @!

http://forums.lavag.org/VI-Scripting-Readme-First-t1207.html

QUOTE (Darren @ Nov 21 2008, 11:02 AM)

... but it seems to me you might have linking issues (like VI search dialogs) when dropping a VI that normally resides in one location on disk from a completely different location...

Dynamically, create a new VI (in memory) where you can can use scripting to drop a VI from disk (using the New VI Object function you mentioned earlier). Now save this VI as the merge VI replacement and the drop will work fine (with no linking issue).

I typically use the true constant merge VI to do this.

PJM

QUOTE (Darren @ Nov 20 2008, 03:40 PM)

...The only way I can think of (and this is very kludgey) is to programmatically add the VI in question to the palettes with the Palette API (maybe to a dummy user.lib subpalette?), programmatically refresh the palettes, then use Drop Ctrl or Func (or Quick Drop) to put the newly-added palette VI on the cursor. The main problem with this method is the amount of time it takes to programmatically refresh the palettes.

There is a faster way. Just temporary replace and existing VI already in the palette by the VI you want to drop. Once the drop is complete, restore the original VI.

This works fine and it is fast enough.

PJM

Use a system Label.

PJM

QUOTE (Variant @ Oct 20 2008, 10:05 AM)

Is there any way to dynamically load images into picture ring control reading from file. I could not fin it

Thanks in advance

None that I know of.

Use a picture control if you want to have an arbitrary image displayed.

PJM

QUOTE (rolfk @ Oct 18 2008, 01:13 PM)

PS: Mesa aka. OpenGL is only used for the 3D controls and there mainly for the alpha shading but for the rest those controls are simply native LabVIEW widgets as all other controls too.

Rolf Kalbermatter

Ah, I knew that you would be the one that would have the answer to this one. This is good to know.

By the way, when I upgrade the mesa.dll to a newer version, every 3D controls/widget (even on toolbar) are no longer rendered.

Just though I would share this.

Thanks again Rolf for the info.

PJM

One think I will add that while the specifications (Software Requirement Specification) and the design description (Software Design Description) are usually different documents, the SDD is not a test plan.

Typically, while the SRS defines "what" the software must do, the SDD defines "how" the system will be designed to implement the SRS. The SDD is the document that the programmer(s) will need to write/implement the code. The SDD does not define any test methodology or test vectors. Other document(s) (such as a test plan for instance) are used for this.

Note (to the original poster): if you do some search on the web with SRS and SDD you will get some info about this.

PJM

QUOTE (d_nikolaos @ Oct 14 2008, 10:53 AM)

Can you tell me what is the function before the join numbers?

Decimate 1D array

PJM

2.37

I was below 2 but I screw up on one of the triangle center.

PJM

This should do it.

PJM

I believe LV use an antiquated version of the mesa.dll to render objects in the FP and BD. This dll is located under your resource folder (in here "C:\Program Files\National Instruments\LabVIEW 8.6\resource\mesa.dll" for a typical installation).

As far as I know this dll has been customized by NI (I might be wrong here) but there might be some functions available in there for getting emf images of objects.

Hmm there is a wglGetCurrentDC in there; may be this could get you somewhere.

Let us know how it goes.

PJM

PS: You might want to update your profile to indicate that you are using LV 8.6

QUOTE (JFM @ Sep 26 2008, 09:06 AM)

* You'll have to install a few software packages, at least if you need the CLI support as well as the support from TSVN

If by CLI you mean Command Line Interface, then do you know that you can automate TSVN by passing command to tortoiseproc.exe?

See http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-automation.html' rel='nofollow' target="_blank">here for more info.

PJM

QUOTE (JFM @ Sep 24 2008, 10:36 AM)

I added a "always copy" primitive right after the Get Image property node, and this also solved the issue.

/J

Good point. I never had a use case for that little guy ("always copy" primitive). I guess this does qualify as a use case

PJM

QUOTE (JFM @ Sep 22 2008, 01:56 AM)

...Does anyone know if this is possible, or do I have to create bmp's of all built in symbols from Screenshots?

What don't you do it programatically, this is pretty easy.

Note: While writing a quick example for you I found a LV bug, so look at this http://forums.lavag.org/Buffer-reuse-gone-wrong-t12015.html' target="_blank">thread for the VI. This should be good enough (bug or no bug) for your use case.

PJM

This bug is a little tricky to explain.

First download the attached VI.

Download File:post-121-1222274788.vi

Now Open its BD and from there open the FP of "Get Image Subset.vi" and put each FP side by side.

Step 1

Run the VI with the "White is transparent" flag set to FALSE.

Here is the result:

So far so Good (note: I highlight the structure where problem will show next)

Step 2

Run the VI with the "White is transparent" flag set to TRUE.

Here is the result:

Somehow the buffer of the cluster is being reused and some data that should not be there are present.

Note: at that stage there are no visible effect of this bug on the "Get Tree Symbols (LV86).vi".

Step 3

Run the VI with the "White is transparent" flag set to FALSE.

Here is the result:

Now we can see the effect of the bug on the "Get Tree Symbols (LV86).vi".

From that point on there are no non edit way to have this vi work properly. Setting the "White is transparent" flag to false always return an array of blank image symbols.

Disconnecting the image data wire (at any place) and reconnecting it does temporary fix the bug until going back to the 3 steps. forcing LV to not reuse the buffer by creating another wire branch (see image below) is the only workaround that I have found.

PJM

PS: This bug is also present in LV 8.5 (I have not tried earlier version)