xfim has far fewer features than, say, Matlab's plotter. It is nothing more than a quick hack. However, it has the following benefits:

• Because I wrote the code, I can create precisely those features I want.
• I/O formats are what I want them to be.
• xfim starts up quickly.
• It is scriptable.
• I can compile and run xfim on any machine with a C compiler and X11.

xfim takes a real or complex matrix as input, mapping matrix values to grayscale values. Data files are single-precision floating-point binary, in network (big-endian) byte order. Conversion to/from ASCII should be done using a separate program.

Usage: xfim [options] {file num rows} {file num cols} {input file name}
Options:
  --help:  Print this message.
  -r:      Input is binary real.
  -lin:    Use linear remap
  -log:    Use log remap
  -quad {a}: Use quadratic remap with midpoint a, 0-1
  -mag:    Binary complex input, plotting magnitude
  -maglog: Binary complex input, plotting log of magnitude
  -phz:    Binary complex input, plotting phase
  -re:     binary complex input, plotting real part
  -im:     binary complex input, plotting imag. part
  -p {n}:  Pixels per sample.  E.g. -p 3 to magnify 3x
  -nc {n}: Specify # grey shades, e.g. for old video cards
  -min:    Manually specify remap min
  -max:    Manually specify remap min
  -ppm {f.ppm}: Write to f.ppm instead of X display

I have not modified xfim recently.

xfim handles X events very naively. In particular, it handles each resize event to completion, in sequence, even if several more resize events are pending. This makes for slow redraws, particuarly when communicating with an X server over a slow network. This effect worsens as the amount of data plotted increases.