So that’s what we did. We are calling this the Coyote Graphics System. It pulls together programs from the Coyote Library, many of them renamed to better reflect their purpose, to create a complete graphics system that rivals any of the five new IDL graphics systems that have come and gone in the past 10 years, including the latest “new”graphics system, function graphics in IDL 8. But, unlike these new systems, this graphics system can actually be used and programmed by mortals to create new visual displays. Any data visualization you can imagine, you can create with the Coyote Graphics System.

There are two programs at the heart of the system. The cgColor program doesn’t care whether you are stuck in the past and will use indexed color until the day you die or whether you have moved on to the 21st century and want get your money’s worth out of that expensive 24-bit graphics card you bought for your computer, it always give you the color you ask for. And cgWindow is a resizeable graphics window that can be used almost exactly like you are currently using normal IDL graphics windows. These two programs can work with any traditional IDL command (e.g., Plot, Contour, Surface, TV, etc.), but the equivalent Coyote Graphics commands (e.g, cgPlot, cgContour, cgSurf, and cgImage) are designed specifically to work with these routines to produce device and color model independent programs.

What does this mean for you? It means you can write one program and have it work and look exactly the same on your display and in a PostScript file. It means you can stop apologizing about the poor quality of IDL graphics displays when you are presenting your results to your colleagues. And it means you can spend more time doing science and less time fooling around with recalcitrant graphics programs.

Wayne Landsman has already converted every plotting routine in the NASA IDL Astronomy Library to Coyote Graphics. Other astronomy libraries are doing the same. You can do this, too, with programs you have already written. My new book, Coyote’s Guide to Traditional IDL Graphics: Using Familiar Tools Creatively ($70 softcover limited time pre-publication price, $90 softcover, $60 PDF) explains the technique in detail. It is incredibly simple and Coyote Library routines have already been written to do most of the dirty work for you.

Here is what Ben Tupper, an IDL veteran and Mac user, had to say about the Coyote Graphics System when I introduced it to him:

I have just perused Chapter 12, “Using the Coyote Graphics System,” and I am thunderstruck (again!) by what a brilliant thing you have done for simple-to-use-right-out-of-the-box-but-wicked-powerful graphics. This is exactly what all of us need whether we are just cutting our teeth or we are getting long in the tooth. It’s freakin’ marvelous!

If you are tired of working with IDL graphics programs that look like they were written in the 1970s, I invite you to try something completely different. Here, for example, is how easy it is to create a filled contour plot in a resizeable graphics window.

   IDL> cgLoadCT, 4, /Brewer, /Reverse
   IDL> data = cgDemoData(2)
   IDL> cgContour, data, NLevels=12, /Fill, Position=[0.1,0.1,0.9,0.75], /Window
   IDL> cgContour, data, Color='Charcoal', NLevels=12, /Overplot, /Add
   IDL> cgColorbar, Divisions=12, Range=[Min(data), Max(data)], XMinor=0, $
           XTicklen=1.0, Charsize=1.25, /Add

And here is the result. I think if you try these commands, it just might change the way you write IDL graphics programs forever!

So, please give the new Coyote Graphics a whirl and let me know what you think in the comments!

SET_PLOT, 'PS',/Encapsulated
!P.FONT=0
DEVICE, FILENAME='figure.eps',/times
plot,findgen(10),xtitle='Msun'
DEVICE, /CLOSE

where Msun works as the tag that PSfrag will replace with the ⦿. The tag can be whatever you want, as long as it is a series of letters. [Update: As Michael Galloy points out below, PSfrag cannot replace substrings, i.e., the string being fed into PSfrag needs to be the entire XTITLE.] Then, create a basic LaTeX document (say, figure.tex):

\documentclass{article}
\usepackage{geometry, graphicx, psfrag}
\pagestyle{empty}
\geometry{paperwidth=12.1cm,paperheight=8.1cm,margin=0pt}
 
\begin{document}
 %%% Msun is the tag in the eps file to be replaced by M⦿
\psfrag{Msun}[c][][1.75]{Mass (M$_{\odot}$)}
\includegraphics[width=11.9cm,height=7.9cm]{figure.eps}
\end{document}

