Color generator

[ASTDan]

Hello,

I need an algorithim that can give me 32 different colors to plot in the waveform graph (Current graph only gives you 8 by default). I could set this up manualy but I was hoping for a more elegant solution.

Dan

[Neville D]

If you download the OpenG package from MooreGoodIdeas, there is a VI in there: MGI Non Repeating Plot Color.vi that selects reasonable colors for a white background plot when called.

Neville.

Edit: And since it took me ages to find it in the palletes when I first installed it, here is where its buried at:

Functions>7.x functions>MGI all VI's>Array>MGI Plots

[ASTDan]

Sooooo close.

That VI only is capable of generating 24 Colors. Then repeats.

I know 32 colors is a lot and is very had to distinguish, but that is what the customer wants.

Very cool vi's. Wow I didn't know there were other open reuse libraries besids open G.

Dan

[Neville D]

QUOTE (ASTDan @ Aug 21 2008, 11:15 AM)

Sooooo close.

That VI only is capable of generating 24 Colors. Then repeats.

I know 32 colors is a lot and is very had to distinguish, but that is what the customer wants.

Very cool vi's. Wow I didn't know there were other open reuse libraries besids open G.

Dan

Hmm.. maybe change pt style/line style to fit the remaining? Anything more than 5 plots is basically unreadable and a waste of time. Maybe try splitting them out to individual or stacked plots? Or else modify Dave's VI with an offset of some sort to get another set of 24 colors.

Off-topic, there's a lot of good stuff in there, and the "read anything write anything" VI's in this library are supposed to be a lot faster than the NI config read-write VI's. I haven't tried them.

Neville.

[Jim Kring]

QUOTE (ASTDan @ Aug 21 2008, 11:15 AM)

Sooooo close.

That VI only is capable of generating 24 Colors. Then repeats.

I know 32 colors is a lot and is very had to distinguish, but that is what the customer wants.

Very cool vi's. Wow I didn't know there were other open reuse libraries besids open G.

Dan

Yes, and hopefully there will be more coming, soon, now that http://forums.jkisoft.com/index.php?showtopic=853' rel='nofollow' target="_blank">it's so easy to build VI Packages.

Cheers,

-Jim

[ASTDan]

QUOTE (Jim Kring @ Aug 21 2008, 07:21 PM)

Yes, and hopefully there will be more coming, soon, now that http://forums.jkisoft.com/index.php?showtopic=853' rel='nofollow' target="_blank">it's so easy to build VI Packages.

Will there be, or is there a central place for these open reuse libraries? Is that open G? I think open reuse libraries are great, but is it a good idea to have many different and competing open reuse libraries?

Dan

[Neville D]

QUOTE (ASTDan @ Aug 22 2008, 05:54 AM)

Will there be, or is there a central place for these open reuse libraries? Is that open G? I think open reuse libraries are great, but is it a good idea to have many different and competing open reuse libraries?

Dan

I agree, it would be good if there was a way to link the location of different available OpenG packages. But whats the harm in having different (maybe competing) libraries? More the better.

Neville.

[ASTDan]

QUOTE (Neville D @ Aug 22 2008, 12:51 PM)

But whats the harm in having different (maybe competing) libraries? More the better.

The worry I have is redundancy of the reuse libraries. Also another issue is how do you manage a number of different reuse libraries i.e. versions etc.

On the positive competition promots inovation. However since it is free I gues we are just trying to out "cool" each other. :thumbup:

Also a central library could pose a problem due to who decides what goes into the library?

Things to ponder...

Dan

[Michael Aivaliotis]

QUOTE (ASTDan @ Aug 24 2008, 04:46 PM)

... Also another issue is how do you manage a number of different reuse libraries i.e. versions etc.

VIPM has solved this problem with the concept of project package configurations. Package configurations are like snapshots in time for the current project you are working on. They contain the package libraries that are used in your project for that LV version. When you need to work on that project you simply "apply" the package configuration and VIPM configures your environment with the exact set of package libraries you need to get your work done. So as long as you have a package configuration created, you can experiment with any library you want. You can always go back to the known working package configuration.

So, using the wrong library version for your project and risking broken code is a thing of the past.

[eaolson]

QUOTE (ASTDan @ Aug 21 2008, 11:27 AM)

I need an algorithim that can give me 32 different colors to plot in the waveform graph (Current graph only gives you 8 by default). I could set this up manualy but I was hoping for a more elegant solution.

It's been a while since this was originally, but what immediately comes to mind is taking the http://en.wikipedia.org/wiki/HSL_and_HSV' rel='nofollow' target="_blank">HSV color representation, picking N equally-spaced values for H, and keeping S and V at 100%. This should work for any N. Then convert to RGB for LabVIEW. They may not be the most aesthetically pleasing colors, but they would be guaranteed to be distinct. Is there an HSV-to-RGB converter out there for LabVIEW? If not, it should be pretty easy to create.

[torekp]

QUOTE (eaolson @ Aug 27 2008, 09:27 PM)

It's been a while since this was originally, but what immediately comes to mind is taking the HSV color representation, picking N equally-spaced values for H, and keeping S and V at 100%. This should work for any N. Then convert to RGB for LabVIEW. They may not be the most aesthetically pleasing colors, but they would be guaranteed to be distinct. Is there an HSV-to-RGB converter out there for LabVIEW? If not, it should be pretty easy to create.

ASK AND YE SHALL RECEIVE (Labview 8.5)

[Neville D]

Great! Thanks Paul.

N.