how is graph data resampled to pixels?

[BradNC]

As a test, I set up two identical graphs with plot areas 500 pixels wide, and a noisy sine wave of 1000 samples.  One graph displayed the straight waveform, while another got the results of using the Decimate Arrray function to halve the number of samples.  They are not the same.

So what exactly is a waveform graph doing when it dispalys a data set larger than its pixel width?

[GerdW]

Hi bcro,

you have a sine wave with 1000 samples and one with just 500 samples. And now you wonder why they look different in a graph?

What is the graph doing? It displays your data. Atleast it tries to fit all the data onto the graph area (like fitting 1000 samples to just 500 pixels). And then it draws lines between the points. And additionally it may apply antialiasing to the lines. Hmm, yes the result may change when feeding different waveforms...

[Alex.T]

Hi bcro,

Just to add to what GerdW mentioned, LabVIEW is essentially doing some guesswork between the points of data that you specify. Fundamentally, what you're seeing represents the benefits of having more samples; we derive a clearer interpretation of the sampled waveform. In terms of the Graph output, a Waveform Graph is built to display the set of data it receives and not constantly append new points like that in a Waveform Chart. This is the reason why we generally write to Waveform Charts within looped sections of code and Waveform Graphs outside of them.

[BradNC]

Perhaps I have poorly stated my question.  I am assuming (perhaps incorrectly), that if a graph with only 500 horizontal pixel rows needs to display data of 1000 samples, it must (behind the scenes) reduce the data to 500 samples...1 per pixel row.  My test in the first post was just an attempt to rule in or out the simplest case where the graph simply decimates the array...appearantly other things are going on.

My question is, what exactly does the code for a LV graph do to a data set in order to map it to a limited number of pixels?

[BradNC]

Alex--

Sorry, I was posting my last when you posted your message.  Thanks for the information.  I'm trying to think through the most effective way to reduce data sets before sending them across the network to a host PC for display on graphs.  How the graph code handles the data is obviously a part of the equation there.

Am I right in understanding from your reply that a Chart will update more efficiently than a Graph, at the cost of getting no interpolation of the data?

And maybe on a more obscure note, is there an efficiency gain with a Graph if it is given a data set of size equal to the number of Horiz. Pixels (thereby requiring no interpolation)?

Thanks again Alex, and have a great day.

[Ben]

I think Dr Grey wrote a KB article that included methods to display large data sets.

This looks like the right title but I don't see the display section.

From what I remember...

LV looks at the max and min of a sub-set of the points to help with the display so that we don't loose data (as you observed in your original Q).

I think the title had the text "large data".

The right article talks about how to handle the decimation.

BTW: This topic used to be hot but with faster CPU's the need to help out the graphs and charts has diminished.

Am I safe in assuming you are having performance issues?

Ben

[Darin.K · Accepted solution]

As you have noticed, the graph is a bit more clever than you expected.  When the number of points exceeds the number of pixels, some form of resampling must take place.  A simple decimation like you tried would potentially drop some interesting points.  Instead, outliers are given priority when selecting which points to display.  This way, sharp peaks and dips are displayed even on a large scale.  Reproducing this behavior on your own can be tricky.  And once you reduce the data set, the points are gone and zooming is not as effective.

I usually try to let the graph do as much as possible.  One simple and effective way to reduce the size of data you have to ship over the network is to use SGL precision instead of DBL precision.

[Ben]

---

@Darin.K wrote:

As you have noticed, the graph is a bit more clever than you expected.  When the number of points exceeds the number of pixels, some form of resampling must take place.  A simple decimation like you tried would potentially drop some interesting points.  Instead, outliers are given priority when selecting which points to display.  This way, sharp peaks and dips are displayed even on a large scale.  Reproducing this behavior on your own can be tricky.  And once you reduce the data set, the points are gone and zooming is not as effective.

I usually try to let the graph do as much as possible.  One simple and effective way to reduce the size of data you have to ship over the network is to use SGL precision instead of DBL precision.

---

Megga-Dittos!

And if the native graph/chart is having trouble...

Check the plot styles...

Reduce the frequency of updates...

Shut-off auto-sclae....

Defer FPupdate before and undefer after the update.

Ben