FAQ for fuview.pro and extract_imageinfo.pro

This page is for users of the above described software. This FAQ is now at version 0.24 (8-17-05)

1.0. What is this stuff?

Fuview is our workhorse viewer for IMAGE/FUV. It is based on browse software written by members of the POLAR team and is developed in a Solaris 8.0 environment. Harald Frey worked to convert the thing to read UDF data. It works pretty well. The guts of this code are in main_scr.pro, but it is generally called using fuview.pro. We recommend that, anyway.

I took fuview.pro from Harald and beat it up a bit. Extract_imageinfo is basically the same software but the widget interface is gone, replaced by a command line interface. This can make things much faster. It caches inventories on disk, so that you don't have to read whole files anymore just to get a list of times. Or, at least not more than once.

1.0.1 What do I need?

A. extract_imageinfo.tar.gz
That contains all the IDL software, including the current version of fuview (v6.0 as of April, 2004). Here is the current list of its contents . Included in the distribution is a changes.log file which tracks changes in the IDL software. Please note that I do not include our Solaris udf.so anymore. This will not work for you until you install the software listed in points A and B below! The changelog lists dates that the distribution has been upgraded. What used to concentrate on extract_imageinfo now will apply to both codebases.
B. UDF
This is the IMAGE filesystem. The IDL codes expect the data to be installed in particular places, and properly byteswapped for your machine architecture.
C. The LANL udf.so .
This is how on Earth IDL talks to the UDF database and extracts data from it. It REQUIRES at least IDL 5.3. Things do not currently work with Gurgiolo's UDFtoIDL DLM. The code (i.e. the Makefile) is not maintained along with UDF, however and there may be some tricks required to get things running.

If you are going to look at IMAGE FUV data, you are going to have to buckle up and install UDF. Or have your sysadmin to it. Or download CDFs from Goddard. In that case, you are on your own and responsible for your own software. I am not writing software for CDF, and neither is anyone else around here. That's that!

1.0.1.1 What else?

1.0.1.2. Why do I need this?

"It's the interface, stupid." - various authors.

The GUI interface for fuview is basic and useful. It allows for quick browsing of the data, export of data to a variety of formats, keogram creation (geographic and MLT now both work). The color scaling is not automatic right now, it always needs to be adjusted for WIC, for example. But this is *the* browse tool for IMAGE/FUV. It also now allows for dayglow subtraction and conversion directly to FUV brightness from counts using the latest calibrations from stars (which correspond well to the lab calibrations).

"...almost all programming can be viewed as an exercise in caching."  - Terje Mathisen, quoted by Michael Abrash, "Ramblings in Realtime"

Sometime you will come to a point where you want to process 100 images. Or 1000 images. And you do not want to have to reextract the data from the UDF files over and over again if you are continually changing your analysis or plotting package.

The extract_imageinfo program writes about anything you can think of for a particular UDF image to the harddrive (no housekeeping, though). It's all contained in a single structure, imageinfo, which the fuview.pro software uses and passes around. I just hacked into it to save SI and WIC in different size structures, add some interesting angles, and write it to the hard drive. Fuview now also saves the si and wic structures separately and saves the same exact structures to the hard drive if you like. So using one or the other is basically up to you. If you know you need 200 images now, extract_imageinfo may do it. If you want to browse 10 different days, fuview is definitely for you.

In recent months, Harald and I have worked our versions of the software together, and the result is that both extract_imageinfo and fuview work with all the same subroutines. Also, when fuview exports IDL structures, the structures are exactly the same as those you would get from extract_imageinfo! Furthermore, you can select filenames which exactly match the naming convention I chose for extract_imageinfo.

1.0.2. How do I install it?!
This is the installation documentation for the software. Yes, it is small! But this is only because it is very simple.

The package should be pretty well self contained. Pick the place you want it to go. I made a directory called ~/sci/fuv/fuview, where I have the system variable $FUV_HOME set to ~/sci/fuv. I copied the .tar.gz into fuview and extracted the whole thing. It is self contained and should run from there! For the pointing database and the default paths to the geographic and magnetic data files in fuview/support (set in fuview.cfg) to be found, you must also define $FUVIEW_HOME. For the above described installation, you would have to set that to ~/sci/fuv/fuview/ (and best to replace the ~ with your actual home directory path).

