Methods

Both the message soliciting feedback and excepts from the responses are available in Feedback Quotes.

Summary & Analysis

• 3D functionality
• Output formats
• Real time viewing
• Native backends
• Open Source
• Interactive plots
• 2D X-Y scatter/line plots
• 3D mesh plots
• subplot within a plot

Some users also requested features not on our list. Many of these fit well into the current design and have been incorporated into our product requirements:

• surface plots with hidden-line removal and shading: this actually was in our original plans, but we had not described it clearly.

• 3D height color coding: in a surface plot, one should be able to color each patch according to its Y value.

• image plot: a special drawing primitive that can efficiently map a two-dimensional color image onto a graph

• irregular mesh/surface/contour plots: two users requested the capability to make surface or contour plots out of data not sampled on a regular grid. We requested more information, and were given references which suggest that this functionality should be feasible.

• super/subscripts, and within-string font/format specifiers: any string used for labels, legends, etc. should be able to include formatting specifiers, such as font/style changes, super/subscripts, etc. in a character-by-character manner.

• asymetrical error bars: it was pointed out that for some types of graphs, the range (error) bars may be asymetrical (e.g., stock price).

• Tukey-style box plots: this is a special type of plotting symbol which incorporates a variety of descriptive statistics into each plotted point.

• anti-aliased GIF output: Graphite itself has no output functionality except through PIDDLE, which is a vector drawing system. PIDDLE currently has no renderer which produces anti-aliased GIF output. Such a renderer could be added to PIDDLE, and Graphite would immediately gain this functionality.

• handling of large datasets as integers (for memory efficiency): a MATLAB user pointed out that the plotting of large integer matrices is slower (and uses more memory) than necessary, because of the floating-point intermediate values. Because of the graphics transformations done by Graphite, we too must use floating-point intermediates. Options for more efficient handling of large integer datasets will be examined, but we are not optimistic.

• acceptable speed with large datasets: on a related note, concern was expressed about Graphite's plotting speed when large datasets were involved. We will make every effort to use efficient algorithms, but speed may be limited by Python itself.

• follow some of the precepts that Tufte lays out in "The Visual Display of Quantitative Information": we were pointed to this reference, and intend to look it up. But we expect that it will have more impact on the way Graphite is applied, than on the way it is designed.

• GTK back end (a PIDDLE issue): like the anti-aliased GIF output, one user's request for GTK output is something that must be addressed by extending PIDDLE.

• animation support: we are not planning any explicit support for animation within Graphite. However, we will provide an example or two of producing a series of graphs by varying parameters in a simple Python loop.

Several other items of interest were gleaned from the responses. Respondents noted previous use of MATLAB and Gnuplot. Specific suggested applications of Graphite included on-the-fly jpeg plots for web servers, and data visualization in an anaesthesia control system. Several users also commented on the similarity between Graphite and another package in development called Snow (by David Ascher). The chief difference is that Snow handles only two-dimensional plots.