To illustrate the NDF library calls, let’s change the code clip.f so that the IMG calls are replaced by NDF calls. Enter the following code and save it as clip2.f.
Code:
Interface file clip2.ifl:
and compile it using
noting the change in the library you’re linking your code to. Try running the application and compare its performance with the one that used the IMG library. You shouldn’t notice any difference.
Note that you can still access GIF, IRAF, ASCII etc. formats just as you could with the IMG library. All you have to remember is to start “Convert” first. The NDF library is more versatile in terms of available file formats than its name would suggest.
You’ll probably notice that a lot of the methodology behind the NDF library is similar to that which we used for the IMG library in part one. We still label NDFs. We still map them with pointers. One change you might have noticed is that when we mapped the NDF, we explicitly stated it was the ‘Data’ structure we wanted to map. As we’ll see later, we are not limited to this.
In the last example, an NDF was made by updating an old one. In this section, there are three examples of creating a new NDF. The third example is the most complete, so the reader who is in a hurry could skip the first two examples.
Code:
Interface file:
Running this code gives:
This rather ghastly error merely means that the file is empty. Using hdstrace to list the contents of the NDF gives:
Now let’s see how we can begin to put information into the NDF.
Code:
Interface file:
Again, on running this code, a warning is reported. However, hdstrace reports:
In this example, we put both a data array and variance array (we’ll mention these in more more detail in the next section) into the file. This is done purely by mapping them:
Interface file:
Obviously an additional subroutine is needed to put useful values into the arrays.