From: John H. <jdh...@ac...> - 2004-03-27 21:45:06
|
I just updated the image module to work with Numeric or numarray (now that matplotlib is the recommended 2D plotting package on the numarray homepage!). Changes in CVS. The code uses the Numeric compatibility layer of numarray, but I am unsure how to best handle the decision of which one to build with. Whichever arrayobject.h you include (Numeric or numarray), the code works with either kind of array, so that is not the issue. But there will be those who want to build with numarray and vice-versa, so my question is how to best support this. Here is what I am currently doing in setup.py: # build the image support module - requires agg and Numeric or # numarray. You can build the image module with either Numeric or # numarray. Whichever way you build it, the code will work with # both Numeric or numarray arrays, but you will get the best # performance if you build with the type of array you use most #BUILD_IMAGE = 0 # no image support #BUILD_IMAGE = 'Numeric' # use Numeric BUILD_IMAGE = 'numarray' # use numarray and then setting a precompiler macro in setupext.py which determines which header is used. Another possibility is to look for a matplotlibrc file at build time and build according to the numerix setting. I think this is a nice solution but adds an extra later of complexity. The additional (and perhaps most important) question is how to handle the win32 build vis-a-vis Numeric/numarray? I ran some very rough profiling numbers. image_demo.py and image_demo_na.py are identical except the latter defines rcParams['numerix'] = 'numarray'. # build with Numeric hunter:> time python image_demo.py -dAgg 0.460u 0.070s 0:00.61 86.8% 0+0k 0+0io 5040pf+0w hunter:> time python image_demo_na.py -dAgg 2.550u 0.080s 0:02.79 94.2% 0+0k 0+0io 5211pf+0w # build with numarray hunter:> time python image_demo.py -dAgg 0.560u 0.140s 0:00.78 89.7% 0+0k 0+0io 5226pf+0w hunter:> time python image_demo_na.py -dAgg 0.540u 0.120s 0:00.72 91.6% 0+0k 0+0io 5197pf+0w The basic result is that numarray users pay a heavy performance price if the image module is built with Numeric, but if built with numarray both types of arrays perform comparably (and are performance competitive with the pure numeric case) Finally, if any of you stsci folks on the list have a nice color image of the heavens you could produce with imshow, that would make a stellar screenshot for the website :-) JDH |
From: Todd M. <jm...@st...> - 2004-03-29 14:35:39
|
On Sat, 2004-03-27 at 16:22, John Hunter wrote: > I just updated the image module to work with Numeric or numarray (now > that matplotlib is the recommended 2D plotting package on the numarray > homepage!). Changes in CVS. > > The code uses the Numeric compatibility layer of numarray, but I am > unsure how to best handle the decision of which one to build with. > Whichever arrayobject.h you include (Numeric or numarray), the code > works with either kind of array, so that is not the issue. But there > will be those who want to build with numarray and vice-versa, so my > question is how to best support this. > > Here is what I am currently doing in setup.py: > > # build the image support module - requires agg and Numeric or > # numarray. You can build the image module with either Numeric or > # numarray. Whichever way you build it, the code will work with > # both Numeric or numarray arrays, but you will get the best > # performance if you build with the type of array you use most > #BUILD_IMAGE = 0 # no image support > #BUILD_IMAGE = 'Numeric' # use Numeric > BUILD_IMAGE = 'numarray' # use numarray > > and then setting a precompiler macro in setupext.py which determines > which header is used. > > Another possibility is to look for a matplotlibrc file at build time > and build according to the numerix setting. I think this is a nice > solution but adds an extra later of complexity. > > The additional (and perhaps most important) question is how to handle > the win32 build vis-a-vis Numeric/numarray? > > I ran some very rough profiling numbers. image_demo.py and > image_demo_na.py are identical except the latter defines > rcParams['numerix'] = 'numarray'. > > # build with Numeric > hunter:> time python image_demo.py -dAgg > 0.460u 0.070s 0:00.61 86.8% 0+0k 0+0io 5040pf+0w > hunter:> time python image_demo_na.py -dAgg > 2.550u 0.080s 0:02.79 94.2% 0+0k 0+0io 5211pf+0w > > # build with numarray > hunter:> time python image_demo.py -dAgg > 0.560u 0.140s 0:00.78 89.7% 0+0k 0+0io 5226pf+0w > hunter:> time python image_demo_na.py -dAgg > 0.540u 0.120s 0:00.72 91.6% 0+0k 0+0io 5197pf+0w > > The basic result is that numarray users pay a heavy performance price > if the image module is built with Numeric, but if built with numarray > both types of arrays perform comparably (and are performance > competitive with the pure numeric case) I'll try to find out why there's a difference here. > > Finally, if any of you stsci folks on the list have a nice color image > of the heavens you could produce with imshow, that would make a > stellar screenshot for the website :-) Perry probably has ideas about more appropriate images for this application, but here is one of the coolest images I know of. (check it out even if you don't want a jpeg): http://imgsrc.hubblesite.org/hu/db/2004/07/images/m/formats/full_jpg.jpg I believe the deepest optical image ever taken, The Deepest. It's called the Hubble Ultra Deep Field (HUDF). Almost everything in the picture are galaxies. The picture itself represents a very small region of sky. Each little spec is billions of suns. Regards, Todd > > JDH > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Todd Miller <jm...@st...> |