[AstroPy] Some Feedbacks about Astropy
Martin Beroiz
martinberoiz at gmail.com
Thu Jul 3 10:47:57 EDT 2014
Hello,
I also did my own registration code based on an approximate rotation + translation and source correspondence with a RANSAC
algorithm. It’s inspired in openCV’s algorithms for image registration and it works with stellar fields like the ones I use.
(openCV methods didn’t work out of the box for the images I needed)
But I would like to see something like astrometry.net does, identifying pentagons or other polygons in both images.
In fact I tried to do something like that myself and then I set that aside for lack of time.
Does anyone know if there’s anything like that implemented yet? I would like to see that included in astropy.
M.
On Jul 3, 2014, at 2:18 AM, Adam Ginsburg <adam.g.ginsburg at gmail.com> wrote:
> I agree with Tom's points, but I'd also like to clarify that the
> variety of replies were not all to the same question.
>
> The scipy.map_coordinates+astropy.wcs, pyAST, and montage utilities
> that I, Ray, and Sophie mentioned solve the problem of image
> regridding and reprojection, which as Tom points out belongs in
> astropy-core eventually.
>
> The montage approach uses a wrapper to an underlying C program called
> montage that needs to be installed independently. The scipy approach
> is more purely python, but it requires interpolation and is not flux
> conserving (montage is). The pyAST approach wraps another underlying
> C library and implements its own resampling that can be flux
> conserving depending on certain flags chosen (but Dave Berry, correct
> me if I've gotten something wrong here):
> http://dsberry.github.io/starlink/node1.html#Resample
> http://www.starlink.rl.ac.uk/docs/sun210.htx/node371.html
> These routines could probably live in something called
> astropy.reprojection or something similar.
>
>
>
> The second class of problems addressed is image registration, which I
> think is being treated in ccdproc, SRPAstro, and the methods that Ray
> mentioned. I think these are each niche codes with a different role;
> image registration based on star matching is very different from that
> based on FFTs and extended emission matching. For a summary of the
> codes available for extended emission registration, have a look at
> http://image-registration.readthedocs.org/en/latest/#programs-implementing-these-methods-in-various-languages.
>
> I hope this is useful clarification, but please correct me if I
> misrepresented anyone's code here.
>
> On Thu, Jul 3, 2014 at 8:10 AM, Thomas Robitaille
> <thomas.robitaille at gmail.com> wrote:
>> Paul Kuin wrote:
>>> Reading all this, I think that part of the success of the IDL Astro
>>> library is due to having one head, Wayne Landsman, put it all together.
>>> This reads like a conversation on the tower of Babel. Everyone their own
>>> method. Someone should take the time to check and compare all the
>>> different implementations. Some funding for such work would be very
>>> useful and save on duplication. I think this is a task that the IAU
>>> could(should?) be involved in.
>>
>> Reducing duplication is precisely the goal of the Astropy project - in
>> fact, we have a rule that 'affiliated' packages should not duplicate
>> functionality from the core, and also avoid duplication amongst one
>> another. See the original vision document:
>>
>> http://docs.astropy.org/en/stable/development/vision.html
>>
>> If you are interested in getting involved, you can join the astropy-dev
>> mailing list. As part of the Astropy project, there have already been a
>> number of successes in merging existing packages to provide a core
>> implementation (for example the cosmology routines).
>>
>> On the more specific topic of re-projection - this is clearly a highly
>> requested feature, and I think it should be targeted as something that
>> should have an implementation in the core astropy package that then gets
>> used by all other packages.
>>
>> As a side note, the fact there was more than one reply to the original
>> question is a testimony to the strength of the development community in
>> Python - people are clearly not just waiting for one person to just
>> write it all. Yes, we need to all make an effort to not duplicate things
>> needlessly, but on the other hand, having two different ways of
>> approaching the same problem is not always bad.
>>
>> Cheers,
>> Tom
>>
>>> Paul
>>>
>>>
>>> On Wed, Jul 2, 2014 at 6:15 AM, Guang Yang <yg1991 at mail.ustc.edu.cn
>>> <mailto:yg1991 at mail.ustc.edu.cn>> wrote:
>>>
>>> Thank all of you for giving those advices. I think I won't bother to
>>> switch between python and IDL in my next project. ^^
>>>
>>> Best wishes,
>>> Guang
>>>
>>>
>>> -----Original email-----
>>> *From:* "Sofia Lianou" <slianou at uwo.ca <mailto:slianou at uwo.ca>>
>>> *Sent Time:* Jul 2, 2014 5:14:53 AM
>>> *To:* "Astronomical Python mailing list" <astropy at scipy.org
>>> <mailto:astropy at scipy.org>>, "Adam Ginsburg"
>>> <adam.g.ginsburg at gmail.com <mailto:adam.g.ginsburg at gmail.com>>
>>> *Cc:* "Pauline Barmby" <pbarmby at uwo.ca <mailto:pbarmby at uwo.ca>>
>>>
>>> *Subject:* Re: [AstroPy] Some Feedbacks about Astropy
>>>
>>> Hello,
>>>
>>> This is something that imagecube is doing, too, and the package
>>> is hosted here:
>>> http://sophiathl.github.io/imagecube/
>>>
>>> Beta release to follow soon, along with proper documentation.
>>>
>>> Cheers,
>>> Sophia, Pauline, and Jeff
>>>
>>> On 07/01/14, *Adam Ginsburg * <adam.g.ginsburg at gmail.com
>>> <mailto:adam.g.ginsburg at gmail.com>> wrote:
>>>>> 1. I find no tools to align two images, i.e. to uniform
>>>> their astrometry, pixel scale, image size and etc.
>>>> hastrom.pro <http://hastrom.pro>
>>>> (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is
>>>> a good example to perform such a task.
>>>>
>>>> I've written a tool to do that:
>>>> https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py
>>>> ...I think it does what hastrom does, not hcongrid, which means I
>>>> should change the name.
>>>>
>>>> Otherwise, you can use the montage wrapper:
>>>> http://www.astropy.org/montage-wrapper/
>>>>
>>>>
>>>> --
>>>> Adam Ginsburg
>>>> Fellow, European Southern Observatory
>>>> http://www.adamgginsburg.com/
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>>> http://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>> http://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>
>>>
>>>
>>> --
>>>
>>> * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
>>> Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk <mailto:n.kuin at ucl.ac.uk>)
>>> phone +44-(0)1483 (prefix) -204927 (work)
>>> mobile +44(0)7806985366 skype ID: npkuin
>>> Mullard Space Science Laboratory – University College London –
>>> Holmbury St Mary – Dorking – Surrey RH5 6NT– U.K.
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> --
> Adam Ginsburg
> Fellow, European Southern Observatory
> http://www.adamgginsburg.com/
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140703/dfda3078/attachment.html>
More information about the AstroPy
mailing list