[AstroPy] Summer scholar

[Jonathan Slavin]

One thing that I'd like (don't know if a summer student could do it) is
to improve on the multidimensional filtering/smoothing in scipy. We had
some discussions about this a little while back.  Specifically the
ndimage.filters.uniform_filter and others in that module are implemented
in multiple dimensions via a series of 1-D filters in each dimension --
which is not the same as a truly multi-dimensional filter.  Maybe this
is not something there is much interest in, though anyone who wants to
remove some noise in a 2-D image might be interested.

Jon Slavin

On Tue, 2010-08-03 at 12:00 -0500, astropy-request at scipy.org wrote:

> Message: 1
> Date: Tue, 3 Aug 2010 00:04:37 -0400
> From: Rene Breton <superluminique at gmail.com>
> Subject: Re: [AstroPy] Summer scholar
> To: astropy at scipy.org
> Message-ID: <17371E6A-230E-4B3C-8977-115C0041E03B at gmail.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi everyone,
> 
> 
> Thanks for sharing your tips/library Stefano. Indeed a matching
> routine would be very nice to have so people should definitely aim to
> have something that makes use of several criteria such as distance and
> magnitude (in a more generic way). The Groth/Stetson algorithm seems
> very good but maybe yours is similar or can do better. Worse case,
> both can be put in under different names a little bit like the
> different root finding algorithms in scipy.optimize. You can never
> have enough algorithms to get around pathological problems.
> 
> Now, regarding Wolfgang's post, I very much agree with his ideas. I
> have to say that I've already implemented the "find" from "find.pro"
> in IDL's astrolib, which works really well in order to identify point
> sources. At the same time, I've modernized the program so that it
> takes advantage of numpy's array algebra, hence there are no slow "for
> loops". Maybe other algorithms could be worked out but this one
> certainly works well and it would be a shame to re-invent the wheel
> and have someone redo it. I think it should have been committed in the
> "pyastrolib" project that I was part of. If not, I'm very happy to add
> it here.
> 
> I'm also not very far from having a re-brewed "aper" function working,
> from "aper.pro" in IDL's astrolib but there are a couple of function
> dependencies that I haven't had try to code. So maybe the students
> could start from there in their coding.
> 
> Here are two ideas that I'd like to throw in for the student project,
> but they also apply in a more general way:
> 1. IDL's astrolib is a good start. The phot/daophot stuff from IDL's
> astrolib is generally pretty good, though it would gain to be
> modernized (and make use of array operations for instance). Since IDL
> and python are arguably similar, it would probably be not too
> difficult for someone with minimal experience to port some IDL code to
> python. Then one can optimize it.
> 2. Working on new photometry algorithms. Despite students may have
> limited programming background, they might be clever physicists. There
> are different algorithm using maximum entropy and such that can try to
> optimized the number of fitted sources. Among other interesting things
> would be algorithms/functions to derive photometric upper limits. This
> is what annoys me most and IDL's astrolib totally misses it. For PSF
> photometry, a routine that adds fake stars and tries to retrieve their
> flux in order to asses upper limits would be awesome. Something should
> also be done for aperture photometry.
> 
> 
> Cheers,
> 
> 
> Rene
-- 
______________________________________________________________
Jonathan D. Slavin              Harvard-Smithsonian CfA
jslavin at cfa.harvard.edu         60 Garden Street, MS 83
phone: (617) 496-7981           Cambridge, MA 02138-1516
 cell: (781) 363-0035           USA
______________________________________________________________