This is primarily a bug-fix release from 0.65, though a couple of little features managed to sneak in - 4x image speedups for large images - figimage bug fixed - fixed some bugs which caused the colorbar not to update properly when changing colormap interactively - refactored axes management to support delaxes, which deletes, as opposed to clears, a specified axes. Default to current axes - tkagg's classic and new-fangled toolbars are now embeddable. - extended the new set/get introspection features to more classes - fixed some tkagg flakiness on win32 regarding unusual uses of show. - new cross backend animation idiom in examples/anim.py - use interactive mode rather than timers/idle handlers. - deferred some initializations in dates and colors modules for faster load times. http://sourceforge.net/projects/matplotlib Enjoy! JDH
On Wed, 2004年12月22日 at 17:30 -0600, John Hunter wrote: > - 4x image speedups for large images This is a biggie!! Ladies and gentlemen, my impression is that imshow is now at least as fast as, and perhaps faster than, DS9 for astronomical image display. (I'm looking at 1024 square full disk solar images.) Nice job, John. Happy happy to all, Steve
Stephen Walton wrote: >On Wed, 2004年12月22日 at 17:30 -0600, John Hunter wrote: > > > >> - 4x image speedups for large images >> >> > >This is a biggie!! Ladies and gentlemen, my impression is that imshow >is now at least as fast as, and perhaps faster than, DS9 for >astronomical image display. (I'm looking at 1024 square full disk solar >images.) Nice job, John. > > I therefore propose that we start developing a Python version of DS9. The benefits of a Python version based on matplotlib are TrueType fonts (with arbitrary text rotation), alpha blending, and direct support for numarray. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
On Fri, 2004年12月24日 at 09:21 -0500, Paul Barrett wrote: > I therefore propose that we start developing a Python version of DS9. > The benefits of a Python version based on matplotlib are TrueType fonts > (with arbitrary text rotation), alpha blending, and direct support for > numarray. Sounds like an interesting project. The first item I'd have on a list of desired features is, surprise, the ability to load multiple aligned images and blink between them.
Stephen> Sounds like an interesting project. The first item I'd
Stephen> have on a list of desired features is, surprise, the
Stephen> ability to load multiple aligned images and blink between
Stephen> them.
With the new keypress event handling in matplotlib-0.70, and the
cleanup to make sure the visible property is respected, this is pretty
easy. The example below is more complicated than you need for the
usual case, since it handles images of different pixel dimensions that
occupy the same physical dimensions, but it gives you the idea (btw,
this is now examples/toggle_images.py, which contains a bit more
information in the header)
What's the second item on the list :-)
JDH
from pylab import *
# two images x1 is initially visible, x2 is not
x1 = rand(100, 100)
x2 = rand(150, 175)
# arbitrary extent - both images must have same extent if you want
# them to be resampled into the same axes space
extent = (0,1,0,1)
im1 = imshow(x1, extent=extent)
im2 = imshow(x2, extent=extent, hold=True)
im2.set_visible(False)
def toggle_images(event):
'toggle the visible state of the two images'
if event.key != 't': return
b1 = im1.get_visible()
b2 = im2.get_visible()
im1.set_visible(not b1)
im2.set_visible(not b2)
draw()
connect('key_press_event', toggle_images)
#savefig('toggle_images')
show()
John Hunter wrote: > Stephen> [...] ability to load multiple aligned images and blink between > Stephen> them. > >With the new keypress event handling in matplotlib-0.70, and the >cleanup to make sure the visible property is respected, this is pretty >easy. > > You're right, thanks for the example code! >What's the second item on the list :-) > > Well, since you asked, and Todd originally mentioned a DS9 replacement: second would be a windowed, scrollable view into an image which is larger than the physical display. I have 2K square cameras at my observatory, and HST ACS images are 4K square; both are quite a bit larger than any display I'm likely to be able to afford in the forseeable future. Third item, and this will be a lot harder, is display and readout of FITS WCS information on the screen. Acronym glossary: HST--Hubble Space Telescope ACS--Advanced Camera for Surveys FITS--Flexible Image Transport System, the default format for astronomical images (http://fits.gsfc.nasa.gov) WCS--World Coordinate System, a standard for embedding information for mapping pixel to physical coordinates in the FITS image header
Stephen Walton wrote: > second would be a windowed, scrollable view into an image which is > larger than the physical display. Actually, imshow seems almost to do this. I did imshow(imdata,interpolation='nearest') where imdata was a 1024 square image. Zooming and panning _seems_ to show the full resolution image with individual pixels visible at high zooms. Is this right?
On Jan 3, 2005, at 7:36 PM, Stephen Walton wrote: > Stephen Walton wrote: > >> second would be a windowed, scrollable view into an image which is >> larger than the physical display. > > Actually, imshow seems almost to do this. I did > > imshow(imdata,interpolation='nearest') > > where imdata was a 1024 square image. Zooming and panning _seems_ to > show the full resolution image with individual pixels visible at high > zooms. Is this right? > Since John is away, if I interpret your question correctly, yes. Both implot and figimage save a reference to the original image so that when redisplayed, it is possible to do things like that (like expanding the size of a figimage window will show all pixels previously falling outside the bounds). Your previous request regarding adding scrollable plot regions raises an interesting issue. I think this is tricky (John may prove me wrong on this). It was this sort of functionality that made chaco comparatively complex so I'm hesitant about adding it. Effectively one now one would be wandering into the area of having the plotting package begin to emulate widgets within its canvas (e.g., the scroll bars). This doesn't mean that one couldn't write a gui application that had scroll bars that responded to scroll events by redisplaying the image (and plot) according to their position. But then it becomes gui dependent. Paul Barrett's suggestion to do a DS9 clone would likely take this approach I think. As you noticed, the general toolbar gives some of this functionality, but I don't know if will satisfy all such needs that something like DS9 does. Perry