Then, compile LaTeX and convert the resultant PS file to EPS, if you so desire.

latex figure.tex
dvips -o fig.ps figure.dvi
ps2epsi fig.ps fig.epsi
### strip out the preview part from fig.epsi
perl -ne 'print unless /^%%BeginPreview/../^%%EndPreview/' < fig.epsi > fig.eps

Done! The Msun in the original figure.eps is replaced by a properly aligned, TeX-like M_⦿ in the new fig.eps!

A couple notes as I experiment more with PSfrag:

1) Note that PSfrag only replaces tags in EPS figures, allowing you to mix your LaTeX with your figures. In other words, you can create all of your figures with tags and add them in your manuscript. All the tags will be replaced when you TeX your document.

2) You can have local a \PSfrag that immediately precedes the \includegraphics in addition to a global PSfrags. The definition in the local environment will have precedence. Really nifty!

IDL> save, wavelength, flux, file='spectrum.sav'

you will now be able to open this file in Python using

>>> import idlsave
>>> s = idlsave.read('spectrum.sav')

after which you will be able to access the values using s.wavelength and s.flux.

The IDLSave homepage includes download and installation instructions. If you encounter problems reading in save files, don’t give up – please submit a bug report through the bug tracker, and I will look into it! One of the main limitations worth noting is that while it is possible to read save files into Python, it isn’t (currently) possible to write save files for reading back into IDL. It also is not possible to read special variables such as pointers or system variables from save files.

Enjoy!

Pros and Cons are addressed below in a comparative sense. Attributes that both share, e.g., that they are interpreted and relatively slow for very simple operations, are not listed.

Pros of IDL

• Mature many numerical and astronomical libraries available
• Wide astronomical user base
• Numerical aspect well integrated with language itself
• Many local users with deep experience
• Faster for small arrays
• Easier installation
• Good, unified documentation
• Standard GUI run/debug tool (IDLDE)
• Single widget system (no angst about which to choose or learn)
• SAVE/RESTORE capability
• Use of keyword arguments as flags more convenient

Cons of IDL

• Narrow applicability, not well suited to general programming
• Slower for large arrays
• Array functionality less powerful
• Table support poor
• Limited ability to extend using C or Fortran, such extensions hard to distribute and support
• Expensive, sometimes problem collaborating with others that don’t have or can’t afford licenses.
• Closed source (only RSI can fix bugs)
• Very awkward to integrate with IRAF tasks
• Memory management more awkward
• Single widget system (useless if working within another framework)
• Plotting:
  • Awkward support for symbols and math text
  • Many font systems, portability issues (v5.1 alleviates somewhat)
  • not as flexible or as extensible
  • plot windows not intrinsically interactive (e.g., pan & zoom)

Pros of Python

• Very general and powerful programming language, yet easy to learn. Strong, but optional, Object Oriented programming support
• Very large user and developer community, very extensive and broad library base
• Very extensible with C, C++, or Fortran, portable distribution mechanisms available
• Free; non-restrictive license; Open Source
• Becoming the standard scripting language for astronomy
• Easy to use with IRAF tasks
• Basis of STScI application efforts
• More general array capabilities
• Faster for large arrays, better support for memory mapping
• Many books and on-line documentation resources available (for the language and its libraries)
• Better support for table structures
• Plotting
  • framework (matplotlib) more extensible and general
  • Better font support and portability (only one way to do it too)
  • Usable within many windowing frameworks (GTK, Tk, WX, Qt…)
  • Standard plotting functionality independent of framework used
  • plots are embeddable within other GUIs
  • more powerful image handling (multiple simultaneous LUTS, optional resampling/rescaling, alpha blending, etc)
• Support for many widget systems
• Strong local influence over capabilities being developed for Python

Cons of Python

• More items to install separately
• Not as well accepted in astronomical community (but support clearly growing)
• Scientific libraries not as mature:
  • Documentation not as complete, not as unified
  • Not as deep in astronomical libraries and utilities
  • Not all IDL numerical library functions have corresponding functionality in Python
