LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Intensity graph: it's a matter of pixels

Hi all!

I would like to share with you what I have found experimenting with
Intensity graphs and picture controls.

First, why go through all this trouble:
I am displaying a grey-scale image in an intensity graph on the user panel.
The user has to select a
number of points to do measurements on. To select the points the cursors are
not very userfriendly
especially when you have a combination of zooming, panning and selecting it
is not very intu�tive.
Having to select different tools all the time also slows down the number of
measurements you can
do in an hour.
To get around this I came up with the following. Over my Intensity graph I
put a transparent picture control.
From this control I get mouse position and button status. Now I can zoom in
, zoom out
, pan and select a point . I
do this by relating the
relative position in the picture control to the X and Y axis of the
intensity graph. The added bonus of
this team up of the two controls is that I can use the picture control to
draw lines in the image without
disturbing the data (I use it as an overlay). The downside is that every
time something changes in the
picture control also the intensity graph has to be redrawn completely. This
makes moving the mouse
jerky even on a Pentium III 550 MHz (the cursor follows the mouse and is
drawn in the picture control,
I also tested moving the cursor of the graph but no speed difference, any
ideas anybody to speed this
up ?, I use images of 765x572 pixels).

To be able to do distance measurements it is very important that the picture
control overlays
the intensity graph nicely. It took quite some time experimenting to get it
right but I think I got it.
Thanx to a little tool called ZoomIn (part of MS VC++6 tools) I was able to
get down to pixel level
to examine what was happening.
If you hide the X and Y axis of the intensity graph and stretch the visible
area to the max you get the following:

The picture control bounds are the visual area + 6, 3 pixels of frame all
around. This is how I would
expect things to work. Now look at the construction work the guys at NI
delivered for the intensity graph.

The bounds of the graph are visual area + 7 (if stretched to the maximum).
For some odd reason there
is one pixel extra to the left and to the top (if it was to the bottom and
left it could have something to do
with the axis....). If the visual area is not max there is no way to find
out where it is within the bounds.
Having a label adds to the bounds (cannot be turned off programatically), a
cursor display can be hidden
if you create a seperate attribute for the cursor display I learned a week
ago from Greg (see question
from Melissa:Attribute node for cursor display) however the cursor control
remains which can not
be turned off and adds to the bounds. The Z-axis can be turned off using
attribute nodes.

Then the visual area itself. If you have a bitmap of say 400x400 you make
the visual area 400x400
and set the axis to 0 to 399 to show it undisturbed only to find that 2
pixels are lost somewhere in the middle.
This is because the visual area is not really the visual area because 1
pixel of framing to all sides is lost
(these pixels can be shown by making the foreground color of the visual area
red which does nothing for
the picture control), this is compensated by scaling the image to the REAL
visual area.

In conlusion to overlay a picture control over an intensity graph, assuming
there are no labels
or cursor displays sticking out to the left or top you have to add 2 pixels
to the left and top (3 pixels of
framing for the picture control, 4+1 pixels for the graph) for the position
and you have to make
the drawarea size of the picture control to the size of the bitmap and add 2
for the plot area size of
the intensity graph.

But then again this could all change in the next version of LabVIEW.

Does it really need to be so difficult?

Happy wireing,

RB.
0 Kudos
Message 1 of 4
(5,306 Views)
I can probably add a little info here. The intensity graph doesn't necessarily
need to display the image at one number for each pixel; so it needs to
be able
to display enlarged images. The intensity graph draws the (0,0) number between
the (0,0) and (1,1) scale positions. That means that to display an
image N
numbers wide, the scale needs to go from 0..N, but the pixel line that N is
on may not really be displaying anything.

Notice that I keep referring to numbers with the intensity graph. It was
developed not for displaying bitmaps, but to display grids of amplitudes
using color information. It was initially done for spectrogram
displays, but
it can be used for images.

Since you are using a picture control already, I'd encourage you to experiment
with using it exclusively. Draw the image into the picture control rather
than the intensity graph. You will not be able to zoom into it or
scroll it,
but you will be able to draw over it pretty efficiently, especially
since you
can set the picture control to not erase before updates. This means
that you
choose when to redraw the picture and erase the annotations, and when you
simply draw more symbols over the image.

