Image Acquisitionand Proces

4
Displaying Images
Although not always necessary, displaying acquired and processed images to the
user is often desirable. If your application calls for the user to be able to review
image data, it is wise to consider performance and user interface designs very
seriously. Your Þrst question should be, “does my application really call for image
data display?” Although we all like to “show off” our programming expertise, and
there is no better way than to show the users (read: managers) the before-and-after
data, displaying images can have much more detrimental effects to system performance
than traditional DAQ systems.
First, image data can often contain much more information than simple DAQ
data — a voltage trace with respect to time may be only an array of a few thousand
doubles, whereas a similar application acquiring images over time could easily Þll
up your RAM (e.g., a 1024 ¥ 768 32-bit image is approximately 3 Mb). Similarly,
image data generally contains more “background” data than tradition methods,
simply due to its two-dimensional nature.
Second, displaying any data on your front panel will take time and memory.
Using a multithreaded version of LabVIEW, whenever you wire data to an indicator
(numeric, string, Boolean, image, etc.) the execution thread is stopped, and the
system switches to the user interface (UI) thread. The UI thread’s copy of the
indicator’s data is then updated (this is generally called the operate data), and if the
panel is open, it is redrawn. Then the data is sent back down to the execution thread,
but in order to do this, it is Þrst sent to a protected area of memory called the transfer
buffer with a mutual exclusion object (MUTEX). After all of this is done, the systems
switches back to the execution thread, and when it next reads data from terminals,
it Þnds any new copies in the transfer buffer and uses these as the new values. As
you can imagine, copying image data between these layers can be quite time and
RAM consuming, especially if the dataset is large or inappropriately formatted.
You need to decide if you are willing to trade off system execution speed for
image display — if you do not really need to display an image on your front panel,
I suggest that you do not (perhaps create a modal sub-VI that the user can view only
when it is required). On the other hand, you may not be able to get away from telling
the user what is going on, but you will need to think carefully about the required
update rate and how you are going to transfer the data.
4.1 SIMPLE DISPLAY TECHNIQUES
If you are reading this book, then you probably have already installed the NI Vision
toolkit, and perhaps even played around with some of the example VIs that come
with it. Figure 4.1 is a simple example that you might recognize (it has been slightly
modiÞed from its original functionality). As you can see from the comment text in
65