search

ioam / topographica

A general-purpose neural simulator focusing on topographic maps.
topographica.org
BSD 3-Clause "New" or "Revised" License
53 stars 32 forks source link

Matplotlib plot, animations and overall integration with the GUI #520

Closed jlstevens closed 10 years ago

jlstevens commented 11 years ago

Current state of plotting

Right now, Topographica's plotting is based on two packages, PIL and Matplotlib. Matplotlib was highly immature at the time of Topographica's initial development, and we took a hard line, saying that we couldn't add any dependency on Matplotlib into the core GUI code. Yet Matplotlib had various types of plots that we needed, which we ended up putting into topo.command.pylabplots, which isn't required for the GUI to function and isn't integrated with the main GUI, spawning separate windows that can't be controlled or used after creation.

Over the years, PIL has become poorly maintained, while Matplotlib has blossomed, with many plotting options, visualization types, etc. (including animation) that go far beyond what PIL can do. Thus now moving most plotting functionality from PIL to Matplotlib would make sense. But of course we don't want to start some huge, unbounded programming project, so we need to make sure that our goals are clearly articulated. We can then make a well-grounded choice about whether to go ahead with implementations that satisfy each goal. Even though we won't be likely to be able to achieve the fully imagined design any time soon, we can at least be moving in the right direction.

Goals

(Not necessarily all achievable, or at least not completely)

  1. Entirely replace PIL with Matplotlib in topo.plotting (PIL would still be required by imagen.FileImage, but that would be an isolated case that could easily be reimplemented using any image-loading package.)
  2. Add animation support, in some form (at least in IPython notebook) (already demonstrated, but needs to be integrated so that it doesn't become unmanageably complex and duplicative)
  3. Entirely replace hacky pylabplots.py code, integrating them into a shared interface used by both Tk GUI and IPython notebook (and integrating the Tk windows and the Matplotlib windows together), and allowing the code to be organized by content, not by whether it uses Matplotlib or not.

Achieving goal 1 enables 2 and 3, and is desirable in itself, but we may be able to make significant progress on 2 and 3 before achieving goal 1.

jlstevens commented 10 years ago

But of course we don't want to start some huge, unbounded programming project..

The huge, unbounded programming project is completed and is called 'DataViews'. Our solution is to deprecate the Tk GUI and use DataViews instead (which is based on matplotlib only)