• Some numeric constructs not quite as consistent with language (or slightly less convenient than IDL)
• Array indexing convention “backwards”
• Small array performance slower
• No standard GUI run/debug tool
• Support for many widget systems (angst regarding which to choose)
• Current lack of function equivalent to SAVE/RESTORE in IDL
• matplotlib does not yet have equivalents for all IDL 2-D plotting capability (e.g., surface plots)
• Use of keyword arguments used as flags less convenient
• Plotting:
  • comparatively immature, still much development going on
  • missing some plot type (e.g., surface)
  • 3-d capability requires VTK (though matplotlib has some basic 3-d capability)

Specific cases where using Python provides strong advantages over IDL

• Your processing needs depend on running a few hard-to-replicate IRAF tasks, but you don’t want to do most of your data manipulation in IRAF, but would rather write your own IDL-style programs to do so (and soon other systems will be accessible from Python, e.g., MIDAS, ALMA, slang, etc)
• You have algorithms that cannot be efficiently coded in IDL. They likely won’t be efficiently coded in Python either, but you will find interfacing the needed C or Fortran code easier, more flexible, more portable, and distributable. (Question: how many distributed IDL libraries developed by 3rd parties include C or Fortran code?) Or you need to wrap existing C libraries (Python has many tools to make this easier to do).
• You do work on algorithms that may migrate into STSDAS packages. Using Python means that your work will be more easily adapted as a distributed and supported tool.
• You wish to integrate data processing with other significant non-numerical processing such as databases, web page generation, web services, text processing, process control, etc.
• You want to learn object-oriented programming and use it with your data analysis. (But you don’t need to learn object-oriented programming to do data analysis in Python.)
• You want to be able to use the same language you use for data analysis for most of your other scripting and programming tasks.
• Your boss makes you.
• You want to be a cool, with-it person.
• You are honked off at ITT Space Systems/RSI.

Obviously using a new language and libraries entails time spent learning. Despite what people say, it’s never that easy, especially if one has a lot of experience and code invested in an existing language. If you don’t have any strong motivations to switch, you should probably wait.

Reproduced with permission. Copyright 2007, Association of Universities for Research in Astronomy, Inc (AURA).

Update 28 Jan 2010: We’ve transferred this article to the wiki so that it can be updated as Python evolves.

BAD: 18 cm across and vector font

BETTER: 9 cm across and Postscript font

Make the figure close to the actual printed size

First thing, size matters. That old manuscript preparation document that said figures should fill a letter-sized page is misguided. No matter what type of font you use, if the text size looks right when the figure is 8 inches across, it will be too small when printed as a single column figure only 9 cm across. The BAD figure above is designed at 18 cm across while the BETTER one is 9 cm. Notice the difference in font size. (Charsize was not specified for either plot.) Design the figures to be tiny from the beginning and no further adjustments to the font size will be necessary for either publications or talks.

When these “small from the start” figures are blown up to fill a letter-sized page (i.e., in Latex preprint mode), the fonts might seem too large and look funny to your eye but, since it ensures that nobody will ever have trouble reading your axis labels, you should just get used to it.

aspect_ratio=1.5 ;rectangle
device, xsize=9, ysize=xsize/aspect_ratio

Use Postscript instead of Vector fonts

Inevitably, when a figure is illegible during a talk, a vector (Hershey) font was used instead of a Postscript font. For the purposes of 2D figures, the relevant difference is that vector fonts are thin and have a tendency to disappear while Postscript fonts are thick. The above BAD figure uses the default vector font while the BETTER one uses a Postscript font.

It’s so simple to switch from vector to device fonts! All you need is !p.font=0. While you’re at it, you might as well specify Helvetica for good measure even though, as far as I can tell, it’s the default Postscript typeface.

set_plot, 'ps'
!p.font=0
device, /helvetica ; a classic sans-serif font

Everything you ever wanted to know about fonts in IDL is in the Reference Guide.

Putting it together

aspect_ratio=1.5
xsize=9
ysize=xsize/aspect_ratio
set_plot, 'ps'
!p.font=0
device, filename='fig_better.eps', encapsulated=1, /helvetica
device, xsize=xsize, ysize=ysize
plot, a, b, xtitle='X Title', ytitle='Y Title'
device, /close
set_plot, 'x'
!p.font=-1

Know how to get nice legible fonts in other plotting programs? Share it in the comments.