You will not need to edit the paths for the apex file and the ciamap in the file called fuview.cfg now, because fuv_init.pro can now handle the environment variables discussed in the previous paragraph. You will need to put the path to your $UDF_DATA tree in there. I know this is redundant under UDF, where this has to be defined anyway, but just do it!

If you want to have your very own custom config file, create a directory in your $HOME called ~/.fuview. In that directory you can place an fuview.cfg file, with your particular output directory, etc. It is not something I use, but may be useful to you. Don't forget that in updates of fuview, this file may change (it should now have 9 lines), and you will have to replace your old file with a new version which is installed in the root directory of the distribution.

1.0.3. It doesn't work!

Why not? Tell me what the problem is. It is possible that I left a file out of the distribution.  Or there are bugs. If you fix a bug or add a feature, please let me know! As I get reports from users, I will update the distro/source, or post fixes to common problems here.

>Solutions to Common Problems<

1: You may need to edit your fuview.cfg file so that the requested directories are correct for your particular system.

2: for the latest getudf_var to work, you need to have defined $FUVIEW_HOME and placed the contents of the attitude subdirectory of the distribution in $FUVIEW_HOME/attitude/. This happens normally when you un-tar the distribution.

3: "I get conflicts between different versions of the imageinfo structure!" I am trying to take care of that business now, before this code is distributed far and wide. The SI imageinfo structure is up to version 2. You can see this in fuv_init.pro as sidata_2. The si_image element that used to be a part of imagedata is now gone, so we should probably bump this up to imagedata_2. Doing this will relieve any of these structure conflicts. You can also restore IDL save files with the /relax keyword, and it will allow changes in the structure contents for a particular structure name.

4: "Dayglow subtraction does not work!". You need to download and install image_bckgnd_p.pro and all the associated codes and databases, including get_flatfield.pro. Go back to my homepage for pointers to these codes. This must be considered a plug-in to fuview, and will be updated/upgraded separately. UPDATE : The dayglow subtraction is now INCLUDED in fuview version 5.0.

5: "% Variable is undefined: AIRGLOW_SCALE (FUV_AIRGLOW)."  See 1. This is just the first of many crashes one would get if things are not properly initialized in $FUVIEW_HOME/fuview.cfg or ~/.fuview/fuview.cfg. For an installation used by a lot of people, it would help if the admin set the one in $FUVIEW_HOME up so that if a basic user has $UDF_HOME, $FUVIEW_HOME, and $FUV_HOME defined, it will all work nicely.

6: "fuv_read_udf is not defined!". The UDF DLM probably didn't get loaded. You need at least group read/execute permissions for the $UDF_HOME directory.

7: "the pointing is messed up!": You could probably use a new set of attitude files. These files can be downloaded using the get_angles.sh script that comes with recent distributions of the software. Once downloaded, however, you must move them into the $FUVIEW_HOME/attitude directory yourself.

8: "fuview cannot restore 'spin_axis_200*.idl'": One distribution was missing these files and this problem was fixed. Download the latest distribution!

9: "This thing does not work at all on my Windows machine!". None of this worked until very recently on Windows. Haje Korth at APL figured it all out and made some very useful changes to the code which opened up the software to Windows users. You will need v6.0 of the fuview code to take advantage of his changes, and the udf.dlm files that are available on his site. All Windows users owe Haje a beer.

1.0.4. I type main_scr and it just compiles a bunch of stuff!

If you are trying to run fuview, you should run fuview.pro from the idl prompt like this : IDL> @fuview. You can actually have fuview.pro anywhere, as long as you edit it and under the 'unix' section put the current path to the home directory of fuview. (the same as $FUVIEW_HOME).

1.0.4. I type extract_imageinfo and it just compiles a bunch of stuff!

To run this software, first type ".run extract_imageinfo.pro" at the IDL prompt (once you are in $FUVIEW_HOME). NOW you have to type main_scr. That is the driver procedure for extract_imageinfo that is in the file extract_imageinfo.pro.  Maybe we should change that, but it really is not a big deal.

1.1. How do I make an idl file?

There are a couple of ways.

A. Run fuview, and select more than one time from the listing on the right-hand side of the interface. Go to the file menu, select output, and the type of output.  Many types of files, including IDL files containing the imageinfo structure, can be dumped in that directory.