Greg McKaskle


> To get around this I came up with the following. Over my Intensity graph I
> put a transparent picture control.
> From this control I get mouse position and button status. Now I can zoom in
> , zoom out
> , pan and select a point . I
> do this by relating the
> relative position in the picture control to the X and Y axis of the
> intensity graph. The added bonus of
> this team up of the two controls is that I can use the picture control to
> draw lines in the image without
> disturbing the data (I use it as an overlay). The downside is that every
> time something changes in the
> picture control also the intensity graph has to be redrawn completely. This
> makes moving the mouse
> jerky even on a Pentium III 550 MHz (the cursor follows the mouse and is
> drawn in the picture control,
> I also tested moving the cursor of the graph but no speed difference, any
> ideas anybody to speed this
> up ?, I use images of 765x572 pixels).
>
> To be able to do distance measurements it is very important that the picture
> control overlays
> the intensity graph nicely. It took quite some time experimenting to get it
> right but I think I got it.
> Thanx to a little tool called ZoomIn (part of MS VC++6 tools) I was able to
> get down to pixel level
> to examine what was happening.
> If you hide the X and Y axis of the intensity graph and stretch the visible
> area to the max you get the following:
>
> The picture control bounds are the visual area + 6, 3 pixels of frame all
> around. This is how I would
> expect things to work. Now look at the construction work the guys at NI
> delivered for the intensity graph.
>
> The bounds of the graph are visual area + 7 (if stretched to the maximum).
> For some odd reason there
> is one pixel extra to the left and to the top (if it was to the bottom and
> left it could have something to do
> with the axis....). If the visual area is not max there is no way to find
> out where it is within the bounds.
> Having a label adds to the bounds (cannot be turned off programatically), a
> cursor display can be hidden
> if you create a seperate attribute for the cursor display I learned a week
> ago from Greg (see question
> from Melissa:Attribute node for cursor display) however the cursor control
> remains which can not
> be turned off and adds to the bounds. The Z-axis can be turned off using
> attribute nodes.
>
> Then the visual area itself. If you have a bitmap of say 400x400 you make
> the visual area 400x400
> and set the axis to 0 to 399 to show it undisturbed only to find that 2
> pixels are lost somewhere in the middle.
> This is because the visual area is not really the visual area because 1
> pixel of framing to all sides is lost
> (these pixels can be shown by making the foreground color of the visual area
> red which does nothing for
> the picture control), this is compensated by scaling the image to the REAL
> visual area.
>
> In conlusion to overlay a picture control over an intensity graph, assuming
> there are no labels
> or cursor displays sticking out to the left or top you have to add 2 pixels
> to the left and top (3 pixels of
> framing for the picture control, 4+1 pixels for the graph) for the position
> and you have to make
> the drawarea size of the picture control to the size of the bitmap and add 2
> for the plot area size of
> the intensity graph.
>
> But then again this could all change in the next version of LabVIEW.
>
> Does it really need to be so difficult?
>
> Happy wireing,
>
> RB.
0 Kudos
Message 2 of 4
(5,306 Views)
Remco, I also found it a real bummer that the attribute nodes allow you to read only the overall bounds and set only the picture area bounds. It would be so much easier if they allowed you to read and write the same parameter!

But you can do it programmatically with a little preliminary arithmetic, subtracting tops and bottoms, lefts and rights together with the number you first thought of... Its fiddly but once you get the formula right you can resize things with gay abandon.

The attached spectra.vi is for multiple XY plots rather than intensity graphs, but the margin-setting principle ( sequence frame 2) is the same. You can trip it up by moving the left-hand edge (more work required on that!) but it does follow the bottom right corner OK, independant of
LV version.
0 Kudos
Message 3 of 4
(5,306 Views)
I have a question- is there any way to overlay on a waveform graph, while still controlling the curosr on the graph and displaying the picture simultaneously?
~Megan
0 Kudos
Message 4 of 4
(5,306 Views)