From ppmime at gmail.com Tue Mar 6 06:00:20 2012 From: ppmime at gmail.com (=?ISO-8859-1?Q?Jose_Miguel_Ib=E1=F1ez?=) Date: Tue, 6 Mar 2012 12:00:20 +0100 Subject: [AstroPy] Image combine Message-ID: Hello everyone, does anyone know of an implementation of the iraf.imcombine task in python+numpy ? (of course, not using pyraf.imcombine call) Thanks ! Jose From erik.tollerud at gmail.com Tue Mar 6 13:52:02 2012 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Tue, 6 Mar 2012 10:52:02 -0800 Subject: [AstroPy] Image combine In-Reply-To: References: Message-ID: I'm not aware of a function that does it exactly with the interface of imcombine, but it can be done pretty easily with pyfits: import pyfits f1 = pyfits.open('filename1') f2 = pyfits.open('filename2') h1 = f1[0].header im1 = f1[0].data im2 = f2[0].data newimage = im1 + im2 newhdu = pyfits.PrimaryHDU(data=newimage,header=h1) newhdu.writeto('newfilename') That example is specific to addition, of course (the im1 + im2 part, but it should be clear how to generalize it to other arithmetic operations. 2012/3/6 Jose Miguel Ib??ez : > Hello everyone, > > does anyone know of an implementation of the iraf.imcombine task in > python+numpy ? (of course, not using pyraf.imcombine call) > > > Thanks ! > Jose > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Erik Tollerud From klabrie at gemini.edu Tue Mar 6 14:01:07 2012 From: klabrie at gemini.edu (Kathleen Labrie) Date: Tue, 6 Mar 2012 09:01:07 -1000 Subject: [AstroPy] Image combine In-Reply-To: References: Message-ID: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> Hi, I think Jose mostly refer to the rejection, masking, scaling, weighing algorithms that iraf imcombine offers. I agree the arithmetic is easy enough to do with numpy and pyfits, even the median. It's the rest of imcombine that can get tricky (and bloated). For the record, here at Gemini, we will soon embark it that foolish adventure of trying to reproduce at least some of the imcombine features (but only the ones we need due to time and resource constraints). We are still at the point of defining which features we really need though, so I don't think it will help Jose much for now. I am very interested to hear if someone has written some code for a imcombine-like routine. Cheers, Kathleen On Mar 6, 2012, at 8:52 AM, Erik Tollerud wrote: > I'm not aware of a function that does it exactly with the interface of > imcombine, but it can be done pretty easily with pyfits: > > import pyfits > > f1 = pyfits.open('filename1') > f2 = pyfits.open('filename2') > > h1 = f1[0].header > im1 = f1[0].data > im2 = f2[0].data > > newimage = im1 + im2 > > newhdu = pyfits.PrimaryHDU(data=newimage,header=h1) > newhdu.writeto('newfilename') > > > That example is specific to addition, of course (the im1 + im2 part, > but it should be clear how to generalize it to other arithmetic > operations. > > > 2012/3/6 Jose Miguel Ib??ez : >> Hello everyone, >> >> does anyone know of an implementation of the iraf.imcombine task in >> python+numpy ? (of course, not using pyraf.imcombine call) >> >> >> Thanks ! >> Jose >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > > -- > Erik Tollerud > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From chanley at gmail.com Tue Mar 6 14:11:36 2012 From: chanley at gmail.com (Christopher Hanley) Date: Tue, 6 Mar 2012 14:11:36 -0500 Subject: [AstroPy] Image combine In-Reply-To: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> References: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> Message-ID: There is a "lite" version called numcombine living in stsci.image. It doesn't exactly have a user friendly interface and I would definitely do it differently if I had to do it again. But it might be a place to start. Chris On Tue, Mar 6, 2012 at 2:01 PM, Kathleen Labrie wrote: > Hi, > > I think Jose mostly refer to the rejection, masking, scaling, weighing > algorithms that iraf imcombine offers. I agree the arithmetic is easy > enough to do with numpy and pyfits, even the median. It's the rest > of imcombine that can get tricky (and bloated). > > For the record, here at Gemini, we will soon embark it that foolish > adventure > of trying to reproduce at least some of the imcombine features (but only > the ones we need due to time and resource constraints). We are still > at the point of defining which features we really need though, so I don't > think it will help Jose much for now. > > I am very interested to hear if someone has written some code for a > imcombine-like routine. > > Cheers, > Kathleen > > On Mar 6, 2012, at 8:52 AM, Erik Tollerud wrote: > > > I'm not aware of a function that does it exactly with the interface of > > imcombine, but it can be done pretty easily with pyfits: > > > > import pyfits > > > > f1 = pyfits.open('filename1') > > f2 = pyfits.open('filename2') > > > > h1 = f1[0].header > > im1 = f1[0].data > > im2 = f2[0].data > > > > newimage = im1 + im2 > > > > newhdu = pyfits.PrimaryHDU(data=newimage,header=h1) > > newhdu.writeto('newfilename') > > > > > > That example is specific to addition, of course (the im1 + im2 part, > > but it should be clear how to generalize it to other arithmetic > > operations. > > > > > > 2012/3/6 Jose Miguel Ib??ez : > >> Hello everyone, > >> > >> does anyone know of an implementation of the iraf.imcombine task in > >> python+numpy ? (of course, not using pyraf.imcombine call) > >> > >> > >> Thanks ! > >> Jose > >> _______________________________________________ > >> AstroPy mailing list > >> AstroPy at scipy.org > >> http://mail.scipy.org/mailman/listinfo/astropy > > > > > > > > -- > > Erik Tollerud > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neilcrighton at gmail.com Tue Mar 6 16:08:31 2012 From: neilcrighton at gmail.com (Neil Crighton) Date: Tue, 6 Mar 2012 22:08:31 +0100 Subject: [AstroPy] Image combine In-Reply-To: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> References: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> Message-ID: Hi, I started to write a Cython version of imcombine that allows weight images to be used and includes outlier rejection. It can operate on a series of images too large to all fit in memory by using memory mapped arrays. It's not thoroughly tested though. Let me know if you're interested in the code and I'll email to you. Cheers, Neil On 6 March 2012 20:01, Kathleen Labrie wrote: > Hi, > > I think Jose mostly refer to the rejection, masking, scaling, weighing > algorithms that iraf imcombine offers. ? ?I agree the arithmetic is easy > enough to do with numpy and pyfits, even the median. ?It's the rest > of imcombine that can get tricky (and bloated). > > For the record, here at Gemini, we will soon embark it that foolish adventure > of trying to reproduce at least some of the imcombine features (but only > the ones we need due to time and resource constraints). ? We are still > at the point of defining which features we really need though, so I don't > think it will help Jose much for now. > > I am very interested to hear if someone has written some code for a > imcombine-like routine. > > Cheers, > Kathleen > > On Mar 6, 2012, at 8:52 AM, Erik Tollerud wrote: > >> I'm not aware of a function that does it exactly with the interface of >> imcombine, but it can be done pretty easily with pyfits: >> >> import pyfits >> >> f1 = pyfits.open('filename1') >> f2 = pyfits.open('filename2') >> >> h1 = f1[0].header >> im1 = f1[0].data >> im2 = f2[0].data >> >> newimage = im1 + im2 >> >> newhdu = pyfits.PrimaryHDU(data=newimage,header=h1) >> newhdu.writeto('newfilename') >> >> >> That example is specific to addition, of course (the im1 + im2 part, >> but it should be clear how to generalize it to other arithmetic >> operations. >> >> >> 2012/3/6 Jose Miguel Ib??ez : >>> Hello everyone, >>> >>> does anyone know of an implementation of the iraf.imcombine task in >>> python+numpy ? (of course, not using pyraf.imcombine call) >>> >>> >>> Thanks ! >>> Jose >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >> >> >> >> -- >> Erik Tollerud >> _______________________________________________ >> 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 From erik.tollerud at gmail.com Tue Mar 6 16:08:42 2012 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Tue, 6 Mar 2012 13:08:42 -0800 Subject: [AstroPy] Image combine In-Reply-To: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> References: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> Message-ID: Fair enough - I just meant many (although certainly not all) of the imcomb options can be done by converting to numpy arrays, doing the operation (including masking and the like), and converting back. But you're right that some of the more complicated functions in imcombine would require a lot of work to re-implement. Tools like this are definitely something that we would definitely like to see as another major affiliated package for astropy, by the way - perhaps "imageutils" or similar. So if you're planning on embarking on such an adventure at Gemini, It'd be great if you could, at least in part, implement it in that form! 2012/3/6 Kathleen Labrie : > Hi, > > I think Jose mostly refer to the rejection, masking, scaling, weighing > algorithms that iraf imcombine offers. ? ?I agree the arithmetic is easy > enough to do with numpy and pyfits, even the median. ?It's the rest > of imcombine that can get tricky (and bloated). > > For the record, here at Gemini, we will soon embark it that foolish adventure > of trying to reproduce at least some of the imcombine features (but only > the ones we need due to time and resource constraints). ? We are still > at the point of defining which features we really need though, so I don't > think it will help Jose much for now. > > I am very interested to hear if someone has written some code for a > imcombine-like routine. > > Cheers, > Kathleen > > On Mar 6, 2012, at 8:52 AM, Erik Tollerud wrote: > >> I'm not aware of a function that does it exactly with the interface of >> imcombine, but it can be done pretty easily with pyfits: >> >> import pyfits >> >> f1 = pyfits.open('filename1') >> f2 = pyfits.open('filename2') >> >> h1 = f1[0].header >> im1 = f1[0].data >> im2 = f2[0].data >> >> newimage = im1 + im2 >> >> newhdu = pyfits.PrimaryHDU(data=newimage,header=h1) >> newhdu.writeto('newfilename') >> >> >> That example is specific to addition, of course (the im1 + im2 part, >> but it should be clear how to generalize it to other arithmetic >> operations. >> >> >> 2012/3/6 Jose Miguel Ib??ez : >>> Hello everyone, >>> >>> does anyone know of an implementation of the iraf.imcombine task in >>> python+numpy ? (of course, not using pyraf.imcombine call) >>> >>> >>> Thanks ! >>> Jose >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >> >> >> >> -- >> Erik Tollerud >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > -- Erik Tollerud From ppmime at gmail.com Wed Mar 7 03:43:11 2012 From: ppmime at gmail.com (=?ISO-8859-1?Q?Jose_Miguel_Ib=E1=F1ez?=) Date: Wed, 7 Mar 2012 09:43:11 +0100 Subject: [AstroPy] Image combine In-Reply-To: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> References: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> Message-ID: Hi ! Right Kathleen, I mostly refer to the rejection, masking, scaling ... algorithms; the idea is to avoid to install all the PyRAF staff only because the nice iraf.imcombine task. I have tried to implement some of those features, but for the moment the main problem is that my routine is extremely slow (~2min) following the next schema: import numpy as np ndim = 2048 cube = np.random.rand(32,ndim, ndim) result = np.zeros([ndim, ndim], np.float32) def combine(cube, result): for ii in range(ndim): for jj in range(ndim): result[ii, jj] = my_sigma_clip(cube[:,ii,jj]) return result However, the next numpy sentence is very fast (less than 1 second ) >> median_result = np.median(cube,0) So, I'd also like to find out where is the point of that difference. As Erik suggests, I think that kind of combine-like routines should be in the next coming astropy package, maybe with the effort of all of us. So Kathleen, I encourage you to continue with your adventure at Gemini and let us know about your progress. Cheers, Jose 2012/3/6 Kathleen Labrie : > Hi, > > I think Jose mostly refer to the rejection, masking, scaling, weighing > algorithms that iraf imcombine offers. ? ?I agree the arithmetic is easy > enough to do with numpy and pyfits, even the median. ?It's the rest > of imcombine that can get tricky (and bloated). > > For the record, here at Gemini, we will soon embark it that foolish adventure > of trying to reproduce at least some of the imcombine features (but only > the ones we need due to time and resource constraints). ? We are still > at the point of defining which features we really need though, so I don't > think it will help Jose much for now. > > I am very interested to hear if someone has written some code for a > imcombine-like routine. > > Cheers, > Kathleen > > On Mar 6, 2012, at 8:52 AM, Erik Tollerud wrote: > >> I'm not aware of a function that does it exactly with the interface of >> imcombine, but it can be done pretty easily with pyfits: >> >> import pyfits >> >> f1 = pyfits.open('filename1') >> f2 = pyfits.open('filename2') >> >> h1 = f1[0].header >> im1 = f1[0].data >> im2 = f2[0].data >> >> newimage = im1 + im2 >> >> newhdu = pyfits.PrimaryHDU(data=newimage,header=h1) >> newhdu.writeto('newfilename') >> >> >> That example is specific to addition, of course (the im1 + im2 part, >> but it should be clear how to generalize it to other arithmetic >> operations. >> >> >> 2012/3/6 Jose Miguel Ib??ez : >>> Hello everyone, >>> >>> does anyone know of an implementation of the iraf.imcombine task in >>> python+numpy ? (of course, not using pyraf.imcombine call) >>> >>> >>> Thanks ! >>> Jose >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >> >> >> >> -- >> Erik Tollerud >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > From alexander.y.wagner at googlemail.com Wed Mar 7 04:13:14 2012 From: alexander.y.wagner at googlemail.com (Alexander Wagner) Date: Wed, 07 Mar 2012 18:13:14 +0900 Subject: [AstroPy] Image combine In-Reply-To: References: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> Message-ID: <4F5726AA.6090009@gmail.com> If you can turn my_sigma_clip into a ufunc, you could do my_sigma_clip.reduce(cube, axis=0) http://docs.scipy.org/doc/numpy/user/c-info.ufunc-tutorial.html http://docs.scipy.org/doc/numpy/reference/generated/numpy.ufunc.reduce.html Best wishes, Alex On 7/03/12 5:43 PM, Jose Miguel Ib??ez wrote: > Hi ! > > Right Kathleen, I mostly refer to the rejection, masking, scaling ... > algorithms; the idea is to avoid to install all the PyRAF staff only > because the nice iraf.imcombine task. > I have tried to implement some of those features, but for the moment > the main problem is that my routine is extremely slow (~2min) > following the next schema: > > import numpy as np > > ndim = 2048 > > cube = np.random.rand(32,ndim, ndim) > result = np.zeros([ndim, ndim], np.float32) > > def combine(cube, result): > > for ii in range(ndim): > for jj in range(ndim): > result[ii, jj] = my_sigma_clip(cube[:,ii,jj]) > return result > > > However, the next numpy sentence is very fast (less than 1 second ) > >>> median_result = np.median(cube,0) > So, I'd also like to find out where is the point of that difference. > > > As Erik suggests, I think that kind of combine-like routines should be > in the next coming astropy package, maybe with the effort of all of > us. > So Kathleen, I encourage you to continue with your adventure at Gemini > and let us know about your progress. > > Cheers, > Jose > > > > 2012/3/6 Kathleen Labrie: >> Hi, >> >> I think Jose mostly refer to the rejection, masking, scaling, weighing >> algorithms that iraf imcombine offers. I agree the arithmetic is easy >> enough to do with numpy and pyfits, even the median. It's the rest >> of imcombine that can get tricky (and bloated). >> >> For the record, here at Gemini, we will soon embark it that foolish adventure >> of trying to reproduce at least some of the imcombine features (but only >> the ones we need due to time and resource constraints). We are still >> at the point of defining which features we really need though, so I don't >> think it will help Jose much for now. >> >> I am very interested to hear if someone has written some code for a >> imcombine-like routine. >> >> Cheers, >> Kathleen >> >> On Mar 6, 2012, at 8:52 AM, Erik Tollerud wrote: >> >>> I'm not aware of a function that does it exactly with the interface of >>> imcombine, but it can be done pretty easily with pyfits: >>> >>> import pyfits >>> >>> f1 = pyfits.open('filename1') >>> f2 = pyfits.open('filename2') >>> >>> h1 = f1[0].header >>> im1 = f1[0].data >>> im2 = f2[0].data >>> >>> newimage = im1 + im2 >>> >>> newhdu = pyfits.PrimaryHDU(data=newimage,header=h1) >>> newhdu.writeto('newfilename') >>> >>> >>> That example is specific to addition, of course (the im1 + im2 part, >>> but it should be clear how to generalize it to other arithmetic >>> operations. >>> >>> >>> 2012/3/6 Jose Miguel Ib??ez: >>>> Hello everyone, >>>> >>>> does anyone know of an implementation of the iraf.imcombine task in >>>> python+numpy ? (of course, not using pyraf.imcombine call) >>>> >>>> >>>> Thanks ! >>>> Jose >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/astropy >>> >>> >>> -- >>> Erik Tollerud >>> _______________________________________________ >>> 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 From eebanado at uc.cl Wed Mar 7 04:16:10 2012 From: eebanado at uc.cl (=?ISO-8859-1?Q?Eduardo_Ba=F1ados_Torres?=) Date: Wed, 7 Mar 2012 10:16:10 +0100 Subject: [AstroPy] Image combine In-Reply-To: <4F5726AA.6090009@gmail.com> References: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> <4F5726AA.6090009@gmail.com> Message-ID: Hi all, I started to write a imcombine-like routine but it still needs a lot of improvements. The main features are mean or median combination, image scaling (mean, median or mode. You can also choose the image section for computing the statistics) and sigma-clipping. The normal mean/median combinations are very fast. For scaling using the mode, I had to write my own method which is not really optimal (I have some ideas to improve it but I haven't had time) but is faster than scipy.stats.mode One big problem is that combinations using sigma-clipping are hundreds times slower than the no-clipped methods, mainly due to the use of numpy masked arrays which are too slow! If someone knows a faster way for the sigma-clipping please let me know :) If you think this can be useful, I'd be happy to share it and get some feedback. So drop me a line if you want me to email you the code, in the meantime I will comment it. Cheers, Eduardo On Wed, Mar 7, 2012 at 10:13 AM, Alexander Wagner wrote: > > If you can turn my_sigma_clip into a ufunc, you could do > > my_sigma_clip.reduce(cube, axis=0) > > http://docs.scipy.org/doc/numpy/user/c-info.ufunc-tutorial.html > http://docs.scipy.org/doc/numpy/reference/generated/numpy.ufunc.reduce.html > > Best wishes, > Alex > > > On 7/03/12 5:43 PM, Jose Miguel Ib??ez wrote: >> Hi ! >> >> Right Kathleen, I mostly refer to the rejection, masking, scaling ... >> algorithms; the idea is to avoid to install all the PyRAF staff only >> because the nice iraf.imcombine task. >> I have tried to implement some of those features, but for the moment >> the main problem is that my routine is extremely slow (~2min) >> following the next schema: >> >> import numpy as np >> >> ndim = 2048 >> >> cube = np.random.rand(32,ndim, ndim) >> result = np.zeros([ndim, ndim], np.float32) >> >> def combine(cube, result): >> >> ? ? ?for ii in range(ndim): >> ? ? ? ? ?for jj in range(ndim): >> ? ? ? ? ? ? ?result[ii, jj] = my_sigma_clip(cube[:,ii,jj]) >> ? ? ?return result >> >> >> However, the next numpy sentence is very fast (less than 1 second ) >> >>>> median_result = np.median(cube,0) >> So, I'd also like to find out where is the point of that difference. >> >> >> As Erik suggests, I think that kind of combine-like routines should be >> in the next coming astropy package, maybe with the effort of all of >> us. >> So Kathleen, I encourage you to continue with your adventure at Gemini >> and let us know about your progress. >> >> Cheers, >> Jose >> >> >> >> 2012/3/6 Kathleen Labrie: >>> Hi, >>> >>> I think Jose mostly refer to the rejection, masking, scaling, weighing >>> algorithms that iraf imcombine offers. ? ?I agree the arithmetic is easy >>> enough to do with numpy and pyfits, even the median. ?It's the rest >>> of imcombine that can get tricky (and bloated). >>> >>> For the record, here at Gemini, we will soon embark it that foolish adventure >>> of trying to reproduce at least some of the imcombine features (but only >>> the ones we need due to time and resource constraints). ? We are still >>> at the point of defining which features we really need though, so I don't >>> think it will help Jose much for now. >>> >>> I am very interested to hear if someone has written some code for a >>> imcombine-like routine. >>> >>> Cheers, >>> Kathleen >>> >>> On Mar 6, 2012, at 8:52 AM, Erik Tollerud wrote: >>> >>>> I'm not aware of a function that does it exactly with the interface of >>>> imcombine, but it can be done pretty easily with pyfits: >>>> >>>> import pyfits >>>> >>>> f1 = pyfits.open('filename1') >>>> f2 = pyfits.open('filename2') >>>> >>>> h1 = f1[0].header >>>> im1 = f1[0].data >>>> im2 = f2[0].data >>>> >>>> newimage = im1 + im2 >>>> >>>> newhdu = pyfits.PrimaryHDU(data=newimage,header=h1) >>>> newhdu.writeto('newfilename') >>>> >>>> >>>> That example is specific to addition, of course (the im1 + im2 part, >>>> but it should be clear how to generalize it to other arithmetic >>>> operations. >>>> >>>> >>>> 2012/3/6 Jose Miguel Ib??ez: >>>>> Hello everyone, >>>>> >>>>> does anyone know of an implementation of the iraf.imcombine task in >>>>> python+numpy ? (of course, not using pyraf.imcombine call) >>>>> >>>>> >>>>> Thanks ! >>>>> Jose >>>>> _______________________________________________ >>>>> AstroPy mailing list >>>>> AstroPy at scipy.org >>>>> http://mail.scipy.org/mailman/listinfo/astropy >>>> >>>> >>>> -- >>>> Erik Tollerud >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Eduardo Ba?ados Torres From sergiopr at fis.ucm.es Wed Mar 7 04:41:21 2012 From: sergiopr at fis.ucm.es (Sergio Pascual) Date: Wed, 7 Mar 2012 10:41:21 +0100 Subject: [AstroPy] Image combine In-Reply-To: References: Message-ID: Hello I have written a image combine implementation for the pipeline of EMIR[1], a near infrared instrument for the 10m GTC Telescope. It does scaling, weighting and masking. It's written as a C/C++ extension. It's part of a larger package, numina, used for other GTC instruments, but I may split combine if there is interest in it. The package, called numina, its under heavy development, but the combine part is fairly stable. You can see the code here https://guaix.fis.ucm.es/hg/numina/ The combine part is the module numina.array.combine, fairly all the C/C++ code is in src/ Regards, Sergio [1] http://www.gtc.iac.es/pages/instrumentacion/emir.php [2] http://www.gtc.iac.es/ El d?a 6 de marzo de 2012 12:00, Jose Miguel Ib??ez escribi?: > Hello everyone, > > does anyone know of an implementation of the iraf.imcombine task in > python+numpy ? (of course, not using pyraf.imcombine call) > > > Thanks ! > Jose > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Sergio Pascual ? ? http://guaix.fis.ucm.es/~spr ? ?+34 91 394 5018 gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) From perry at stsci.edu Wed Mar 7 08:30:51 2012 From: perry at stsci.edu (Perry Greenfield) Date: Wed, 7 Mar 2012 08:30:51 -0500 Subject: [AstroPy] Image combine In-Reply-To: References: <9A748A52-3CBE-4E86-97D4-1FBE834DE036@gemini.edu> Message-ID: <733F0713-976E-470C-B965-35B609ADCC0F@stsci.edu> Hi Jose, Anytime you iterate over every pixel in a loop, you are going to find that it is very slow. You want to be operating on at least 1000 pixels at a time (ideally more than 10,000) to avoid numpy overhead. Using masks to do the sigma clipping would be much faster (though not as optimized as doing it in C as others mention). Perry On Mar 7, 2012, at 3:43 AM, Jose Miguel Ib??ez wrote: > Hi ! > > Right Kathleen, I mostly refer to the rejection, masking, scaling ... > algorithms; the idea is to avoid to install all the PyRAF staff only > because the nice iraf.imcombine task. > I have tried to implement some of those features, but for the moment > the main problem is that my routine is extremely slow (~2min) > following the next schema: > > import numpy as np > > ndim = 2048 > > cube = np.random.rand(32,ndim, ndim) > result = np.zeros([ndim, ndim], np.float32) > > def combine(cube, result): > > for ii in range(ndim): > for jj in range(ndim): > result[ii, jj] = my_sigma_clip(cube[:,ii,jj]) > return result > > > However, the next numpy sentence is very fast (less than 1 second ) > >>> median_result = np.median(cube,0) From wkerzendorf at gmail.com Wed Mar 7 08:41:00 2012 From: wkerzendorf at gmail.com (Wolfgang Kerzendorf) Date: Wed, 7 Mar 2012 08:41:00 -0500 Subject: [AstroPy] Image combine In-Reply-To: References:

Message-ID: <79E82236-E34D-4733-91C9-FD9B67A8E1D3@gmail.com> Hello Jose, What you're trying to do is already half implemented in numpy and called masked arrays: Let's say you want to stack images and you have put them together in a 3d cube (first axis being the images): myimages = numpy.ma.MaskedArray(rand(5,100,100), mask=zeros((5,100,100).astype(bool)) let's do a simple sigma clipping algorithm: image_mean = mean(myimages) image_std = std(myimages) #now let's adjust the mask to mask the pixels that are more than 1 sigma out new_mask = abs(myimages - image_mean) > 1. myimages.mask = new_mask #if you do a mean now it will ignore the values where the mask = True mean(myimages, axis=0) This will be all near C-speeds (I guess a factor of 100 is easily in there). ---- As other's have pointed out using i,j in a loop is a very bad idea for numpy arrays. Numpy arrays are much more easy to handle than in most other languages, there is a bit of getting used to required though. I recommend reviewing the different operations on http://www.scipy.org/Tentative_NumPy_Tutorial. Hope that helps, Wolfgang On 2012-03-07, at 4:41 AM, Sergio Pascual wrote: > Hello > > I have written a image combine implementation for the pipeline of > EMIR[1], a near infrared instrument for the 10m GTC Telescope. It does > scaling, > weighting and masking. It's written as a C/C++ extension. It's part of > a larger package, numina, used for other GTC instruments, but I may > split combine if there is interest in it. The package, called numina, > its under heavy development, but the combine part is fairly stable. > > You can see the code here https://guaix.fis.ucm.es/hg/numina/ > > The combine part is the module numina.array.combine, fairly all the > C/C++ code is in src/ > > Regards, Sergio > > > [1] http://www.gtc.iac.es/pages/instrumentacion/emir.php > [2] http://www.gtc.iac.es/ > > > > El d?a 6 de marzo de 2012 12:00, Jose Miguel Ib??ez escribi?: >> Hello everyone, >> >> does anyone know of an implementation of the iraf.imcombine task in >> python+numpy ? (of course, not using pyraf.imcombine call) >> >> >> Thanks ! >> Jose >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > > -- > Sergio Pascual http://guaix.fis.ucm.es/~spr +34 91 394 5018 > gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC > Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From neilcrighton at gmail.com Wed Mar 7 08:45:31 2012 From: neilcrighton at gmail.com (Neil Crighton) Date: Wed, 7 Mar 2012 14:45:31 +0100 Subject: [AstroPy] Image combine In-Reply-To: <79E82236-E34D-4733-91C9-FD9B67A8E1D3@gmail.com> References:

<79E82236-E34D-4733-91C9-FD9B67A8E1D3@gmail.com> Message-ID: Hi Wolfgang, The problem is that masked arrays in numpy are not implemented in c, so they are not c-speed. There is a proposal to implement a masked array in c (https://github.com/numpy/numpy/blob/master/doc/neps/missing-data.rst) but this hasn't been finalised. Cheers, Neil On 7 March 2012 14:41, Wolfgang Kerzendorf wrote: > Hello Jose, > > What you're trying to do is already half implemented in numpy and called > masked arrays: > > Let's say you want to stack images and you have put them together in a 3d > cube (first axis being the images): > > myimages = numpy.ma.MaskedArray(rand(5,100,100), > mask=zeros((5,100,100).astype(bool)) > > let's do a simple sigma clipping algorithm: > > image_mean = mean(myimages) > image_std = std(myimages) > > #now let's adjust the mask to mask the pixels that are more than 1 sigma out > > new_mask = abs(myimages - image_mean) > 1. > > myimages.mask = new_mask > > #if you do a mean now it will ignore the values where the mask = True > > mean(myimages, axis=0) > > This will be all near C-speeds (I guess a factor of 100 is easily in there). > ---- > > As other's have pointed out using i,j in a loop is a very bad idea for numpy > arrays. Numpy arrays are much more easy to handle than in most other > languages, there is a bit of getting used to required though. I recommend > reviewing the different operations > on?http://www.scipy.org/Tentative_NumPy_Tutorial. > > Hope that helps, > > ? ? Wolfgang > On 2012-03-07, at 4:41 AM, Sergio Pascual wrote: > > Hello > > I have written a image combine implementation for the pipeline of > EMIR[1], a near infrared instrument for the 10m GTC Telescope. It does > scaling, > weighting and masking. It's written as a C/C++ extension. It's part of > a larger package, numina, used for other GTC instruments, but I may > split combine if there is interest in it. The package, called numina, > its under heavy development, but the combine part is fairly stable. > > You can see the code here https://guaix.fis.ucm.es/hg/numina/ > > The combine part is the module numina.array.combine, fairly all the > C/C++ code is in src/ > > Regards, Sergio > > > [1] http://www.gtc.iac.es/pages/instrumentacion/emir.php > [2] http://www.gtc.iac.es/ > > > > El d?a 6 de marzo de 2012 12:00, Jose Miguel Ib??ez > escribi?: > > Hello everyone, > > > does anyone know of an implementation of the iraf.imcombine task in > > python+numpy ? (of course, not using pyraf.imcombine call) > > > > Thanks ! > > Jose > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > -- > Sergio Pascual ? ? http://guaix.fis.ucm.es/~spr ? ?+34 91 394 5018 > gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC > Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) > _______________________________________________ > 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 > From wkerzendorf at gmail.com Wed Mar 7 08:50:08 2012 From: wkerzendorf at gmail.com (Wolfgang Kerzendorf) Date: Wed, 7 Mar 2012 08:50:08 -0500 Subject: [AstroPy] Image combine In-Reply-To: References:

<79E82236-E34D-4733-91C9-FD9B67A8E1D3@gmail.com> Message-ID: <240D4B68-6CCD-4D38-81E1-B293E3AE097C@gmail.com> But they do use Numpy's underlying arrays, right? Which are implemented in C? I do understand that the whole structure still somewhat relies on python. Irregardless of what they are implemented in, I found them to be fast. In [132]: myimages = numpy.ma.MaskedArray(rand(5,1000,1000), rand(5, 1000, 1000) > .5) In [133]: %timeit myimages.mean(axis=0) 1 loops, best of 3: 255 ms per loop Cheers W On 2012-03-07, at 8:45 AM, Neil Crighton wrote: > Hi Wolfgang, > > The problem is that masked arrays in numpy are not implemented in c, > so they are not c-speed. There is a proposal to implement a masked > array in c (https://github.com/numpy/numpy/blob/master/doc/neps/missing-data.rst) > but this hasn't been finalised. > > Cheers, Neil > > > On 7 March 2012 14:41, Wolfgang Kerzendorf wrote: >> Hello Jose, >> >> What you're trying to do is already half implemented in numpy and called >> masked arrays: >> >> Let's say you want to stack images and you have put them together in a 3d >> cube (first axis being the images): >> >> myimages = numpy.ma.MaskedArray(rand(5,100,100), >> mask=zeros((5,100,100).astype(bool)) >> >> let's do a simple sigma clipping algorithm: >> >> image_mean = mean(myimages) >> image_std = std(myimages) >> >> #now let's adjust the mask to mask the pixels that are more than 1 sigma out >> >> new_mask = abs(myimages - image_mean) > 1. >> >> myimages.mask = new_mask >> >> #if you do a mean now it will ignore the values where the mask = True >> >> mean(myimages, axis=0) >> >> This will be all near C-speeds (I guess a factor of 100 is easily in there). >> ---- >> >> As other's have pointed out using i,j in a loop is a very bad idea for numpy >> arrays. Numpy arrays are much more easy to handle than in most other >> languages, there is a bit of getting used to required though. I recommend >> reviewing the different operations >> on http://www.scipy.org/Tentative_NumPy_Tutorial. >> >> Hope that helps, >> >> Wolfgang >> On 2012-03-07, at 4:41 AM, Sergio Pascual wrote: >> >> Hello >> >> I have written a image combine implementation for the pipeline of >> EMIR[1], a near infrared instrument for the 10m GTC Telescope. It does >> scaling, >> weighting and masking. It's written as a C/C++ extension. It's part of >> a larger package, numina, used for other GTC instruments, but I may >> split combine if there is interest in it. The package, called numina, >> its under heavy development, but the combine part is fairly stable. >> >> You can see the code here https://guaix.fis.ucm.es/hg/numina/ >> >> The combine part is the module numina.array.combine, fairly all the >> C/C++ code is in src/ >> >> Regards, Sergio >> >> >> [1] http://www.gtc.iac.es/pages/instrumentacion/emir.php >> [2] http://www.gtc.iac.es/ >> >> >> >> El d?a 6 de marzo de 2012 12:00, Jose Miguel Ib??ez >> escribi?: >> >> Hello everyone, >> >> >> does anyone know of an implementation of the iraf.imcombine task in >> >> python+numpy ? (of course, not using pyraf.imcombine call) >> >> >> >> Thanks ! >> >> Jose >> >> _______________________________________________ >> >> AstroPy mailing list >> >> AstroPy at scipy.org >> >> http://mail.scipy.org/mailman/listinfo/astropy >> >> >> >> >> -- >> Sergio Pascual http://guaix.fis.ucm.es/~spr +34 91 394 5018 >> gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC >> Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) >> _______________________________________________ >> 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 >> From perry at stsci.edu Wed Mar 7 08:52:03 2012 From: perry at stsci.edu (Perry Greenfield) Date: Wed, 7 Mar 2012 08:52:03 -0500 Subject: [AstroPy] Image combine In-Reply-To: References:

<79E82236-E34D-4733-91C9-FD9B67A8E1D3@gmail.com> Message-ID: <92863DF9-1BD9-41CF-847F-FC554D9287B6@stsci.edu> Hi Neil, That's a bit misleading. The application of the masking operation is certainly done in C. The whole issue is how tightly integrated the masks are with native arrays. For large arrays, it's not likely a significant speed issue per se, but it is perhaps a memory issue (with consequent speed issues if memory caches are involved). Perry On Mar 7, 2012, at 8:45 AM, Neil Crighton wrote: > Hi Wolfgang, > > The problem is that masked arrays in numpy are not implemented in c, > so they are not c-speed. There is a proposal to implement a masked > array in c (https://github.com/numpy/numpy/blob/master/doc/neps/missing-data.rst > ) > but this hasn't been finalised. > > Cheers, Neil > > > On 7 March 2012 14:41, Wolfgang Kerzendorf > wrote: >> Hello Jose, >> >> What you're trying to do is already half implemented in numpy and >> called >> masked arrays: >> >> Let's say you want to stack images and you have put them together >> in a 3d >> cube (first axis being the images): >> >> myimages = numpy.ma.MaskedArray(rand(5,100,100), >> mask=zeros((5,100,100).astype(bool)) >> >> let's do a simple sigma clipping algorithm: >> >> image_mean = mean(myimages) >> image_std = std(myimages) >> >> #now let's adjust the mask to mask the pixels that are more than 1 >> sigma out >> >> new_mask = abs(myimages - image_mean) > 1. >> >> myimages.mask = new_mask >> >> #if you do a mean now it will ignore the values where the mask = True >> >> mean(myimages, axis=0) >> >> This will be all near C-speeds (I guess a factor of 100 is easily >> in there). >> ---- >> >> As other's have pointed out using i,j in a loop is a very bad idea >> for numpy >> arrays. Numpy arrays are much more easy to handle than in most other >> languages, there is a bit of getting used to required though. I >> recommend >> reviewing the different operations >> on http://www.scipy.org/Tentative_NumPy_Tutorial. >> >> Hope that helps, >> >> Wolfgang >> On 2012-03-07, at 4:41 AM, Sergio Pascual wrote: >> >> Hello >> >> I have written a image combine implementation for the pipeline of >> EMIR[1], a near infrared instrument for the 10m GTC Telescope. It >> does >> scaling, >> weighting and masking. It's written as a C/C++ extension. It's part >> of >> a larger package, numina, used for other GTC instruments, but I may >> split combine if there is interest in it. The package, called numina, >> its under heavy development, but the combine part is fairly stable. >> >> You can see the code here https://guaix.fis.ucm.es/hg/numina/ >> >> The combine part is the module numina.array.combine, fairly all the >> C/C++ code is in src/ >> >> Regards, Sergio >> >> >> [1] http://www.gtc.iac.es/pages/instrumentacion/emir.php >> [2] http://www.gtc.iac.es/ >> >> >> >> El d?a 6 de marzo de 2012 12:00, Jose Miguel Ib??ez >> >> escribi?: >> >> Hello everyone, >> >> >> does anyone know of an implementation of the iraf.imcombine task in >> >> python+numpy ? (of course, not using pyraf.imcombine call) >> >> >> >> Thanks ! >> >> Jose >> >> _______________________________________________ >> >> AstroPy mailing list >> >> AstroPy at scipy.org >> >> http://mail.scipy.org/mailman/listinfo/astropy >> >> >> >> >> -- >> Sergio Pascual http://guaix.fis.ucm.es/~spr +34 91 394 5018 >> gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC >> Departamento de Astrof?sica -- Universidad Complutense de Madrid >> (Spain) >> _______________________________________________ >> 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 >> > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From t_ribeiro at me.com Wed Mar 7 10:11:53 2012 From: t_ribeiro at me.com (Tiago Ribeiro de Souza) Date: Wed, 07 Mar 2012 12:11:53 -0300 Subject: [AstroPy] Image combine In-Reply-To: <92863DF9-1BD9-41CF-847F-FC554D9287B6@stsci.edu> References:

<79E82236-E34D-4733-91C9-FD9B67A8E1D3@gmail.com> <92863DF9-1BD9-41CF-847F-FC554D9287B6@stsci.edu> Message-ID: <63972524-48D2-4579-A4F6-91B90A2E534B@me.com> Hi guys, Even though I understand that people want to be free from using IRAF, I don't agree that only translating its basic functionality to other programming language is actually useful. If we ought to look to the future I would say that we should start an effort to provide a GPU-enabled suite of image reduction facility ratter than replicating existing code in different languages. Given the level of paralalization of image reduction (say image combine, subtraction, division, source extraction, spectral extraction and more!) GPU programming will definitively be much more important and useful. For those who are interested, check out this tutorial at http://www.macresearch.org/opencl and http://developer.nvidia.com/content/september-2009-opencl-public-downloads Cheers, T. Em 07/03/2012, ?s 10:52, Perry Greenfield escreveu: > Hi Neil, > > That's a bit misleading. The application of the masking operation is > certainly done in C. The whole issue is how tightly integrated the > masks are with native arrays. For large arrays, it's not likely a > significant speed issue per se, but it is perhaps a memory issue (with > consequent speed issues if memory caches are involved). > > Perry > > On Mar 7, 2012, at 8:45 AM, Neil Crighton wrote: > >> Hi Wolfgang, >> >> The problem is that masked arrays in numpy are not implemented in c, >> so they are not c-speed. There is a proposal to implement a masked >> array in c (https://github.com/numpy/numpy/blob/master/doc/neps/missing-data.rst >> ) >> but this hasn't been finalised. >> >> Cheers, Neil >> >> >> On 7 March 2012 14:41, Wolfgang Kerzendorf >> wrote: >>> Hello Jose, >>> >>> What you're trying to do is already half implemented in numpy and >>> called >>> masked arrays: >>> >>> Let's say you want to stack images and you have put them together >>> in a 3d >>> cube (first axis being the images): >>> >>> myimages = numpy.ma.MaskedArray(rand(5,100,100), >>> mask=zeros((5,100,100).astype(bool)) >>> >>> let's do a simple sigma clipping algorithm: >>> >>> image_mean = mean(myimages) >>> image_std = std(myimages) >>> >>> #now let's adjust the mask to mask the pixels that are more than 1 >>> sigma out >>> >>> new_mask = abs(myimages - image_mean) > 1. >>> >>> myimages.mask = new_mask >>> >>> #if you do a mean now it will ignore the values where the mask = True >>> >>> mean(myimages, axis=0) >>> >>> This will be all near C-speeds (I guess a factor of 100 is easily >>> in there). >>> ---- >>> >>> As other's have pointed out using i,j in a loop is a very bad idea >>> for numpy >>> arrays. Numpy arrays are much more easy to handle than in most other >>> languages, there is a bit of getting used to required though. I >>> recommend >>> reviewing the different operations >>> on http://www.scipy.org/Tentative_NumPy_Tutorial. >>> >>> Hope that helps, >>> >>> Wolfgang >>> On 2012-03-07, at 4:41 AM, Sergio Pascual wrote: >>> >>> Hello >>> >>> I have written a image combine implementation for the pipeline of >>> EMIR[1], a near infrared instrument for the 10m GTC Telescope. It >>> does >>> scaling, >>> weighting and masking. It's written as a C/C++ extension. It's part >>> of >>> a larger package, numina, used for other GTC instruments, but I may >>> split combine if there is interest in it. The package, called numina, >>> its under heavy development, but the combine part is fairly stable. >>> >>> You can see the code here https://guaix.fis.ucm.es/hg/numina/ >>> >>> The combine part is the module numina.array.combine, fairly all the >>> C/C++ code is in src/ >>> >>> Regards, Sergio >>> >>> >>> [1] http://www.gtc.iac.es/pages/instrumentacion/emir.php >>> [2] http://www.gtc.iac.es/ >>> >>> >>> >>> El d?a 6 de marzo de 2012 12:00, Jose Miguel Ib??ez >>> >>> escribi?: >>> >>> Hello everyone, >>> >>> >>> does anyone know of an implementation of the iraf.imcombine task in >>> >>> python+numpy ? (of course, not using pyraf.imcombine call) >>> >>> >>> >>> Thanks ! >>> >>> Jose >>> >>> _______________________________________________ >>> >>> AstroPy mailing list >>> >>> AstroPy at scipy.org >>> >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >>> >>> >>> >>> -- >>> Sergio Pascual http://guaix.fis.ucm.es/~spr +34 91 394 5018 >>> gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC >>> Departamento de Astrof?sica -- Universidad Complutense de Madrid >>> (Spain) >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> 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 From perry at stsci.edu Wed Mar 7 10:17:43 2012 From: perry at stsci.edu (Perry Greenfield) Date: Wed, 7 Mar 2012 10:17:43 -0500 Subject: [AstroPy] Image combine In-Reply-To: <63972524-48D2-4579-A4F6-91B90A2E534B@me.com> References:

<79E82236-E34D-4733-91C9-FD9B67A8E1D3@gmail.com> <92863DF9-1BD9-41CF-847F-FC554D9287B6@stsci.edu> <63972524-48D2-4579-A4F6-91B90A2E534B@me.com> Message-ID: Do you have any good example of code like this is successfully distributed to users in the wild? So far, the dependencies on the specific GPU hardware seem to make this impractical right now. But maybe I'm missing something. And I'm also a bit confused by the first statement. Are you arguing that we should be porting SPP to GPUs? Perry On Mar 7, 2012, at 10:11 AM, Tiago Ribeiro de Souza wrote: > Hi guys, > > Even though I understand that people want to be free from using > IRAF, I don't agree that only translating its basic functionality > to other programming language is actually useful. If we ought to > look to the future I would say that we should start an effort to > provide a GPU-enabled suite of image reduction facility ratter than > replicating existing code in different languages. Given the level of > paralalization of image reduction (say image combine, subtraction, > division, source extraction, spectral extraction and more!) GPU > programming will definitively be much more important and useful. > > For those who are interested, check out this tutorial at http://www.macresearch.org/opencl > and http://developer.nvidia.com/content/september-2009-opencl-public-downloads > > Cheers, > T. > > Em 07/03/2012, ?s 10:52, Perry Greenfield escreveu: > >> Hi Neil, >> >> That's a bit misleading. The application of the masking operation is >> certainly done in C. The whole issue is how tightly integrated the >> masks are with native arrays. For large arrays, it's not likely a >> significant speed issue per se, but it is perhaps a memory issue >> (with >> consequent speed issues if memory caches are involved). >> >> Perry >> >> On Mar 7, 2012, at 8:45 AM, Neil Crighton wrote: >> >>> Hi Wolfgang, >>> >>> The problem is that masked arrays in numpy are not implemented in c, >>> so they are not c-speed. There is a proposal to implement a masked >>> array in c (https://github.com/numpy/numpy/blob/master/doc/neps/missing-data.rst >>> ) >>> but this hasn't been finalised. >>> >>> Cheers, Neil >>> >>> >>> On 7 March 2012 14:41, Wolfgang Kerzendorf >>> wrote: >>>> Hello Jose, >>>> >>>> What you're trying to do is already half implemented in numpy and >>>> called >>>> masked arrays: >>>> >>>> Let's say you want to stack images and you have put them together >>>> in a 3d >>>> cube (first axis being the images): >>>> >>>> myimages = numpy.ma.MaskedArray(rand(5,100,100), >>>> mask=zeros((5,100,100).astype(bool)) >>>> >>>> let's do a simple sigma clipping algorithm: >>>> >>>> image_mean = mean(myimages) >>>> image_std = std(myimages) >>>> >>>> #now let's adjust the mask to mask the pixels that are more than 1 >>>> sigma out >>>> >>>> new_mask = abs(myimages - image_mean) > 1. >>>> >>>> myimages.mask = new_mask >>>> >>>> #if you do a mean now it will ignore the values where the mask = >>>> True >>>> >>>> mean(myimages, axis=0) >>>> >>>> This will be all near C-speeds (I guess a factor of 100 is easily >>>> in there). >>>> ---- >>>> >>>> As other's have pointed out using i,j in a loop is a very bad idea >>>> for numpy >>>> arrays. Numpy arrays are much more easy to handle than in most >>>> other >>>> languages, there is a bit of getting used to required though. I >>>> recommend >>>> reviewing the different operations >>>> on http://www.scipy.org/Tentative_NumPy_Tutorial. >>>> >>>> Hope that helps, >>>> >>>> Wolfgang >>>> On 2012-03-07, at 4:41 AM, Sergio Pascual wrote: >>>> >>>> Hello >>>> >>>> I have written a image combine implementation for the pipeline of >>>> EMIR[1], a near infrared instrument for the 10m GTC Telescope. It >>>> does >>>> scaling, >>>> weighting and masking. It's written as a C/C++ extension. It's part >>>> of >>>> a larger package, numina, used for other GTC instruments, but I may >>>> split combine if there is interest in it. The package, called >>>> numina, >>>> its under heavy development, but the combine part is fairly stable. >>>> >>>> You can see the code here https://guaix.fis.ucm.es/hg/numina/ >>>> >>>> The combine part is the module numina.array.combine, fairly all the >>>> C/C++ code is in src/ >>>> >>>> Regards, Sergio >>>> >>>> >>>> [1] http://www.gtc.iac.es/pages/instrumentacion/emir.php >>>> [2] http://www.gtc.iac.es/ >>>> >>>> >>>> >>>> El d?a 6 de marzo de 2012 12:00, Jose Miguel Ib??ez >>>> >>>> escribi?: >>>> >>>> Hello everyone, >>>> >>>> >>>> does anyone know of an implementation of the iraf.imcombine task in >>>> >>>> python+numpy ? (of course, not using pyraf.imcombine call) >>>> >>>> >>>> >>>> Thanks ! >>>> >>>> Jose >>>> >>>> _______________________________________________ >>>> >>>> AstroPy mailing list >>>> >>>> AstroPy at scipy.org >>>> >>>> http://mail.scipy.org/mailman/listinfo/astropy >>>> >>>> >>>> >>>> >>>> -- >>>> Sergio Pascual http://guaix.fis.ucm.es/~spr +34 91 394 5018 >>>> gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC >>>> Departamento de Astrof?sica -- Universidad Complutense de Madrid >>>> (Spain) >>>> _______________________________________________ >>>> 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 >>>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From chanley at gmail.com Wed Mar 7 10:19:08 2012 From: chanley at gmail.com (Chris Hanley) Date: Wed, 7 Mar 2012 10:19:08 -0500 Subject: [AstroPy] Image combine In-Reply-To: <63972524-48D2-4579-A4F6-91B90A2E534B@me.com> References:

<79E82236-E34D-4733-91C9-FD9B67A8E1D3@gmail.com> <92863DF9-1BD9-41CF-847F-FC554D9287B6@stsci.edu> <63972524-48D2-4579-A4F6-91B90A2E534B@me.com> Message-ID: <54728433-CC43-4032-9E47-2D9B7E60DB81@gmail.com> I disagree. I don't think spending time on GPU programming is useful. It is too hardware dependent to be generally useful. Parallize the code for multi CPU systems if desired. Forget about a general GPU application. Chris On Mar 7, 2012, at 10:11 AM, Tiago Ribeiro de Souza wrote: > Hi guys, > > Even though I understand that people want to be free from using IRAF, I don't agree that only translating its basic functionality to other programming language is actually useful. If we ought to look to the future I would say that we should start an effort to provide a GPU-enabled suite of image reduction facility ratter than replicating existing code in different languages. Given the level of paralalization of image reduction (say image combine, subtraction, division, source extraction, spectral extraction and more!) GPU programming will definitively be much more important and useful. > > For those who are interested, check out this tutorial at http://www.macresearch.org/opencl and http://developer.nvidia.com/content/september-2009-opencl-public-downloads > > Cheers, > T. > > Em 07/03/2012, ?s 10:52, Perry Greenfield escreveu: > >> Hi Neil, >> >> That's a bit misleading. The application of the masking operation is >> certainly done in C. The whole issue is how tightly integrated the >> masks are with native arrays. For large arrays, it's not likely a >> significant speed issue per se, but it is perhaps a memory issue (with >> consequent speed issues if memory caches are involved). >> >> Perry >> >> On Mar 7, 2012, at 8:45 AM, Neil Crighton wrote: >> >>> Hi Wolfgang, >>> >>> The problem is that masked arrays in numpy are not implemented in c, >>> so they are not c-speed. There is a proposal to implement a masked >>> array in c (https://github.com/numpy/numpy/blob/master/doc/neps/missing-data.rst >>> ) >>> but this hasn't been finalised. >>> >>> Cheers, Neil >>> >>> >>> On 7 March 2012 14:41, Wolfgang Kerzendorf >>> wrote: >>>> Hello Jose, >>>> >>>> What you're trying to do is already half implemented in numpy and >>>> called >>>> masked arrays: >>>> >>>> Let's say you want to stack images and you have put them together >>>> in a 3d >>>> cube (first axis being the images): >>>> >>>> myimages = numpy.ma.MaskedArray(rand(5,100,100), >>>> mask=zeros((5,100,100).astype(bool)) >>>> >>>> let's do a simple sigma clipping algorithm: >>>> >>>> image_mean = mean(myimages) >>>> image_std = std(myimages) >>>> >>>> #now let's adjust the mask to mask the pixels that are more than 1 >>>> sigma out >>>> >>>> new_mask = abs(myimages - image_mean) > 1. >>>> >>>> myimages.mask = new_mask >>>> >>>> #if you do a mean now it will ignore the values where the mask = True >>>> >>>> mean(myimages, axis=0) >>>> >>>> This will be all near C-speeds (I guess a factor of 100 is easily >>>> in there). >>>> ---- >>>> >>>> As other's have pointed out using i,j in a loop is a very bad idea >>>> for numpy >>>> arrays. Numpy arrays are much more easy to handle than in most other >>>> languages, there is a bit of getting used to required though. I >>>> recommend >>>> reviewing the different operations >>>> on http://www.scipy.org/Tentative_NumPy_Tutorial. >>>> >>>> Hope that helps, >>>> >>>> Wolfgang >>>> On 2012-03-07, at 4:41 AM, Sergio Pascual wrote: >>>> >>>> Hello >>>> >>>> I have written a image combine implementation for the pipeline of >>>> EMIR[1], a near infrared instrument for the 10m GTC Telescope. It >>>> does >>>> scaling, >>>> weighting and masking. It's written as a C/C++ extension. It's part >>>> of >>>> a larger package, numina, used for other GTC instruments, but I may >>>> split combine if there is interest in it. The package, called numina, >>>> its under heavy development, but the combine part is fairly stable. >>>> >>>> You can see the code here https://guaix.fis.ucm.es/hg/numina/ >>>> >>>> The combine part is the module numina.array.combine, fairly all the >>>> C/C++ code is in src/ >>>> >>>> Regards, Sergio >>>> >>>> >>>> [1] http://www.gtc.iac.es/pages/instrumentacion/emir.php >>>> [2] http://www.gtc.iac.es/ >>>> >>>> >>>> >>>> El d?a 6 de marzo de 2012 12:00, Jose Miguel Ib??ez >>>> >>>> escribi?: >>>> >>>> Hello everyone, >>>> >>>> >>>> does anyone know of an implementation of the iraf.imcombine task in >>>> >>>> python+numpy ? (of course, not using pyraf.imcombine call) >>>> >>>> >>>> >>>> Thanks ! >>>> >>>> Jose >>>> >>>> _______________________________________________ >>>> >>>> AstroPy mailing list >>>> >>>> AstroPy at scipy.org >>>> >>>> http://mail.scipy.org/mailman/listinfo/astropy >>>> >>>> >>>> >>>> >>>> -- >>>> Sergio Pascual http://guaix.fis.ucm.es/~spr +34 91 394 5018 >>>> gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC >>>> Departamento de Astrof?sica -- Universidad Complutense de Madrid >>>> (Spain) >>>> _______________________________________________ >>>> 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 >>>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From t_ribeiro at me.com Wed Mar 7 10:35:50 2012 From: t_ribeiro at me.com (Tiago Ribeiro de Souza) Date: Wed, 07 Mar 2012 12:35:50 -0300 Subject: [AstroPy] Image combine In-Reply-To: <54728433-CC43-4032-9E47-2D9B7E60DB81@gmail.com> References:

<79E82236-E34D-4733-91C9-FD9B67A8E1D3@gmail.com> <92863DF9-1BD9-41CF-847F-FC554D9287B6@stsci.edu> <63972524-48D2-4579-A4F6-91B90A2E534B@me.com> Message-ID: <77C20A81-200F-4D5E-96CA-A866B8FF18D4@astro.physik.uni-goettingen.de> On 7 Mar 2012, at 16:17, Perry Greenfield wrote: > Do you have any good example of code like this is successfully > distributed to users in the wild? So far, the dependencies on the > specific GPU hardware seem to make this impractical right now. But > maybe I'm missing something. > > And I'm also a bit confused by the first statement. Are you arguing > that we should be porting SPP to GPUs? I'd agree that optimisation is an important issue; enabling GPU is one part of that, classical parallelisation (multi-core/shared memory first) another part. But these are rather two sides of the medal; if the basic tasks are not available people will not be willing or even able to switch from IRAF or other suites. The best perspectives for speed-ups OTOH lie most likely in the underlying routines, i.e. for the most part the numpy core routines or even below (like the general-purpose numeric libraries numpy or scipy are calling), and that is where any optimisation effort is best spent - just my 2p. Cheers, Derek > On Mar 7, 2012, at 10:11 AM, Tiago Ribeiro de Souza wrote: > >> Hi guys, >> >> Even though I understand that people want to be free from using >> IRAF, I don't agree that only translating its basic functionality >> to other programming language is actually useful. If we ought to >> look to the future I would say that we should start an effort to >> provide a GPU-enabled suite of image reduction facility ratter than >> replicating existing code in different languages. Given the level of >> paralalization of image reduction (say image combine, subtraction, >> division, source extraction, spectral extraction and more!) GPU >> programming will definitively be much more important and useful. >> >> For those who are interested, check out this tutorial at http://www.macresearch.org/opencl >> and http://developer.nvidia.com/content/september-2009-opencl-public-downloads > From derek at astro.physik.uni-goettingen.de Wed Mar 7 10:52:07 2012 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Wed, 7 Mar 2012 16:52:07 +0100 Subject: [AstroPy] Image combine In-Reply-To: <3FCE4A89-1B3A-4D8D-A23C-30F56D3E4639@me.com> References:

Message-ID: On Wed, Mar 7, 2012 at 9:02 AM, Tiago Ribeiro de Souza wrote: > Certainly, there are a lot of things to consider. There is a rater interesting paper about this on astro-ph (http://arxiv.org/abs/1008.4623), if you are interested. Ted Kisner's talk at the Future of Astrocomputing conference from Dec 2010 addresses OpenCL in astronomy as well. In the video file he discusses many of the shortcomings and challenges more than comes across in the slides. http://hipacc.ucsc.edu/FOA_Program.html (with links to both PDF and MP4 files) > > Em 07/03/2012, ?s 12:52, Derek Homeier escreveu: > >> On 7 Mar 2012, at 16:35, Tiago Ribeiro de Souza wrote: >> >>> As far as I concern openCL is an attempt to provide a hardware-free sdk for GPU programming. ?I agree that it is still far from being user-friendly, though. I am also not aware of any astronomical code widely distributed but, the tutorial in macresearch shows an application used in chemistry (I guess) that uses openCL for scientific computation. At the same time, it seems to me that, once you write parallelized code in openCL it works both with CPU and GPUs in the same way. >> >> That's highly unlikely, since even within openCL I expect you have to consider the >> type of hardware available to you, e.g. standard graphics cards will only provide >> significant speed-up for single-precision data, while the newest Tesla models >> (or successors) have double-precision vector registers. You might be able to code >> routines for both cases and multi-threading over several CPU cores, but again, this >> is probably best done at a lower level, as I'd expect a lot of these tasks are quite >> generic for image data or any kind of large arrays in 2 or more D. >> For rather simple tasks like addition/subtraction/division one would probably also >> have to carefully weigh the gain in CPU/GPU power against the overhead for moving >> these large amounts of data around. >> >> Cheers, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Derek >> >> _______________________________________________ >> 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 From neilcrighton at gmail.com Wed Mar 7 11:11:38 2012 From: neilcrighton at gmail.com (Neil Crighton) Date: Wed, 7 Mar 2012 17:11:38 +0100 Subject: [AstroPy] Speed of numpy masked arrays Message-ID: Ah sorry, my mistake. I hadn't realised the .mean() method was pretty fast. numpy.ma.median() seems to be much slower than numpy.median(), though: In [35]: myimages = numpy.ma.MaskedArray(rand(5,100,100), rand(5, 100, 100) > .5) In [36]: %timeit np.ma.median(myimages, axis=0) 1 loops, best of 3: 2.33 s per loop In [37]: myimages = rand(5,100,100) In [38]: %timeit np.median(myimages, axis=0) 10 loops, best of 3: 1.4 ms per loop Cheers, Neil On 7 March 2012 14:52, Perry Greenfield wrote: > Hi Neil, > > That's a bit misleading. The application of the masking operation is > certainly done in C. The whole issue is how tightly integrated the masks are > with native arrays. For large arrays, it's not likely a significant speed > issue per se, but it is perhaps a memory issue (with consequent speed issues > if memory caches are involved). > > Perry > > > On Mar 7, 2012, at 8:45 AM, Neil Crighton wrote: > >> Hi Wolfgang, >> >> The problem is that masked arrays in numpy are not implemented in c, >> so they are not c-speed. ?There is a proposal to implement a masked >> array in c >> (https://github.com/numpy/numpy/blob/master/doc/neps/missing-data.rst) >> but this hasn't been finalised. >> >> Cheers, Neil >> >> >> On 7 March 2012 14:41, Wolfgang Kerzendorf wrote: >>> >>> Hello Jose, >>> >>> What you're trying to do is already half implemented in numpy and called >>> masked arrays: >>> >>> Let's say you want to stack images and you have put them together in a 3d >>> cube (first axis being the images): >>> >>> myimages = numpy.ma.MaskedArray(rand(5,100,100), >>> mask=zeros((5,100,100).astype(bool)) >>> >>> let's do a simple sigma clipping algorithm: >>> >>> image_mean = mean(myimages) >>> image_std = std(myimages) >>> >>> #now let's adjust the mask to mask the pixels that are more than 1 sigma >>> out >>> >>> new_mask = abs(myimages - image_mean) > 1. >>> >>> myimages.mask = new_mask >>> >>> #if you do a mean now it will ignore the values where the mask = True >>> >>> mean(myimages, axis=0) >>> >>> This will be all near C-speeds (I guess a factor of 100 is easily in >>> there). >>> ---- >>> >>> As other's have pointed out using i,j in a loop is a very bad idea for >>> numpy >>> arrays. Numpy arrays are much more easy to handle than in most other >>> languages, there is a bit of getting used to required though. I recommend >>> reviewing the different operations >>> on http://www.scipy.org/Tentative_NumPy_Tutorial. >>> >>> Hope that helps, >>> >>> ? ?Wolfgang >>> On 2012-03-07, at 4:41 AM, Sergio Pascual wrote: >>> >>> Hello >>> >>> I have written a image combine implementation for the pipeline of >>> EMIR[1], a near infrared instrument for the 10m GTC Telescope. It does >>> scaling, >>> weighting and masking. It's written as a C/C++ extension. It's part of >>> a larger package, numina, used for other GTC instruments, but I may >>> split combine if there is interest in it. The package, called numina, >>> its under heavy development, but the combine part is fairly stable. >>> >>> You can see the code here https://guaix.fis.ucm.es/hg/numina/ >>> >>> The combine part is the module numina.array.combine, fairly all the >>> C/C++ code is in src/ >>> >>> Regards, Sergio >>> >>> >>> [1] http://www.gtc.iac.es/pages/instrumentacion/emir.php >>> [2] http://www.gtc.iac.es/ >>> >>> >>> >>> El d?a 6 de marzo de 2012 12:00, Jose Miguel Ib??ez >>> escribi?: >>> >>> Hello everyone, >>> >>> >>> does anyone know of an implementation of the iraf.imcombine task in >>> >>> python+numpy ? (of course, not using pyraf.imcombine call) >>> >>> >>> >>> Thanks ! >>> >>> Jose >>> >>> _______________________________________________ >>> >>> AstroPy mailing list >>> >>> AstroPy at scipy.org >>> >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >>> >>> >>> >>> -- >>> Sergio Pascual ? ? http://guaix.fis.ucm.es/~spr ? ?+34 91 394 5018 >>> gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC >>> Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > From rays at blue-cove.com Wed Mar 7 13:21:53 2012 From: rays at blue-cove.com (RayS) Date: Wed, 07 Mar 2012 10:21:53 -0800 Subject: [AstroPy] Image combine In-Reply-To: References:

<79E82236-E34D-4733-91C9-FD9B67A8E1D3@gmail.com> <92863DF9-1BD9-41CF-847F-FC554D9287B6@stsci.edu> <63972524-48D2-4579-A4F6-91B90A2E534B@me.com> <54728433-CC43-4032-9E47-2D9B7E60DB81@gmail.com> <3FCE4A89-1B3A-4D8D-A23C-30F56D3E4639@me.com> Message-ID: <201203071821.q27ILsdW009556@blue-cove.com> FYI, I once tested pyCuda http://mathema.tician.de/software/pycuda for 1D and 2D FFT computations. I found that the crossover on a multi-core Tyan MB was ~4k N, below that, the (extra) bus transfer time exceeded the FFT speed-up. But, I would expect the speed advantage for large images to be significant, particularly FITS cubes where multiple operations are performed while the data stays in GPU memory. With faster, wider 64 bit bus break-even might be even lower - I should test on my new P6200 MB. Ray From vivienne.baldassare at gmail.com Tue Mar 13 15:24:19 2012 From: vivienne.baldassare at gmail.com (Vivienne Baldassare) Date: Tue, 13 Mar 2012 15:24:19 -0400 Subject: [AstroPy] Heliocentric Velocity Correction Message-ID: Is there a python function for calculating the heliocentric velocity correction? I found one called helcorr.py in the Astrolibpy library but am curious if there is another one worth considering. In particular, I noticed that the major observatories aren't in by default. If this is the only one, is it worth me improving this one? Best, Vivienne Baldassare -------------- next part -------------- An HTML attachment was scrubbed... URL: From sransom at nrao.edu Tue Mar 13 15:58:06 2012 From: sransom at nrao.edu (Scott Ransom) Date: Tue, 13 Mar 2012 15:58:06 -0400 Subject: [AstroPy] Heliocentric Velocity Correction In-Reply-To: References: Message-ID: <4F5FA6CE.6080603@nrao.edu> Hi Vivienne, There are heliocentric velocity routines which have many of the major observatories in pyslalib (which wraps the GPL'd version of SLALIB). See the sla_earth routine for a description (and for a way of getting even more accurate values). https://github.com/scottransom/pyslalib Scott PS: There is a _lot_ of other high-quality functionality in SLALIB (which is all wrapped by pyslalib) as well... On 03/13/2012 03:24 PM, Vivienne Baldassare wrote: > Is there a python function for calculating the heliocentric velocity > correction? I found one called helcorr.py in the Astrolibpy library but > am curious if there is another one worth considering. In particular, I > noticed that the major observatories aren't in by default. If this is > the only one, is it worth me improving this one? > > Best, > Vivienne Baldassare > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Scott M. Ransom Address: NRAO Phone: (434) 296-0320 520 Edgemont Rd. email: sransom at nrao.edu Charlottesville, VA 22903 USA GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 From d.berry at jach.hawaii.edu Tue Mar 13 16:16:07 2012 From: d.berry at jach.hawaii.edu (David Berry) Date: Tue, 13 Mar 2012 20:16:07 +0000 Subject: [AstroPy] Heliocentric Velocity Correction In-Reply-To: <4F5FA6CE.6080603@nrao.edu> References: <4F5FA6CE.6080603@nrao.edu> Message-ID: Pyast (http://dsberry.github.com/starlink/pyast.html) provides a wide range of facilities for handling spectral, celestial and time axes. This includes heliocentric velocity correction (amongst other things) for spectral axes. In particularly, see the "SpecFrame" class (http://www.starlink.ac.uk/docs/sun211.htx/node680.html#SpecFrame). If you create two SpecFrames with different properties (i.e. different standards of rest, units, geocentic observatory positions, etc), then the astConvert method (http://www.starlink.ac.uk/docs/sun211.htx/node245.html#xref_astConvert) can be used to get the transformation between them. David On 13 March 2012 19:58, Scott Ransom wrote: > Hi Vivienne, > > There are heliocentric velocity routines which have many of the major > observatories in pyslalib (which wraps the GPL'd version of SLALIB). > See the sla_earth routine for a description (and for a way of getting > even more accurate values). > > https://github.com/scottransom/pyslalib > > Scott > > PS: ?There is a _lot_ of other high-quality functionality in SLALIB > (which is all wrapped by pyslalib) as well... > > On 03/13/2012 03:24 PM, Vivienne Baldassare wrote: >> Is there a python function for calculating the heliocentric velocity >> correction? ?I found one called helcorr.py in the Astrolibpy library but >> am curious if there is another one worth considering. ?In particular, I >> noticed that the major observatories aren't in by default. ?If this is >> the only one, is it worth me improving this one? >> >> Best, >> Vivienne Baldassare >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > -- > Scott M. Ransom ? ? ? ? ? ?Address: ?NRAO > Phone: ?(434) 296-0320 ? ? ? ? ? ? ? 520 Edgemont Rd. > email: ?sransom at nrao.edu ? ? ? ? ? ? Charlottesville, VA 22903 USA > GPG Fingerprint: 06A9 9553 78BE 16DB 407B ?FFCA 9BFA B6FF FFD3 2989 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From indiajoe at gmail.com Wed Mar 14 10:13:48 2012 From: indiajoe at gmail.com (Joe Philip Ninan) Date: Wed, 14 Mar 2012 19:43:48 +0530 Subject: [AstroPy] Cross-Identification of stars in a collection of images Message-ID: Hi, Is there any python function to cross-identify the stars between different frames and calculate the coefficients of coordinate transformation equations? If not, i am planning to implement it by first running daofind using pyraf and then trying to match triangles; starting from brightest stars. Is there any better/easier way to do this? Thanking you, Joe -- /--------------------------------------------------------------- "GNU/Linux: because a PC is a terrible thing to waste" - GNU Generation ************************************************ Joe Philip Ninan http://sites.google.com/site/jpninan/ Research Scholar /________________\ DAA, | Vadakeparambil | TIFR, | Pullad P.O. | Mumbai-05, India. | Kerala, India | Ph: +917738438212 | PIN:689548 | ------------------------------\_______________/-------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From indiajoe at gmail.com Thu Mar 15 07:17:57 2012 From: indiajoe at gmail.com (Joe Philip Ninan) Date: Thu, 15 Mar 2012 16:47:57 +0530 Subject: [AstroPy] Cross-Identification of stars in a collection of images In-Reply-To: <35F338CA-0E9A-42AA-A881-6E7177B77AFF@sdsc.edu> References: <35F338CA-0E9A-42AA-A881-6E7177B77AFF@sdsc.edu> Message-ID: Hi, The blog[1] Richard mentioned seems to be dealing with matching the stars using their RA and Dec. Even the code mentioned in the last comment of the page seems to be for that. I was looking for a code which matches stars from frame to frame using their pixel coordinates. The http://astrometry.net suggested by Wolfgang does what i wanted. But as he suggested, i think i shall write a function in python itself to do that, so that we can use it for general purpose. I am planning to use the algorithm mentioned by Peter B. Stetson in his 'The Techniques of Least squares and stellar Photometry with CCDs' [2]. Thanking you all for suggestions, -cheers Joe [2] http://ned.ipac.caltech.edu/level5/Stetson/Stetson5_2.html On 14 March 2012 21:49, Richard P Wagner wrote: > Hi Joe, > > On Mar 14, 2012, at 7:13 AM, Joe Philip Ninan wrote: > > > Hi, > > Is there any python function to cross-identify the stars between > different frames and calculate the coefficients of coordinate > transformation equations? > > If not, i am planning to implement it by first running daofind using > pyraf and then trying to match triangles; starting from brightest stars. > > Is there any better/easier way to do this? > > Thanking you, > > Joe > > I don't tackle observational data myself, but I know that others work on > cross-matching regularly. You might find this AstroPython blog post a > useful starting point [1]. > > --Rick > > [1] > http://www.astropython.org/blog/2010/4/Question-Cross-matching-in-python > > > > > -- > > /--------------------------------------------------------------- > > "GNU/Linux: because a PC is a terrible thing to waste" - GNU Generation > > > > ************************************************ > > Joe Philip Ninan http://sites.google.com/site/jpninan/ > > Research Scholar /________________\ > > DAA, | Vadakeparambil | > > TIFR, | Pullad P.O. | > > Mumbai-05, India. | Kerala, India | > > Ph: +917738438212 | PIN:689548 | > > ------------------------------\_______________/-------------- > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > -- /--------------------------------------------------------------- "GNU/Linux: because a PC is a terrible thing to waste" - GNU Generation ************************************************ Joe Philip Ninan http://sites.google.com/site/jpninan/ Research Scholar /________________\ DAA, | Vadakeparambil | TIFR, | Pullad P.O. | Mumbai-05, India. | Kerala, India | Ph: +917738438212 | PIN:689548 | ------------------------------\_______________/-------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdl at astro.livjm.ac.uk Thu Mar 15 13:19:57 2012 From: jdl at astro.livjm.ac.uk (Joe Lyman) Date: Thu, 15 Mar 2012 17:19:57 +0000 Subject: [AstroPy] Cross-Identification of stars in a collection of images Message-ID: <4F6224BD.1010307@astro.livjm.ac.uk> Hi Joe, Not sure if this is what you're after, but check out `xyxymatch` in the immatch package of IRAF(/pyraf). This performs triangle matching of object lists (taken from daofind output for example) to create a matched list of coordinates (which can be input into geomap to compute the transformation and finally geotran to perform it). The source for xyxymatch may help you. Performs fairly well from my own experiences, even in the absence of an initial guess at the transformation. Cheers, Joe From indiajoe at gmail.com Thu Mar 15 15:05:01 2012 From: indiajoe at gmail.com (Joe Philip Ninan) Date: Fri, 16 Mar 2012 00:35:01 +0530 Subject: [AstroPy] Cross-Identification of stars in a collection of images In-Reply-To: <4F6224BD.1010307@astro.livjm.ac.uk> References: <4F6224BD.1010307@astro.livjm.ac.uk> Message-ID: Hi, Something like xyxymatch Joe Lyman mentioned was exactly what i was looking for. Thanks a lot. Warren Hack have send me link to its python version in stsci's irafx [1]. I had actually finished sketching the algorithm to implement triangle matching and was about to start coding. i shall code that some other time later. Right now xyxymatch meets my requirement. :-) Thanks a lot for the help. -Joe [1] http://stsdas.stsci.edu/irafx/ On 15 March 2012 22:49, Joe Lyman wrote: > Hi Joe, > > Not sure if this is what you're after, but check out `xyxymatch` in the > immatch package of IRAF(/pyraf). > > This performs triangle matching of object lists (taken from daofind output > for example) to create a matched list of coordinates (which can be input > into geomap to compute the transformation and finally geotran to perform > it). The source for xyxymatch may help you. > > Performs fairly well from my own experiences, even in the absence of an > initial guess at the transformation. > > Cheers, > Joe > -- /--------------------------------------------------------------- "GNU/Linux: because a PC is a terrible thing to waste" - GNU Generation ************************************************ Joe Philip Ninan http://sites.google.com/site/jpninan/ Research Scholar /________________\ DAA, | Vadakeparambil | TIFR, | Pullad P.O. | Mumbai-05, India. | Kerala, India | Ph: +917738438212 | PIN:689548 | ------------------------------\_______________/-------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jh at physics.ucf.edu Thu Mar 15 15:26:50 2012 From: jh at physics.ucf.edu (Joe Harrington) Date: Thu, 15 Mar 2012 15:26:50 -0400 Subject: [AstroPy] Cross-Identification of stars in a collection of images In-Reply-To: (astropy-request@scipy.org) Message-ID: You could also try something simpler, based on image morphing. Write the transformation matrix that scales, shifts, and rotates image 1 to mimic image 2. Calculate the reduced chi-squared between the images, possibly with a background offset. Put that into a function minimizer and solve for the elements of the transformation matrix as free parameters. You'll need an initial guess at the parameters that is pretty good, which you can get from manually matching a few stars. Then, use the fitted matrix to transform all the coordinates of the identified stars in image 1 to the coordinates of image 2. Clean those up if you need to by re-running your centering routine with those positions as initial guesses. It sounds complicated, but I'm betting it's a lot fewer calcs than the gigatriangles talked about in the page you cited (though I didn't read thoroughly, maybe there was a shortcut), and there may already be image morphing code that does the ugly part. Or, use an optical distortions code and fit for the polynomial coefficients. That would handle things like differential refraction, if these are ground-based images. A thornier problem is tracking features in pairs of mapped giant-planet images. There you use a full image-morphing routine to derive a fluid flow field between two images. If you have access to one of those (I don't), the star-matching problem seems like a relatively simple sub-case. Finally, some of our exoplanet transit survey friends might have a routine they are willing to share. --jh-- Date: Thu, 15 Mar 2012 16:47:57 +0530 From: Joe Philip Ninan Subject: Re: [AstroPy] Cross-Identification of stars in a collection of images To: Richard P Wagner , wkerzendorf at gmail.com Cc: astropy Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi, The blog[1] Richard mentioned seems to be dealing with matching the stars using their RA and Dec. Even the code mentioned in the last comment of the page seems to be for that. I was looking for a code which matches stars from frame to frame using their pixel coordinates. The http://astrometry.net suggested by Wolfgang does what i wanted. But as he suggested, i think i shall write a function in python itself to do that, so that we can use it for general purpose. I am planning to use the algorithm mentioned by Peter B. Stetson in his 'The Techniques of Least squares and stellar Photometry with CCDs' [2]. Thanking you all for suggestions, -cheers Joe [2] http://ned.ipac.caltech.edu/level5/Stetson/Stetson5_2.html On 14 March 2012 21:49, Richard P Wagner wrote: > Hi Joe, > > On Mar 14, 2012, at 7:13 AM, Joe Philip Ninan wrote: > > > Hi, > > Is there any python function to cross-identify the stars between > different frames and calculate the coefficients of coordinate > transformation equations? > > If not, i am planning to implement it by first running daofind using > pyraf and then trying to match triangles; starting from brightest stars. > > Is there any better/easier way to do this? > > Thanking you, > > Joe > > I don't tackle observational data myself, but I know that others work on > cross-matching regularly. You might find this AstroPython blog post a > useful starting point [1]. > > --Rick > > [1] > http://www.astropython.org/blog/2010/4/Question-Cross-matching-in-python From indiajoe at gmail.com Thu Mar 15 16:17:36 2012 From: indiajoe at gmail.com (Joe Philip Ninan) Date: Fri, 16 Mar 2012 01:47:36 +0530 Subject: [AstroPy] Cross-Identification of stars in a collection of images In-Reply-To: References: Message-ID: Hi Joe Harrington, Wouldn't using the entire image to calculate the transformation matrix using minimizing algorithms be a lot more time consuming? Especially when no initial guess is given. On the other hand, the triangulation method in the end requires to solve only 2 linear equations using the brightest (say 10) of the common star. Only sorting out the brightest stars from the daofind output will be time consuming. The solving for transformation coefficients by least squares is done by SVD, and it wouldn't take much time compared to sorting time. (Note: we are not using all the stars; only the brightest few to make all possible combinations of triangles. Number of equations is only equal to no# of stars used.) Anyway xyxymatch in stsci package solves my problem right now. -cheers Joe On 16 March 2012 00:56, Joe Harrington wrote: > You could also try something simpler, based on image morphing. Write > the transformation matrix that scales, shifts, and rotates image 1 to > mimic image 2. Calculate the reduced chi-squared between the images, > possibly with a background offset. Put that into a function minimizer > and solve for the elements of the transformation matrix as free > parameters. You'll need an initial guess at the parameters that is > pretty good, which you can get from manually matching a few stars. > > Then, use the fitted matrix to transform all the coordinates of the > identified stars in image 1 to the coordinates of image 2. Clean those > up if you need to by re-running your centering routine with those > positions as initial guesses. It sounds complicated, but I'm betting > it's a lot fewer calcs than the gigatriangles talked about in the page > you cited (though I didn't read thoroughly, maybe there was a shortcut), > and there may already be image morphing code that does the ugly part. > Or, use an optical distortions code and fit for the polynomial > coefficients. That would handle things like differential refraction, if > these are ground-based images. > > A thornier problem is tracking features in pairs of mapped giant-planet > images. There you use a full image-morphing routine to derive a fluid > flow field between two images. If you have access to one of those (I > don't), the star-matching problem seems like a relatively simple > sub-case. > > Finally, some of our exoplanet transit survey friends might have a > routine they are willing to share. > > --jh-- > > Date: Thu, 15 Mar 2012 16:47:57 +0530 > From: Joe Philip Ninan > Subject: Re: [AstroPy] Cross-Identification of stars in a collection > of images > To: Richard P Wagner , wkerzendorf at gmail.com > Cc: astropy > Message-ID: > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > The blog[1] Richard mentioned seems to be dealing with matching the stars > using their RA and Dec. > Even the code mentioned in the last comment of the page seems to be for > that. > I was looking for a code which matches stars from frame to frame using > their pixel coordinates. > The http://astrometry.net suggested by Wolfgang does what i wanted. > But as he suggested, i think i shall write a function in python itself to > do that, so that we can use it for general purpose. > I am planning to use the algorithm mentioned by Peter B. Stetson in his > 'The Techniques of Least squares and stellar Photometry with CCDs' [2]. > Thanking you all for suggestions, > -cheers > Joe > > [2] http://ned.ipac.caltech.edu/level5/Stetson/Stetson5_2.html > > > On 14 March 2012 21:49, Richard P Wagner wrote: > > > Hi Joe, > > > > On Mar 14, 2012, at 7:13 AM, Joe Philip Ninan wrote: > > > > > Hi, > > > Is there any python function to cross-identify the stars between > > different frames and calculate the coefficients of coordinate > > transformation equations? > > > If not, i am planning to implement it by first running daofind using > > pyraf and then trying to match triangles; starting from brightest stars. > > > Is there any better/easier way to do this? > > > Thanking you, > > > Joe > > > > I don't tackle observational data myself, but I know that others work on > > cross-matching regularly. You might find this AstroPython blog post a > > useful starting point [1]. > > > > --Rick > > > > [1] > > http://www.astropython.org/blog/2010/4/Question-Cross-matching-in-python > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- /--------------------------------------------------------------- "GNU/Linux: because a PC is a terrible thing to waste" - GNU Generation ************************************************ Joe Philip Ninan http://sites.google.com/site/jpninan/ Research Scholar /________________\ DAA, | Vadakeparambil | TIFR, | Pullad P.O. | Mumbai-05, India. | Kerala, India | Ph: +917738438212 | PIN:689548 | ------------------------------\_______________/-------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From magee at ucolick.org Thu Mar 15 16:45:57 2012 From: magee at ucolick.org (Daniel Magee) Date: Thu, 15 Mar 2012 13:45:57 -0700 Subject: [AstroPy] Cross-Identification of stars in a collection of images In-Reply-To: References: Message-ID: <4110BB32-4E44-434A-849E-7C15030929CB@ucolick.org> Hi Joe, While not python, I have found "match" to be useful and have used it in several pipelines to do image registration. http://spiff.rit.edu/match/ Cheers, Dan Dan Magee UCO/Lick Observatory http://www.ucolick.org/~magee magee at ucolick.org 831.459.5276 On Mar 14, 2012, at Mar 14 7:13 AM, Joe Philip Ninan wrote: > Hi, > Is there any python function to cross-identify the stars between different frames and calculate the coefficients of coordinate transformation equations? > If not, i am planning to implement it by first running daofind using pyraf and then trying to match triangles; starting from brightest stars. > Is there any better/easier way to do this? > Thanking you, > Joe > > -- > /--------------------------------------------------------------- > "GNU/Linux: because a PC is a terrible thing to waste" - GNU Generation > > ************************************************ > Joe Philip Ninan http://sites.google.com/site/jpninan/ > Research Scholar /________________\ > DAA, | Vadakeparambil | > TIFR, | Pullad P.O. | > Mumbai-05, India. | Kerala, India | > Ph: +917738438212 | PIN:689548 | > ------------------------------\_______________/-------------- > > !DSPAM:424,4f60a7b8215641294622181! _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > !DSPAM:424,4f60a7b8215641294622181! From jerome_caron_astro at ymail.com Thu Mar 15 16:47:29 2012 From: jerome_caron_astro at ymail.com (Jerome Caron) Date: Thu, 15 Mar 2012 20:47:29 +0000 (GMT) Subject: [AstroPy] aspylib library References: <35F338CA-0E9A-42AA-A881-6E7177B77AFF@sdsc.edu> Message-ID: <1331844449.60796.YahooMailNeo@web24603.mail.ird.yahoo.com> Dear list ? I would like to present a python library I am developing since 1.5 years for processing FITS images. It is called AsPyLib (www.aspylib.com) and?works on both Linux and Windows platforms. It allows to process FITS images for simple tasks (co-registration, co-addition, analysis..). There are also more elaborate functions or scripts for aperture photometry, specialised for short period variable stars and asteroids. ? For the programmers, it's a thin interface layer on top of Pyfits and Numpy-Scipy-Matplolib. All the computationally costly operations are coded in C and interfaced with ctypes. Parallel computation is used for long calculations. The code is simple (no classes, only modules, scripts and functions) to leave room for later evolutions and also allow others to understand it easily. ? At the moment the most mature part is the photometry script. It is used actively by a few amateur observers reporting asteroid lightcurves to R.Behrend (http://obswww.unige.ch/~behrend/page_cou.html). The script has been tested on several (~12) setups, from wide field images (teleobjective 200mm FL) to narrow fields (14'' telescope with 3.5m FL) and it performs quite well. The performance has been quite investigated, I can provide more details for those interested. ? Maybe this library can provide some answers to a few topics that have been discussed recently on the list (such as matching the stars between frames or co-addition with rejection of outliers). For those would are interested to use it as a starting point and modify it for your own needs, I can provide help by email. Just don't forget there's a GPL license on it, so that if you want to use it for a different project there are some restrictions.? The library is rapidly evolving. Feel free to give feedback, or maybe make comments or ask for help.Enjoy ! Best wishes Jerome Caron -------------- next part -------------- An HTML attachment was scrubbed... URL: From zonca at deepspace.ucsb.edu Thu Mar 15 16:51:56 2012 From: zonca at deepspace.ucsb.edu (Andrea Zonca) Date: Thu, 15 Mar 2012 13:51:56 -0700 Subject: [AstroPy] aspylib library In-Reply-To: <1331844449.60796.YahooMailNeo@web24603.mail.ird.yahoo.com> References: <35F338CA-0E9A-42AA-A881-6E7177B77AFF@sdsc.edu> <1331844449.60796.YahooMailNeo@web24603.mail.ird.yahoo.com> Message-ID: hi Jerome, it would be nice if you could upload the library to github, people can collaborate much more easily over there. cheers, andrea From thomas.robitaille at gmail.com Fri Mar 16 04:59:22 2012 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Fri, 16 Mar 2012 09:59:22 +0100 Subject: [AstroPy] APLpy 0.9.8 Release Message-ID: We are pleased to announce the release of APLpy 0.9.8, which includes many new features, bug fixes, and improvements. APLpy is a Python module that makes it easy to interactively produce publication-quality plots of astronomical images. Since 0.9.6, we've made extensive changes to the core APLpy code to allow us to support plotting of FITS files with arbitrary coordinates rather than just sky coordinates, and to also allow slicing of multi-dimensional data cubes. It is now very easy for example to make position-velocity plots from a 3D FITS cube. We now have a documentation page regarding arbitrary coordinate systems: http://aplpy.github.com/documentation/arbitrary_coordinate_systems.html as well as regarding slicing (in particular, check out the example): http://aplpy.github.com/documentation/slicing.html There are a number of other new features and bug fixes in this release, including minor ticks and the ability to initialize FITSFigure with Numpy arrays or FITS files with no WCS information. You can read about these and other changes in the following file: https://github.com/aplpy/aplpy/blob/master/CHANGES If you use pip or easy_install, you should now be able to update to 0.9.8. Note that if you are a Mac user, 0.9.8 is now available via MacPorts (you will need to type 'sudo port selfupdate' to see it). For more information on using MacPorts for Python, see: http://astrofrog.github.com/macports-python/ Please report any issues via GitHub: https://github.com/aplpy/aplpy/issues Cheers, The APLpy developers From thomas.robitaille at gmail.com Fri Mar 16 10:30:53 2012 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Fri, 16 Mar 2012 15:30:53 +0100 Subject: [AstroPy] Python packages in package managers Message-ID: <4A5A69A10E804238BFE05D7CCD055DAC@gmail.com> Hi, As some of you already know, I've been working on adding various Python packages for Astronomy to MacPorts, a package manager on Mac. I think that adding at least some of the Astronomy packages to package managers on various platforms will make it a lot easier in future for people to get a full Python installation on Mac and Linux without having to resort to e.g. EPD or other package bundles, so if you are interested, I would definitely encourage you to find out how you can help add packages to various other packages managers. I'm happy to help with MacPorts, but making sure the packages are up to date, etc. is already quite a bit to keep track of, and there are still many astronomy packages that have yet to be added, so I can't help add the packages to other package managers. It would be really great if other people could volunteer to help with other package managers! If you can maintain the package descriptions in a particular package manager, just reply to this thread to let other people know! Thanks, Tom From sergiopr at fis.ucm.es Fri Mar 16 12:34:49 2012 From: sergiopr at fis.ucm.es (Sergio Pascual) Date: Fri, 16 Mar 2012 17:34:49 +0100 Subject: [AstroPy] Python packages in package managers In-Reply-To: <4A5A69A10E804238BFE05D7CCD055DAC@gmail.com> References: <4A5A69A10E804238BFE05D7CCD055DAC@gmail.com> Message-ID: Hi, I maintain some Python Astronomy packages in Fedora (to name a few: pyfits, ATpy, asciitable...) If there are interested Fedorans in the audience, there is always some room to comaintain packages or swap reviews. Regards, Sergio 2012/3/16 Thomas Robitaille : > Hi, > > As some of you already know, I've been working on adding various Python packages for Astronomy to MacPorts, a package manager on Mac. I think that adding at least some of the Astronomy packages to package managers on various platforms will make it a lot easier in future for people to get a full Python installation on Mac and Linux without having to resort to e.g. EPD or other package bundles, so if you are interested, I would definitely encourage you to find out how you can help add packages to various other packages managers. > > I'm happy to help with MacPorts, but making sure the packages are up to date, etc. is already quite a bit to keep track of, and there are still many astronomy packages that have yet to be added, so I can't help add the packages to other package managers. It would be really great if other people could volunteer to help with other package managers! > > If you can maintain the package descriptions in a particular package manager, just reply to this thread to let other people know! > > Thanks, > Tom > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Sergio Pascual ? ? http://guaix.fis.ucm.es/~spr ? ?+34 91 394 5018 gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) From derek at astro.physik.uni-goettingen.de Fri Mar 16 13:15:04 2012 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Fri, 16 Mar 2012 18:15:04 +0100 Subject: [AstroPy] Python packages in package managers In-Reply-To: References: <4A5A69A10E804238BFE05D7CCD055DAC@gmail.com> Message-ID: Hi, On 16 Mar 2012, at 17:34, Sergio Pascual wrote: > I maintain some Python Astronomy packages in Fedora (to name a few: > pyfits, ATpy, asciitable...) If there are interested Fedorans in the > audience, there is always some room to comaintain packages or swap > reviews. I have created a couple of packages for fink, the other major Mac packaging system (also including asciitable and ATpy, pyfits is already part of the distribution); primarily for my personal use as I found the threshold of submitting them to the package tracker usually higher than creating/updating the actual package, but I can definitely push those if there is a wider interest. There are probably a couple other packages for which it would be similarly easy to create fink .debs, if the demand is there. Cheers, Derek From erik.tollerud at gmail.com Fri Mar 16 17:42:34 2012 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Fri, 16 Mar 2012 14:42:34 -0700 Subject: [AstroPy] Cross-Identification of stars in a collection of images In-Reply-To: References: Message-ID: Another useful resource that's actually build into scipy is the kdtree module (scipy.spatial.kdtree). It's not astronomy specific, but it's an efficient way to do nearest-neighbor searches in arbitrary coordinate spaces. So you can e.g. feed in the ra/dec of objects from the first image, and then use that to find nearest-neighbor (or nth nearest neighbor) of the second image. This is generally the way I do coordinate matching, because it's one of the most efficient spatial search algorithms out there. (Note that there's also a Cython version in scipy.spatial.ckdtree... it has the exact same interface, but it's compiled, so it's something like 10-100x faster, and possibly more memory-efficient.) It doesn't do any kind of transformations though - you'd have to figure that out based on the matches, I suppose. On Wed, Mar 14, 2012 at 7:13 AM, Joe Philip Ninan wrote: > Hi, > Is there any python function to cross-identify the stars between different > frames and calculate the coefficients of coordinate transformation > equations? > If not, i am planning to implement it by first running daofind using pyraf > and then trying to match triangles; starting from brightest stars. > Is there any better/easier way to do this? > Thanking you, > Joe > > -- > /--------------------------------------------------------------- > "GNU/Linux: because a PC is a terrible thing to waste" -? GNU Generation > > ************************************************ > Joe Philip Ninan? ? http://sites.google.com/site/jpninan/ > Research Scholar??????? /________________\ > DAA, ?????????????????????????? | Vadakeparambil | > TIFR,?????????????????????????? | Pullad P.O.???????? | > Mumbai-05, India. ???? | Kerala, India????? | > Ph: +917738438212?? | PIN:689548?????? | > ------------------------------\_______________/-------------- > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Erik Tollerud From thomas.robitaille at gmail.com Mon Mar 19 05:43:39 2012 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Mon, 19 Mar 2012 10:43:39 +0100 Subject: [AstroPy] Astropy website/logo competition! In-Reply-To: References: Message-ID: Hi everyone, Just a quick reminder that submissions for the Astropy website design competition are due by March 31st - we look forward to your submissions! Cheers, Tom On 26 January 2012 10:01, Thomas Robitaille wrote: > Hi everyone, > > We are holding a design competition for the http://www.astropy.org > website and logo! There is a prize of a $50 (or equivalent) Amazon > Voucher for the winner, and the deadline for submissions is March 31st > 2012. Instructions and guidelines can be found at the following page: > > http://github.com/astropy/astropy/wiki/Website-logo-competition > > Please let us know if you have any questions. We look forward to your > submissions! > > Cheers, > Tom From astropy at liska.ath.cx Wed Mar 21 06:01:54 2012 From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher) Date: Wed, 21 Mar 2012 11:01:54 +0100 Subject: [AstroPy] Python packages in package managers References: <4A5A69A10E804238BFE05D7CCD055DAC@gmail.com> Message-ID: Hi Thomas, Thomas Robitaille writes: > I'm happy to help with MacPorts, but making sure the packages are up > to date, etc. is already quite a bit to keep track of, and there are > still many astronomy packages that have yet to be added, so I can't > help add the packages to other package managers. It would be really > great if other people could volunteer to help with other package > managers! I am maintaining a few astronomy packages for Debian; in the Python world this is mainly pywcs and python-cpl. I would add other packages when I need them myself, or if someone expresses some interest in having a certain python package available in Debian and Ubuntu. Cheers Ole From kellecruz at gmail.com Wed Mar 21 09:49:14 2012 From: kellecruz at gmail.com (Kelle Cruz) Date: Wed, 21 Mar 2012 09:49:14 -0400 Subject: [AstroPy] Heliocentric Velocity Correction In-Reply-To: References: <4F5FA6CE.6080603@nrao.edu> Message-ID: Thanks so much for the responses to Vivienne's (my student) question about heliocentric velocity. However, none of these packages were very user friendly and we ended up just going with IRAF's rvcorrect: http://stsdas.stsci.edu/cgi-bin/gethelp.cgi?rvcorrect I hope the eventual astropy has something more straightforward, or at least better documented with examples. kelle On Tue, Mar 13, 2012 at 4:16 PM, David Berry wrote: > Pyast (http://dsberry.github.com/starlink/pyast.html) provides a wide > range of facilities for handling spectral, celestial and time axes. > This includes heliocentric velocity correction (amongst other things) > for spectral axes. In particularly, see the "SpecFrame" class > (http://www.starlink.ac.uk/docs/sun211.htx/node680.html#SpecFrame). If > you create two SpecFrames with different properties (i.e. different > standards of rest, units, geocentic observatory positions, etc), then > the astConvert method > (http://www.starlink.ac.uk/docs/sun211.htx/node245.html#xref_astConvert) > can be used to get the transformation between them. > > David > > > On 13 March 2012 19:58, Scott Ransom wrote: > > Hi Vivienne, > > > > There are heliocentric velocity routines which have many of the major > > observatories in pyslalib (which wraps the GPL'd version of SLALIB). > > See the sla_earth routine for a description (and for a way of getting > > even more accurate values). > > > > https://github.com/scottransom/pyslalib > > > > Scott > > > > PS: There is a _lot_ of other high-quality functionality in SLALIB > > (which is all wrapped by pyslalib) as well... > > > > On 03/13/2012 03:24 PM, Vivienne Baldassare wrote: > >> Is there a python function for calculating the heliocentric velocity > >> correction? I found one called helcorr.py in the Astrolibpy library but > >> am curious if there is another one worth considering. In particular, I > >> noticed that the major observatories aren't in by default. If this is > >> the only one, is it worth me improving this one? > >> > >> Best, > >> Vivienne Baldassare > >> > >> > >> _______________________________________________ > >> AstroPy mailing list > >> AstroPy at scipy.org > >> http://mail.scipy.org/mailman/listinfo/astropy > > > > -- > > Scott M. Ransom Address: NRAO > > Phone: (434) 296-0320 520 Edgemont Rd. > > email: sransom at nrao.edu Charlottesville, VA 22903 USA > > GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 > > _______________________________________________ > > 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 > -- Kelle Cruz, PhD ? http://kellecruz.com/ 917.725.1334 ? Hunter ext: 16486 ? AMNH ext: 3404 -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.berry at jach.hawaii.edu Wed Mar 21 10:21:16 2012 From: d.berry at jach.hawaii.edu (David Berry) Date: Wed, 21 Mar 2012 14:21:16 +0000 Subject: [AstroPy] Heliocentric Velocity Correction In-Reply-To: References: <4F5FA6CE.6080603@nrao.edu>

Message-ID: On 21 March 2012 13:49, Kelle Cruz wrote: > Thanks so much for the responses to Vivienne's (my student) question about > heliocentric velocity. > > However, none of these packages were very user friendly and we ended up just > going with IRAF's > rvcorrect:?http://stsdas.stsci.edu/cgi-bin/gethelp.cgi?rvcorrect > > I hope the eventual astropy has something more straightforward, or at least > better documented with examples. By design, both AST and SLALIB are at the level of infrastructure libraries rather than user applications. David From embray at stsci.edu Wed Mar 21 11:01:50 2012 From: embray at stsci.edu (Erik Bray) Date: Wed, 21 Mar 2012 11:01:50 -0400 Subject: [AstroPy] Python packages in package managers In-Reply-To: References: <4A5A69A10E804238BFE05D7CCD055DAC@gmail.com> Message-ID: <4F69ED5E.8030406@stsci.edu> On 03/21/2012 06:01 AM, Ol? Streicher wrote: > Hi Thomas, > > Thomas Robitaille writes: >> I'm happy to help with MacPorts, but making sure the packages are up >> to date, etc. is already quite a bit to keep track of, and there are >> still many astronomy packages that have yet to be added, so I can't >> help add the packages to other package managers. It would be really >> great if other people could volunteer to help with other package >> managers! > > I am maintaining a few astronomy packages for Debian; in the Python > world this is mainly pywcs and python-cpl. I would add other packages > when I need them myself, or if someone expresses some interest in > having a certain python package available in Debian and Ubuntu. > > Cheers > > Ole I'll gladly serve as a backup for any Debian or Ubuntu packaging too. From erik.tollerud at gmail.com Wed Mar 21 20:46:08 2012 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 21 Mar 2012 17:46:08 -0700 Subject: [AstroPy] Heliocentric Velocity Correction In-Reply-To: References: <4F5FA6CE.6080603@nrao.edu>

Message-ID: FYI this is definitely something that is quite high on the priority list for the upcoming astropy.coords package, as it has a quite natural connection to the solar system models that are necessary for some of the coordinate transforms. On Wed, Mar 21, 2012 at 6:49 AM, Kelle Cruz wrote: > Thanks so much for the responses to Vivienne's (my student) question about > heliocentric velocity. > > However, none of these packages were very user friendly and we ended up just > going with IRAF's > rvcorrect:?http://stsdas.stsci.edu/cgi-bin/gethelp.cgi?rvcorrect > > I hope the eventual astropy has something more straightforward, or at least > better documented with examples. > > kelle > > On Tue, Mar 13, 2012 at 4:16 PM, David Berry > wrote: >> >> Pyast (http://dsberry.github.com/starlink/pyast.html) provides a wide >> range of facilities for handling spectral, celestial and time axes. >> This includes heliocentric velocity correction (amongst other things) >> for spectral axes. In particularly, see the "SpecFrame" class >> (http://www.starlink.ac.uk/docs/sun211.htx/node680.html#SpecFrame). If >> you create two SpecFrames with different properties (i.e. different >> standards of rest, units, geocentic observatory positions, etc), then >> the astConvert method >> (http://www.starlink.ac.uk/docs/sun211.htx/node245.html#xref_astConvert) >> can be used to get the transformation between them. >> >> David >> >> >> On 13 March 2012 19:58, Scott Ransom wrote: >> > Hi Vivienne, >> > >> > There are heliocentric velocity routines which have many of the major >> > observatories in pyslalib (which wraps the GPL'd version of SLALIB). >> > See the sla_earth routine for a description (and for a way of getting >> > even more accurate values). >> > >> > https://github.com/scottransom/pyslalib >> > >> > Scott >> > >> > PS: ?There is a _lot_ of other high-quality functionality in SLALIB >> > (which is all wrapped by pyslalib) as well... >> > >> > On 03/13/2012 03:24 PM, Vivienne Baldassare wrote: >> >> Is there a python function for calculating the heliocentric velocity >> >> correction? ?I found one called helcorr.py in the Astrolibpy library >> >> but >> >> am curious if there is another one worth considering. ?In particular, I >> >> noticed that the major observatories aren't in by default. ?If this is >> >> the only one, is it worth me improving this one? >> >> >> >> Best, >> >> Vivienne Baldassare >> >> >> >> >> >> _______________________________________________ >> >> AstroPy mailing list >> >> AstroPy at scipy.org >> >> http://mail.scipy.org/mailman/listinfo/astropy >> > >> > -- >> > Scott M. Ransom ? ? ? ? ? ?Address: ?NRAO >> > Phone: ?(434) 296-0320 ? ? ? ? ? ? ? 520 Edgemont Rd. >> > email: ?sransom at nrao.edu ? ? ? ? ? ? Charlottesville, VA 22903 USA >> > GPG Fingerprint: 06A9 9553 78BE 16DB 407B ?FFCA 9BFA B6FF FFD3 2989 >> > _______________________________________________ >> > 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 > > > > > -- > Kelle Cruz, PhD ??http://kellecruz.com/ > 917.725.1334 ??Hunter ext: 16486 ? AMNH ext: 3404 > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Erik Tollerud From jturner at gemini.edu Wed Mar 28 14:36:19 2012 From: jturner at gemini.edu (James Turner) Date: Wed, 28 Mar 2012 15:36:19 -0300 Subject: [AstroPy] SciPy 2012 Message-ID: <4F735A23.9040402@gemini.edu> Hi everyone, I'm just wondering who is thinking of attending SciPy in Austin this July 16-21: http://conference.scipy.org/scipy2012/ I've been asked by the organizers to help out, but am just figuring out what my plans are, since it clashes with a couple of things. If there's enough interest, I would propose an AstroPy sprint during the last couple of days, where people (including me) can get started contributing and focus on one or two areas of missing functionality, compared with eg. IRAF or IDL. I gather the next AstroPy co-ordination meeting is likely to happen separately elsewhere, due to people's limited availability during the conference season, but SciPy is a good venue for wider exposure and for participants to learn about other Python tools (eg. NumPy, Matplotlib, GPU libraries, symbolic mathematics, you name it...). Cheers, James. From embray at stsci.edu Wed Mar 28 14:53:54 2012 From: embray at stsci.edu (Erik Bray) Date: Wed, 28 Mar 2012 14:53:54 -0400 Subject: [AstroPy] SciPy 2012 In-Reply-To: <4F735A23.9040402@gemini.edu> References: <4F735A23.9040402@gemini.edu> Message-ID: <4F735E42.3040601@stsci.edu> On 03/28/2012 02:36 PM, James Turner wrote: > Hi everyone, > > I'm just wondering who is thinking of attending SciPy in Austin this > July 16-21: > > http://conference.scipy.org/scipy2012/ > > I've been asked by the organizers to help out, but am just figuring out > what my plans are, since it clashes with a couple of things. If there's > enough interest, I would propose an AstroPy sprint during the last > couple of days, where people (including me) can get started contributing > and focus on one or two areas of missing functionality, compared with > eg. IRAF or IDL. > > I gather the next AstroPy co-ordination meeting is likely to happen > separately elsewhere, due to people's limited availability during the > conference season, but SciPy is a good venue for wider exposure and for > participants to learn about other Python tools (eg. NumPy, Matplotlib, > GPU libraries, symbolic mathematics, you name it...). > > Cheers, > > James. I'm probably going to hold off until I see what tutorials get accepted--the tutorials were kind of the highlight of SciPy for me last year. I don't recall getting too much out of the talks. Not that there was anything wrong with them, or that there weren't some very interesting ones. Just that there were only a handful I felt that I took much away from that's of immediate use to me. But that's just me. That said, I don't mean to sound down on SciPy. And an Astropy sprint would be a great incentive. I can't believe it's already been nearly a year since last time... Erik From klabrie at gemini.edu Wed Mar 28 16:08:32 2012 From: klabrie at gemini.edu (Kathleen Labrie) Date: Wed, 28 Mar 2012 10:08:32 -1000 Subject: [AstroPy] SciPy 2012 In-Reply-To: <4F735E42.3040601@stsci.edu> References: <4F735A23.9040402@gemini.edu> <4F735E42.3040601@stsci.edu> Message-ID: <7A4B46B9-EB3E-4A16-8B0A-014BCA4B825C@gemini.edu> On a side note, is it time for an AstroPy BoF at ADASS? Kathleen On Mar 28, 2012, at 8:53 AM, Erik Bray wrote: > On 03/28/2012 02:36 PM, James Turner wrote: >> Hi everyone, >> >> I'm just wondering who is thinking of attending SciPy in Austin this >> July 16-21: >> >> http://conference.scipy.org/scipy2012/ >> >> I've been asked by the organizers to help out, but am just figuring out >> what my plans are, since it clashes with a couple of things. If there's >> enough interest, I would propose an AstroPy sprint during the last >> couple of days, where people (including me) can get started contributing >> and focus on one or two areas of missing functionality, compared with >> eg. IRAF or IDL. >> >> I gather the next AstroPy co-ordination meeting is likely to happen >> separately elsewhere, due to people's limited availability during the >> conference season, but SciPy is a good venue for wider exposure and for >> participants to learn about other Python tools (eg. NumPy, Matplotlib, >> GPU libraries, symbolic mathematics, you name it...). >> >> Cheers, >> >> James. > > I'm probably going to hold off until I see what tutorials get > accepted--the tutorials were kind of the highlight of SciPy for me last > year. I don't recall getting too much out of the talks. Not that there > was anything wrong with them, or that there weren't some very > interesting ones. Just that there were only a handful I felt that I took > much away from that's of immediate use to me. But that's just me. > > That said, I don't mean to sound down on SciPy. And an Astropy sprint > would be a great incentive. I can't believe it's already been nearly a > year since last time... > > Erik > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From klabrie at gemini.edu Wed Mar 28 16:42:47 2012 From: klabrie at gemini.edu (Kathleen Labrie) Date: Wed, 28 Mar 2012 10:42:47 -1000 Subject: [AstroPy] SciPy 2012 In-Reply-To: <86EF99759C1D44CF810D5CB9401CB26B@gmail.com> References: <4F735A23.9040402@gemini.edu> <4F735E42.3040601@stsci.edu> <13336_1332965343_4F736FDF_13336_4279_1_7A4B46B9-EB3E-4A16-8B0A-014BCA4B825C@gemini.edu> <86EF99759C1D44CF810D5CB9401CB26B@gmail.com> Message-ID: <203EB936-EE56-4BE8-8CBD-43F5FAD51956@gemini.edu> :) BoF = birds of a feather, ie. some sort of break out session. ADASS = Astronomical Data Analysis Software and Systems. It's a yearly conference. Kathleen On Mar 28, 2012, at 10:12 AM, Andy Casey wrote: > Somebody's going to have to spell out those acronyms to me. > > Cheers, > Andy > On Wednesday, 28 March 2012 at 9:08 PM, Kathleen Labrie wrote: > >> On a side note, is it time for an AstroPy BoF at ADASS? >> >> Kathleen >> >> On Mar 28, 2012, at 8:53 AM, Erik Bray wrote: >> >>> On 03/28/2012 02:36 PM, James Turner wrote: >>>> Hi everyone, >>>> >>>> I'm just wondering who is thinking of attending SciPy in Austin this >>>> July 16-21: >>>> >>>> http://conference.scipy.org/scipy2012/ >>>> >>>> I've been asked by the organizers to help out, but am just figuring out >>>> what my plans are, since it clashes with a couple of things. If there's >>>> enough interest, I would propose an AstroPy sprint during the last >>>> couple of days, where people (including me) can get started contributing >>>> and focus on one or two areas of missing functionality, compared with >>>> eg. IRAF or IDL. >>>> >>>> I gather the next AstroPy co-ordination meeting is likely to happen >>>> separately elsewhere, due to people's limited availability during the >>>> conference season, but SciPy is a good venue for wider exposure and for >>>> participants to learn about other Python tools (eg. NumPy, Matplotlib, >>>> GPU libraries, symbolic mathematics, you name it...). >>>> >>>> Cheers, >>>> >>>> James. >>> >>> I'm probably going to hold off until I see what tutorials get >>> accepted--the tutorials were kind of the highlight of SciPy for me last >>> year. I don't recall getting too much out of the talks. Not that there >>> was anything wrong with them, or that there weren't some very >>> interesting ones. Just that there were only a handful I felt that I took >>> much away from that's of immediate use to me. But that's just me. >>> >>> That said, I don't mean to sound down on SciPy. And an Astropy sprint >>> would be a great incentive. I can't believe it's already been nearly a >>> year since last time... >>> >>> Erik >>> _______________________________________________ >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldcroft at head.cfa.harvard.edu Wed Mar 28 20:04:33 2012 From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft) Date: Wed, 28 Mar 2012 20:04:33 -0400 Subject: [AstroPy] AstroPy meeting? WAS: SciPy 2012 Message-ID: I agree with Erik here about SciPy, and I might have blown my conference (time) budget already with PyCon. That said, I'm having trouble making enough time for AstroPy so a dedicated meeting and sprint might be welcome. We had talked about a followup meeting, perhaps at STSci? - Tom p.s. Didn't want to hijack the original thread so I renamed it here. On Wed, Mar 28, 2012 at 2:53 PM, Erik Bray wrote: > On 03/28/2012 02:36 PM, James Turner wrote: >> Hi everyone, >> >> I'm just wondering who is thinking of attending SciPy in Austin this >> July 16-21: >> >> ? ? http://conference.scipy.org/scipy2012/ >> >> I've been asked by the organizers to help out, but am just figuring out >> what my plans are, since it clashes with a couple of things. If there's >> enough interest, I would propose an AstroPy sprint during the last >> couple of days, where people (including me) can get started contributing >> and focus on one or two areas of missing functionality, compared with >> eg. IRAF or IDL. >> >> I gather the next AstroPy co-ordination meeting is likely to happen >> separately elsewhere, due to people's limited availability during the >> conference season, but SciPy is a good venue for wider exposure and for >> participants to learn about other Python tools (eg. NumPy, Matplotlib, >> GPU libraries, symbolic mathematics, you name it...). >> >> Cheers, >> >> James. > > I'm probably going to hold off until I see what tutorials get > accepted--the tutorials were kind of the highlight of SciPy for me last > year. ?I don't recall getting too much out of the talks. ?Not that there > was anything wrong with them, or that there weren't some very > interesting ones. Just that there were only a handful I felt that I took > much away from that's of immediate use to me. ?But that's just me. > > That said, I don't mean to sound down on SciPy. And an Astropy sprint > would be a great incentive. ?I can't believe it's already been nearly a > year since last time... > > Erik > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From erik.tollerud at gmail.com Wed Mar 28 21:44:53 2012 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 28 Mar 2012 18:44:53 -0700 Subject: [AstroPy] AstroPy meeting? WAS: SciPy 2012 In-Reply-To: References: Message-ID: Yes, another coordination meeting is definitely in the plans, tentatively at STScI - we were considering summer, but I think we may be tilting in the direction of pushing until fall again (to avoid the summer science conference season). A suggestion for the interim (from Tom R): videoconference coordination meetings (most likely google+ hangouts) every couple months or so? We might also consider "virtual sprints," either with the videocons or smaller sprints that we might schedule at SciPy or elsewhere. On Wed, Mar 28, 2012 at 5:04 PM, Tom Aldcroft wrote: > I agree with Erik here about SciPy, and I might have blown my > conference (time) budget already with PyCon. ?That said, I'm having > trouble making enough time for AstroPy so a dedicated meeting and > sprint might be welcome. ?We had talked about a followup meeting, > perhaps at STSci? > > - Tom > > p.s. Didn't want to hijack the original thread so I renamed it here. > > On Wed, Mar 28, 2012 at 2:53 PM, Erik Bray wrote: >> On 03/28/2012 02:36 PM, James Turner wrote: >>> Hi everyone, >>> >>> I'm just wondering who is thinking of attending SciPy in Austin this >>> July 16-21: >>> >>> ? ? http://conference.scipy.org/scipy2012/ >>> >>> I've been asked by the organizers to help out, but am just figuring out >>> what my plans are, since it clashes with a couple of things. If there's >>> enough interest, I would propose an AstroPy sprint during the last >>> couple of days, where people (including me) can get started contributing >>> and focus on one or two areas of missing functionality, compared with >>> eg. IRAF or IDL. >>> >>> I gather the next AstroPy co-ordination meeting is likely to happen >>> separately elsewhere, due to people's limited availability during the >>> conference season, but SciPy is a good venue for wider exposure and for >>> participants to learn about other Python tools (eg. NumPy, Matplotlib, >>> GPU libraries, symbolic mathematics, you name it...). >>> >>> Cheers, >>> >>> James. >> >> I'm probably going to hold off until I see what tutorials get >> accepted--the tutorials were kind of the highlight of SciPy for me last >> year. ?I don't recall getting too much out of the talks. ?Not that there >> was anything wrong with them, or that there weren't some very >> interesting ones. Just that there were only a handful I felt that I took >> much away from that's of immediate use to me. ?But that's just me. >> >> That said, I don't mean to sound down on SciPy. And an Astropy sprint >> would be a great incentive. ?I can't believe it's already been nearly a >> year since last time... >> >> Erik >> _______________________________________________ >> 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 -- Erik Tollerud From brandon at rhodesmill.org Fri Mar 30 12:30:36 2012 From: brandon at rhodesmill.org (Brandon Craig Rhodes) Date: Fri, 30 Mar 2012 12:30:36 -0400 Subject: [AstroPy] "jplephem" - first step towards pure-Python "PyEphem" Message-ID: <877gy2aw5v.fsf@asaph.rhodesmill.org> I hope that this does not dreadfully duplicate anyone else's work. I have just released five of the major JPL ephemerides as Python packages. As long as you have NumPy installed, you can now run a pair of commands like: pip install jplephem pip install de423 Then you can write scripts like this: import de423 from jplephem import Ephemeris e = Ephemeris(de423) jed = 2444391.5 # 1980.06.01 print e.compute('mars', jed) The "jplephem" package is just a first step, and its API is currently quite primitive (it consists only of the compute() function you've just seen). Conversations at PyCon about "PyEphem" this year made it clear that users would like finer-grained control over its solar system operations than are currently possible today, since all of the actual computation is bundled into C-language routines. While the last decade of being a wrapper around XEphem's "libastro" saved me a lot of work, it now seems time - especially with PyPy poised to absorb much of the performance penalty of doing math in Python for those who need unusual speed - for me to think about finally re-implementing the astronomy routines in Python for easier maintenance and better user access to internals. This "jplephem" package is a first step towards a pure-Python replacement for the C internals of "PyEphem". Next, I want to add routines that let the JPL's x/y/z coordinates be turned into more traditional Earth-observer numbers like RA and dec. Are there already astronomy routines like that lying around? I am still learning the ecosystem that "libastro" hopes to unify! My github repository for this "jplephem" experiment is here: https://github.com/brandon-rhodes/jplephem -- Brandon Craig Rhodes brandon at rhodesmill.org http://rhodesmill.org/brandon From brandon at rhodesmill.org Fri Mar 30 12:49:01 2012 From: brandon at rhodesmill.org (Brandon Craig Rhodes) Date: Fri, 30 Mar 2012 12:49:01 -0400 Subject: [AstroPy] "jplephem" - first step towards pure-Python "PyEphem" In-Reply-To: <877gy2aw5v.fsf@asaph.rhodesmill.org> (Brandon Craig Rhodes's message of "Fri, 30 Mar 2012 12:30:36 -0400") References: <877gy2aw5v.fsf@asaph.rhodesmill.org> Message-ID: <87398qavb6.fsf@asaph.rhodesmill.org> Well, drat, it looks like I spoke too soon! DE421 is now available on PyPI, but PyPI is refusing my uploads of the other data sets - perhaps because of the archive size? I will have to ask the PyPI folks about it this evening and see if I can get the limit raised. -- Brandon Craig Rhodes brandon at rhodesmill.org http://rhodesmill.org/brandon