B. When browsing through images using extract_imageinfo, you can dump the current image with the D key (plus enter)

C: You can specify a whole range of records(times) from an opened UDF file using the E key, then entering the requested record numbers.

Below is a summary of the commands you can enter at the extract_imageinfo prompt. I don't think [P] works.



C : [C]hange output directory: /home/immel/sci/fuv/
S : [S]kip to particular UDF file.
J : [J]ump to record #X (current is  0).
I : show [I]mage for current record.
B : show [B]ackground-subtracted images instead
D : [D]ump current imageinfo to file.
E : [E]xtract a range of times from the current file to disk.
P : [P]rint numbered list of files for this time.
Q : [Q]uit this program.


1.1.1 Where did the file get written?

Exactly where you told it to go. :P The default place for fuview.pro is defined in fuview.cfg (which is in $FUVIEW_HOME or, if you have your own special config, in ~/.fuview/), and is with this distribution defined as $FUV_HOME/output. With the command line extract_imageinfo interface, if you don't like the output directory default, hardwire your own. The directory you define at the prompt or in the code MUST have a '/' after it. Yes, this is fixable. No I don't have a spare second to do it.

1.2 I accidentally deleted all my IDL files that I created. What do I do!?????!!?

If you were using extract_imageinfo, go look  though the logfile directory.  Paste the entire contents of one of those files on the extract_imageinfo prompt, and it will go through all the motions you did (except displaying the image [by typing "I"]) and re-extract the info. This works well, and will even consecutively open a number of different UDF files if that is what you asked the code to do.

1.3 The geographic disk does not overlay properly with the apparent position of Earth from the image.

It's not a secret that there were pointing problems from Day 0. In the first six months of operation, this caused the FUV instrument team to update the flight software, caused the IMAGE software people to update their analysis packages (i.e. the IDL UDF-DLM interface), and finally, caused the spacecraft team to correct their nadir calculation.  The result: There has been a huge improvement in the pointing! We are down to pointing errors which are due to noise in the spin rate induced by Earth's magnetic field. So early data may certainly have problems. You can correct the offset by hand, I do, we've all had to at some point. But images in late 2000 and onward are as good as we can get.

The pointing information for specific days is in the install directory under attitude. Please have a look at these. You can edit these files by hand (BUT NO TABS!!!) and use the stars and star-markers in fuview to line things up! Fuview.pro responds instantly to any changes in attitude files, so this process can be interactive and quick. The columns represent azimuth, co-elevation, and roll. The default values for any given day that is not shown in this file can be seen in get_inst_angles_p.pro which is included in the distribution. Editing these pointing information will almost surely be necessary during "Summer Vacation" times which Harald or I have not yet examined.

There is a particular problem with pointing that comes up every summer, it is tough to get around and we get it in the summers of 2001 and 2002 now. Basically, the spacecraft no longer reports the spin axis to us for several months (summer vacation).  In 2001, we have interpolated such that we get roughly the right axis vs. time, but 2002 is not done at this time, and the small variations (8-12 minute period) due to the slight nutation of the sc cannot be accounted for at these times.

1.4 I am having dificulty driving this fuview thing.

Maybe a few hints will help.
1) Whenever you are displaying a WIC image, you should immediately increase the top of the color table to at least 3000 (vs. the default 300). I usually got to 12000 or 18000.
2) When doing dayglow subtraction, it may be easier if you select the linear scale. And I do not recommend significant changes in the "power" of the dayglow for WIC.
3) You should generally not select "Open -> FUV UDF Set" from the File Menu, but rather UDF File (Individual). That is, unless you really really want to see images from all three channels at the same time.
4) This program will no longer run on a mac or a windoze machine, due mainly to the paths and filename conventions which have been added all over the place. Which is fine with us. Those are not research platforms! UNIX is!!! (OK, well now Macs are too :) If you want to make this software work under all platforms, we welcome your additions to the code.
5) Update on the above statement, Mac OS X should inherently have no problems running this code. The question is whether the UDF DLM will compile on that platform, and whether UDF will install properly. This is an experiment I hope to do before the end of 2002. (Note, with the 0.70 LANL UDF-DLM, and the latest version of UDF, fuview works nicely on Macs now!)