What are some known problems with the AFNI package?
Document Actions
Q53. What are some known problems with the AFNI package?
Alas, no nontrivial program is without bugs or other flaws. The ones that I know about are listed below.
- Plugins: The plugin startup code searches all the
directories given in the environment variable
AFNI_PLUGINPATH for plugin libraries. If this environment
variable is not set, then the PATH variable will be used
instead. The use of PATH has caused problems at 2 sites,
for reasons unknown. Therefore, it is best to set
AFNI_PLUGINPATH directly before starting the afni program.
In the C shell:
setenv AFNI_PLUGINPATH /plugin/directory
In the Bourne or Korn shellsAFNI_PLUGINPATH=/plugin/directory ; export AFNI_PLUGINPATH
Logically, these go best in your startup files (e.g., .cshrc, .profile, etc.). You can also set environment variables in your .afnirc file; for details, see README.environment.Note that the Makefiles and binary distributions install the plugins in the same directory as the other AFNI binaries. If you wish to avoid trying to load plugins altogther, the switch -noplugins can be used on the afni command line. You may also set the environment variable AFNI_NOPLUGINS; this too will prevent the plugin startup code from being executed.
Local Plugins: If you develop your own plugins (see /pub/dist/doc/afni_plugins.ps), you must be sure to compile them with the same Makefile that was used to compile the AFNI package. Otherwise they may not be loaded correctly. This problem has arisen with our SGI systems, which have several different binary execution modes (selected by compile-time options to cc), which are not compatible with each other (e.g., a -n32 module can't be mixed with a -64 module).
Plugin Date Checking: When new versions of the package are released, I don't guarantee binary compatibility with older plugins. One reason is the need to add new data structures to the AFNI internals. The result is that all plugins and command line programs need to be recompiled with each release of AFNI. To remind you of this (if you are developing your own plugins), the plugin startup code checks the plugin compilation date vs. the AFNI compilation date - if the plugin is compiled before afni itself, a warning message will be displayed.
- FIM+ and 3dfim: As mentioned in Q35 and Q41, the internal FIM+ and batch program 3dfim don't calculate exactly the same % Change. They also don't prune the low-intensity voxels from the calculation in exactly the same fashion. There are probably other differences, as well, which are ultimately due to the different histories of these two codes.
- Byte Ordering: As discussed in Q18, AFNI now keeps a flag in each dataset header file noting the byte order of the information in the bricks. However, older (pre-May 1998) files won't have this flag. When transported between computer systems, such datasets will behave peculiarly. The solution is to properly mark old datasets with their byte order. The method for doing this is described in AFNI Necronomicon (README.environment).
- Illegal Float BRIKs: It is possible to write a set of
bits to a floating point file that does not represent a legal
number (this cannot happen with an integer-valued file). Floating
point bricks are assumed to contain legal numbers, and AFNI
programs will likely fail badly (e.g., go into an infinite loop) if
this assumption is violated.
There are two ways to avoid this problem:
(1) Use program float_scan. It can read a floating point file, patch (set to zero) illegal values, and write them back to the disk file.
(2) The environment variable AFNI_FLOATSCAN, if set, will check and patch input float .BRIK data when they are read into memory. Of course, this takes extra CPU time. It may also take extra memory or swap space, since patched data cannot be loaded by mmap(), but must be read directly into malloc()-ed RAM. - SunOS 4.1.x: This ancient operating system (used mostly for hunting mastodons) is no longer supported, since I don't have easy access to one of these beasts any more. (Nor do I want to have such access - don't offer!)
- Solaris 2.5: /usr/dt/lib is not included in the
default search path when a program starts. To force this directory
to be searched for libraries at program runtime, you must set the
environment variable LD_LIBRARY_PATH properly. Using the C
shell:
setenv LD_LIBRARY_PATH /usr/lib:/usr/dt/lib:/usr/openwin/lib:/usr/ucblib
Using the Bourne or Korn shells:LD_LIBRARY_PATH=/usr/lib:/usr/dt/lib:/usr/openwin/lib:/usr/ucblib export LD_LIBRARY_PATH
Again, these should go in your startup files (e.g., .cshrc) so that they are executed whenever you login.You will need to install all the Solaris 2.5 X11 and Motif patches to get AFNI to work without crashing.
- Solaris 2.x (for x > 5): See the latter part of the
answer to Q29. Also, I have heard
that the Rescan function in AFNI works very slowly
under Solaris. Why, I don't know.
I have no experience with Sun's latest release of Solaris (Solaris 7? 8?), so you are on your own there. Good hunting.
[26 May 2000] The only Solaris machine I have access to has been upgraded to Solaris 2.8, so that is what the Solaris binaries are compiled for from now on.
[07 Nov 2001] AFNI precompiled binaries for Solaris 2.x are now available here, for x=6 and x=8. There are still a few minor user interface glitches that surface on Solaris, but these are cosmetic blemishes.
[22 Jul 2002] The Solaris 2.6 machine I used was upgraded to 2.8 recently, so Solaris 2.6 binaries and support will no longer be available.
- HP-UX: Under HP-VUE (or CDE), and when using an 8 bit
PseudoColor X11 visual, you'll find that the window manager hogs
all the colors to make the window decorations look nice. You have
to reclaim some of these colors before AFNI will work. To do
this, you click on the VUE control panel icon that is like a
painter's palette. Under that application, choose Color
(or something like that), and under that menu, choose Color
Usage (or something like that). Then pick Medium or
Low, instead of Default. (It may also be labeled
Most Colors for Applications.) After that is done, you'll
have to confirm it, and then logout and login to have this change
take effect.
On HP-UX systems, another problem is that HP seems to ship the Unix kernel configured so that each running program can only access 64 MB of RAM, no matter how much memory the system actually has. To fix this, the super-duper-user (root) has to use the SAM program (part of HP-UX) to adjust the kernel parameters, and then rebuild the operating system. You will probably want to have this done.
- CDE: The above remarks about color usage also apply to
the Common Desktop Environment DeskTop (CDE DT), which is in fact
adapted from HP-VUE.
Another "feature" of CDE is that dropdown menus (as in the AFNI Lock and Misc menus) don't stay posted when the mouse button is released. This makes it difficult to click on a menu item such as a Toggle Button. I don't know how to make the menus stay up, but a workaround is to popup the menus with the right mouse button (Button 3) and, while holding Button 3 down, use Button 1 to activate the Toggle Button. This method requires a little practice, but developing these motor skills will provide a good neural workout for your next scanning session.
- SGI IRIX: Text entry fields don't show a vertical
(I-beam) cursor, unlike other platforms. Apparently this is a bug
(feature?) with SGI's Motif library. I have been unable to find a
way around this problem. I don't know why software from SGI itself
doesn't have this problem.
The volume rendering plugin does not work properly at the higher optimization modes of the Volpack library. I don't know why this is, nor do I know how to fix the problem. My only suggestion is to switch to a Linux box. Rendering is pretty nice on a 1 GHz Athlon system with 1 GB of RAM!
- Linux/Intel: You will have to byte swap short (16-bit)
images from most other workstation platforms. The program
2swap can do this for 2D and 3D data. Also, the
3Ds: input format can do this as the images are read in -
see the output of to3d -help and Q12 for more information about how to swap
bytes on input to to3d. The program 4swap can be used
to quad-swap 32-bit image files; for example, files in IEEE
floating point format. You can also swap the bytes from the
interactive control panel in to3d, using the cleverly
labeled Byte Swap button.
AFNI itself now stores the byte order of datasets in the header files, and will swap bytes appropriately on input. This means that you don't have to swap the bytes in .BRIK files when you move them between systems. If you do want to swap the bytes (for efficiency), then run 2swap or 4swap (for short and float files, respectively) on the .BRIK files, and use program 3drefit to alter the byte order flag in the .HEAD files. See README.environment for a few more details.
If you wish to force all newly created AFNI datasets to be stored in a particular byte order, you can do so using the environment variable AFNI_BYTEORDER. This may ease the problem of inter-system dataset transport. (But you will have to make sure that this variable is set on all systems/accounts which use AFNI.)
Some desktop/window managers under Linux (e.g., KDE) don't respect the request that AFNI makes to keep the aspect ratio - width/height fraction - of the image windows constant. This makes it hard to properly resize an image. You can make AFNI enforce the aspect ratio constraint itself by setting the Unix environment variable AFNI_ENFORCE_ASPECT; details can be found in README.environment.
Most pre-installed Linux systems now seem to ship with a 16-bit or 24-bit TrueColor X11 visual set as the default. AFNI will work with this imaging mode, but the older program FD2 will not (nor do I plan to make any changes to FD2 in the future - it is a pile of spaghetti code from multiple authors). As a lenitive (look it up!), AFNI has been modified to allow you to input image time series and look at their graphs as well as their images. This is the new [20 Oct 1999] -tim option - see the output of afni -help for usage details.
[16 Oct 2001]: FD2 now works with TrueColor, thanks to Andrzej Jesmanowicz of MCW. - IBM RS/6000: Plugins don't work, or so I was informed by
the guy who gave me the Makefile for this type of system. Not
having one meself, I have no real comment.
[Answer last changed 24 Nov 1999]
This FAQ applies to: Any version.
