[AstroPy] Summer scholar

[James Turner]

Yeah, the whole of ndimage needs rewriting (the code is also
somewhat impenetrable and doesn't have a proper maintainer). That's
a fairly daunting task and no-one has had time to do it so far. A lot
of us need that code, so sooner or later I think someone may have to
bite the bullet... I wish we had the time.

Cheers,

James.


Jonathan Slavin wrote:
> 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