From stefano.covino at brera.inaf.it Mon Aug 2 03:37:09 2010 From: stefano.covino at brera.inaf.it (Stefano Covino) Date: Mon, 2 Aug 2010 09:37:09 +0200 Subject: [AstroPy] Summer scholar Message-ID: Hello everybody, actually, I feel a bit out of place since my programming skills are definitely limited compared to most, in not all, people writing to this list. Actually, I have so far mainly developed a set of tools which I have shared with my research team and my only goal was to make easier operations which could be performed in many other ways (http://www.merate.mi.astro.it/utenti/covino/usermanual.html). Actually, one of the problems I have to solve more often, is to efficiently match objects (entries) in different tables, usually tables retrieved from databases and so on. Time ago I had to develop a tool to derive the roto-translation solution for a set of different scientific frames with reference to a chosen image, and I applied a triangle match algorithm. It works very well, although I develop it following a sort of "quick and dirty" strategy. I think that the idea to develop and eventually distribute a pure python library able to match tables with or without hierarchical parameters (i.e. magnitude, flux, etc.) could be a good project for a set of still unexperienced programmers. Something, indeed, probably useful by itself. Cheers, Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From superluminique at gmail.com Tue Aug 3 00:04:37 2010 From: superluminique at gmail.com (Rene Breton) Date: Tue, 3 Aug 2010 00:04:37 -0400 Subject: [AstroPy] Summer scholar In-Reply-To: References: Message-ID: <17371E6A-230E-4B3C-8977-115C0041E03B@gmail.com> Hi everyone, Thanks for sharing your tips/library Stefano. Indeed a matching routine would be very nice to have so people should definitely aim to have something that makes use of several criteria such as distance and magnitude (in a more generic way). The Groth/Stetson algorithm seems very good but maybe yours is similar or can do better. Worse case, both can be put in under different names a little bit like the different root finding algorithms in scipy.optimize. You can never have enough algorithms to get around pathological problems. Now, regarding Wolfgang's post, I very much agree with his ideas. I have to say that I've already implemented the "find" from "find.pro" in IDL's astrolib, which works really well in order to identify point sources. At the same time, I've modernized the program so that it takes advantage of numpy's array algebra, hence there are no slow "for loops". Maybe other algorithms could be worked out but this one certainly works well and it would be a shame to re-invent the wheel and have someone redo it. I think it should have been committed in the "pyastrolib" project that I was part of. If not, I'm very happy to add it here. I'm also not very far from having a re-brewed "aper" function working, from "aper.pro" in IDL's astrolib but there are a couple of function dependencies that I haven't had try to code. So maybe the students could start from there in their coding. Here are two ideas that I'd like to throw in for the student project, but they also apply in a more general way: 1. IDL's astrolib is a good start. The phot/daophot stuff from IDL's astrolib is generally pretty good, though it would gain to be modernized (and make use of array operations for instance). Since IDL and python are arguably similar, it would probably be not too difficult for someone with minimal experience to port some IDL code to python. Then one can optimize it. 2. Working on new photometry algorithms. Despite students may have limited programming background, they might be clever physicists. There are different algorithm using maximum entropy and such that can try to optimized the number of fitted sources. Among other interesting things would be algorithms/functions to derive photometric upper limits. This is what annoys me most and IDL's astrolib totally misses it. For PSF photometry, a routine that adds fake stars and tries to retrieve their flux in order to asses upper limits would be awesome. Something should also be done for aperture photometry. Cheers, Rene From jslavin at cfa.harvard.edu Tue Aug 3 14:01:08 2010 From: jslavin at cfa.harvard.edu (Jonathan Slavin) Date: Tue, 03 Aug 2010 14:01:08 -0400 Subject: [AstroPy] Summer scholar In-Reply-To: References: Message-ID: <1280858468.20684.13.camel@shevek> One thing that I'd like (don't know if a summer student could do it) is to improve on the multidimensional filtering/smoothing in scipy. We had some discussions about this a little while back. Specifically the ndimage.filters.uniform_filter and others in that module are implemented in multiple dimensions via a series of 1-D filters in each dimension -- which is not the same as a truly multi-dimensional filter. Maybe this is not something there is much interest in, though anyone who wants to remove some noise in a 2-D image might be interested. Jon Slavin On Tue, 2010-08-03 at 12:00 -0500, astropy-request at scipy.org wrote: > Message: 1 > Date: Tue, 3 Aug 2010 00:04:37 -0400 > From: Rene Breton > Subject: Re: [AstroPy] Summer scholar > To: astropy at scipy.org > Message-ID: <17371E6A-230E-4B3C-8977-115C0041E03B at gmail.com> > Content-Type: text/plain; charset=us-ascii > > Hi everyone, > > > Thanks for sharing your tips/library Stefano. Indeed a matching > routine would be very nice to have so people should definitely aim to > have something that makes use of several criteria such as distance and > magnitude (in a more generic way). The Groth/Stetson algorithm seems > very good but maybe yours is similar or can do better. Worse case, > both can be put in under different names a little bit like the > different root finding algorithms in scipy.optimize. You can never > have enough algorithms to get around pathological problems. > > Now, regarding Wolfgang's post, I very much agree with his ideas. I > have to say that I've already implemented the "find" from "find.pro" > in IDL's astrolib, which works really well in order to identify point > sources. At the same time, I've modernized the program so that it > takes advantage of numpy's array algebra, hence there are no slow "for > loops". Maybe other algorithms could be worked out but this one > certainly works well and it would be a shame to re-invent the wheel > and have someone redo it. I think it should have been committed in the > "pyastrolib" project that I was part of. If not, I'm very happy to add > it here. > > I'm also not very far from having a re-brewed "aper" function working, > from "aper.pro" in IDL's astrolib but there are a couple of function > dependencies that I haven't had try to code. So maybe the students > could start from there in their coding. > > Here are two ideas that I'd like to throw in for the student project, > but they also apply in a more general way: > 1. IDL's astrolib is a good start. The phot/daophot stuff from IDL's > astrolib is generally pretty good, though it would gain to be > modernized (and make use of array operations for instance). Since IDL > and python are arguably similar, it would probably be not too > difficult for someone with minimal experience to port some IDL code to > python. Then one can optimize it. > 2. Working on new photometry algorithms. Despite students may have > limited programming background, they might be clever physicists. There > are different algorithm using maximum entropy and such that can try to > optimized the number of fitted sources. Among other interesting things > would be algorithms/functions to derive photometric upper limits. This > is what annoys me most and IDL's astrolib totally misses it. For PSF > photometry, a routine that adds fake stars and tries to retrieve their > flux in order to asses upper limits would be awesome. Something should > also be done for aperture photometry. > > > Cheers, > > > Rene -- ______________________________________________________________ Jonathan D. Slavin Harvard-Smithsonian CfA jslavin at cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 cell: (781) 363-0035 USA ______________________________________________________________ From jturner at gemini.edu Tue Aug 3 14:17:21 2010 From: jturner at gemini.edu (James Turner) Date: Tue, 3 Aug 2010 14:17:21 -0400 Subject: [AstroPy] Summer scholar In-Reply-To: <1280858468.20684.13.camel@shevek> References: <1280858468.20684.13.camel@shevek> Message-ID: <4C585D31.8090908@gemini.edu> Yeah, the whole of ndimage needs rewriting (the code is also somewhat impenetrable and doesn't have a proper maintainer). That's a fairly daunting task and no-one has had time to do it so far. A lot of us need that code, so sooner or later I think someone may have to bite the bullet... I wish we had the time. Cheers, James. Jonathan Slavin wrote: > One thing that I'd like (don't know if a summer student could do it) is > to improve on the multidimensional filtering/smoothing in scipy. We had > some discussions about this a little while back. Specifically the > ndimage.filters.uniform_filter and others in that module are implemented > in multiple dimensions via a series of 1-D filters in each dimension -- > which is not the same as a truly multi-dimensional filter. Maybe this > is not something there is much interest in, though anyone who wants to > remove some noise in a 2-D image might be interested. > > Jon Slavin > > On Tue, 2010-08-03 at 12:00 -0500, astropy-request at scipy.org wrote: > >> Message: 1 >> Date: Tue, 3 Aug 2010 00:04:37 -0400 >> From: Rene Breton >> Subject: Re: [AstroPy] Summer scholar >> To: astropy at scipy.org >> Message-ID: <17371E6A-230E-4B3C-8977-115C0041E03B at gmail.com> >> Content-Type: text/plain; charset=us-ascii >> >> Hi everyone, >> >> >> Thanks for sharing your tips/library Stefano. Indeed a matching >> routine would be very nice to have so people should definitely aim to >> have something that makes use of several criteria such as distance and >> magnitude (in a more generic way). The Groth/Stetson algorithm seems >> very good but maybe yours is similar or can do better. Worse case, >> both can be put in under different names a little bit like the >> different root finding algorithms in scipy.optimize. You can never >> have enough algorithms to get around pathological problems. >> >> Now, regarding Wolfgang's post, I very much agree with his ideas. I >> have to say that I've already implemented the "find" from "find.pro" >> in IDL's astrolib, which works really well in order to identify point >> sources. At the same time, I've modernized the program so that it >> takes advantage of numpy's array algebra, hence there are no slow "for >> loops". Maybe other algorithms could be worked out but this one >> certainly works well and it would be a shame to re-invent the wheel >> and have someone redo it. I think it should have been committed in the >> "pyastrolib" project that I was part of. If not, I'm very happy to add >> it here. >> >> I'm also not very far from having a re-brewed "aper" function working, >> from "aper.pro" in IDL's astrolib but there are a couple of function >> dependencies that I haven't had try to code. So maybe the students >> could start from there in their coding. >> >> Here are two ideas that I'd like to throw in for the student project, >> but they also apply in a more general way: >> 1. IDL's astrolib is a good start. The phot/daophot stuff from IDL's >> astrolib is generally pretty good, though it would gain to be >> modernized (and make use of array operations for instance). Since IDL >> and python are arguably similar, it would probably be not too >> difficult for someone with minimal experience to port some IDL code to >> python. Then one can optimize it. >> 2. Working on new photometry algorithms. Despite students may have >> limited programming background, they might be clever physicists. There >> are different algorithm using maximum entropy and such that can try to >> optimized the number of fitted sources. Among other interesting things >> would be algorithms/functions to derive photometric upper limits. This >> is what annoys me most and IDL's astrolib totally misses it. For PSF >> photometry, a routine that adds fake stars and tries to retrieve their >> flux in order to asses upper limits would be awesome. Something should >> also be done for aperture photometry. >> >> >> Cheers, >> >> >> Rene From erik.tollerud at gmail.com Tue Aug 3 15:18:46 2010 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Tue, 3 Aug 2010 12:18:46 -0700 Subject: [AstroPy] Summer scholar In-Reply-To: <4C585D31.8090908@gemini.edu> References: <1280858468.20684.13.camel@shevek> <4C585D31.8090908@gemini.edu> Message-ID: I definitely agree that scipy.ndimage needs some work... but a re-write/fixup is probably a perfect Google Summer of Code project... then hopefully whomever ended up as the mentor could then take responsibility as the maintainer even if they didn't have time to really dig into the code as much as the student would. Also, regarding Rene's suggestions: Those are definitely usefule tasks, and re-writing astrolib functions is a straightforward way to have a well-defined task, but for a physics student (which likely means no IDL background), that requires learning two languages. that's a pretty big lead-up to getting anything really at all done... and is it really a good idea to spoil a fresh new student's mind by forcing them to first learn IDL before python :) ? It does depend on the student, but for something with a decent algorithmic description (e.g. daophot, for which the papers pretty much say it all), it might be better to define a task, and then let the student do it from the ground up in a more pythonic fashion. By that I mean both the improvements Rene described that are available using numpy tricks, as well as following python constructs (object-oriented, proper exceptions, etc) instead of being tied to an IDL-style function-calls-only way of thinking. I would also point out, for those that are interested, that there is groundwork already in place for PSF and aperture photometry in astropysics (in the phot module - http://packages.python.org/Astropysics/coremods/phot.html). Not much of it is really in a generically workable state yet, but many of the pieces (background estimation, PSF model classes, an object-oriented pipeline for ccdproc tasks, etc) are in place. It mostly needs to be put together and polished, so maybe that's a task for a summer student, either within astopysics itself, or using those as a starting point... On Tue, Aug 3, 2010 at 11:17 AM, James Turner wrote: > Yeah, the whole of ndimage needs rewriting (the code is also > somewhat impenetrable and doesn't have a proper maintainer). That's > a fairly daunting task and no-one has had time to do it so far. A lot > of us need that code, so sooner or later I think someone may have to > bite the bullet... I wish we had the time. > > Cheers, > > James. > > > Jonathan Slavin wrote: >> One thing that I'd like (don't know if a summer student could do it) is >> to improve on the multidimensional filtering/smoothing in scipy. We had >> some discussions about this a little while back. ?Specifically the >> ndimage.filters.uniform_filter and others in that module are implemented >> in multiple dimensions via a series of 1-D filters in each dimension -- >> which is not the same as a truly multi-dimensional filter. ?Maybe this >> is not something there is much interest in, though anyone who wants to >> remove some noise in a 2-D image might be interested. >> >> Jon Slavin >> >> On Tue, 2010-08-03 at 12:00 -0500, astropy-request at scipy.org wrote: >> >>> Message: 1 >>> Date: Tue, 3 Aug 2010 00:04:37 -0400 >>> From: Rene Breton >>> Subject: Re: [AstroPy] Summer scholar >>> To: astropy at scipy.org >>> Message-ID: <17371E6A-230E-4B3C-8977-115C0041E03B at gmail.com> >>> Content-Type: text/plain; charset=us-ascii >>> >>> Hi everyone, >>> >>> >>> Thanks for sharing your tips/library Stefano. Indeed a matching >>> routine would be very nice to have so people should definitely aim to >>> have something that makes use of several criteria such as distance and >>> magnitude (in a more generic way). The Groth/Stetson algorithm seems >>> very good but maybe yours is similar or can do better. Worse case, >>> both can be put in under different names a little bit like the >>> different root finding algorithms in scipy.optimize. You can never >>> have enough algorithms to get around pathological problems. >>> >>> Now, regarding Wolfgang's post, I very much agree with his ideas. I >>> have to say that I've already implemented the "find" from "find.pro" >>> in IDL's astrolib, which works really well in order to identify point >>> sources. At the same time, I've modernized the program so that it >>> takes advantage of numpy's array algebra, hence there are no slow "for >>> loops". Maybe other algorithms could be worked out but this one >>> certainly works well and it would be a shame to re-invent the wheel >>> and have someone redo it. I think it should have been committed in the >>> "pyastrolib" project that I was part of. If not, I'm very happy to add >>> it here. >>> >>> I'm also not very far from having a re-brewed "aper" function working, >>> from "aper.pro" in IDL's astrolib but there are a couple of function >>> dependencies that I haven't had try to code. So maybe the students >>> could start from there in their coding. >>> >>> Here are two ideas that I'd like to throw in for the student project, >>> but they also apply in a more general way: >>> 1. IDL's astrolib is a good start. The phot/daophot stuff from IDL's >>> astrolib is generally pretty good, though it would gain to be >>> modernized (and make use of array operations for instance). Since IDL >>> and python are arguably similar, it would probably be not too >>> difficult for someone with minimal experience to port some IDL code to >>> python. Then one can optimize it. >>> 2. Working on new photometry algorithms. Despite students may have >>> limited programming background, they might be clever physicists. There >>> are different algorithm using maximum entropy and such that can try to >>> optimized the number of fitted sources. Among other interesting things >>> would be algorithms/functions to derive photometric upper limits. This >>> is what annoys me most and IDL's astrolib totally misses it. For PSF >>> photometry, a routine that adds fake stars and tries to retrieve their >>> flux in order to asses upper limits would be awesome. Something should >>> also be done for aperture photometry. >>> >>> >>> Cheers, >>> >>> >>> Rene > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Erik Tollerud From sierra_mtnview at sbcglobal.net Sun Aug 8 19:39:51 2010 From: sierra_mtnview at sbcglobal.net (Wayne Watson) Date: Sun, 08 Aug 2010 16:39:51 -0700 Subject: [AstroPy] Does anyone here use The Software Bisque Orchestrate Program? Message-ID: <4C5F4047.9090001@sbcglobal.net> See Subject. It's a long shot, and it is related to this list. -- Wayne Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39? 15' 7" N, 121? 2' 32" W, 2700 feet "An experiment is a question which science poses to Nature, and a measurement is the recording of Nature?s answer." -- Max Planck Web Page: From wkerzendorf at googlemail.com Sun Aug 8 20:01:13 2010 From: wkerzendorf at googlemail.com (Wolfgang Kerzendorf) Date: Mon, 09 Aug 2010 10:01:13 +1000 Subject: [AstroPy] Does anyone here use The Software Bisque Orchestrate Program? In-Reply-To: <4C5F4047.9090001@sbcglobal.net> References: <4C5F4047.9090001@sbcglobal.net> Message-ID: <4C5F4549.2080409@gmail.com> It is not related to this list, as that does not seem to be an astronomy python program. This is not a general astronomy help forum. Cheers Wolfgang On 9/08/10 9:39 AM, Wayne Watson wrote:a > See Subject. It's a long shot, and it is related to this list. > From sierra_mtnview at sbcglobal.net Sun Aug 8 20:21:11 2010 From: sierra_mtnview at sbcglobal.net (Wayne Watson) Date: Sun, 08 Aug 2010 17:21:11 -0700 Subject: [AstroPy] Does anyone here use The Software Bisque Orchestrate Program? In-Reply-To: <4C5F4549.2080409@gmail.com> References: <4C5F4047.9090001@sbcglobal.net> <4C5F4549.2080409@gmail.com> Message-ID: <4C5F49F7.6000805@sbcglobal.net> Well, I think you are wrong about my post, but you do not know the reason why. The reason is this. First, The Bisque writes very professional astronomy software for their products, one of which is a hig quality GEM robotic mount. Further, Orchestrate is able to utilize programs written in Visual Basic Script, JavaScript, Perl and other high level languages. If I'm not mistaken it does this in first three languages by the user providing a "compiled" version to Orchestrate. Using, say, VB, one is able to write "auxillary" programs with a GUI as an aid to operation. So my follow up question is will Python work with it Python? Python can produce exe files, as I understand it but neither the Bisque or I know if they work. My questions stand until the moderator says otherwise. On 8/8/2010 5:01 PM, Wolfgang Kerzendorf wrote: > It is not related to this list, as that does not seem to be an > astronomy python program. This is not a general astronomy help forum. > > Cheers > Wolfgang > On 9/08/10 9:39 AM, Wayne Watson wrote:a > >> See Subject. It's a long shot, and it is related to this list. >> >> > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- Wayne Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39? 15' 7" N, 121? 2' 32" W, 2700 feet "An experiment is a question which science poses to Nature, and a measurement is the recording of Nature?s answer." -- Max Planck Web Page: From tgrav at mac.com Sun Aug 8 20:28:06 2010 From: tgrav at mac.com (Tommy Grav) Date: Sun, 08 Aug 2010 20:28:06 -0400 Subject: [AstroPy] Does anyone here use The Software Bisque Orchestrate Program? In-Reply-To: <4C5F49F7.6000805@sbcglobal.net> References: <4C5F4047.9090001@sbcglobal.net> <4C5F4549.2080409@gmail.com> <4C5F49F7.6000805@sbcglobal.net> Message-ID: <27C815E3-3796-4703-9066-108BF4CF0E53@mac.com> On Aug 8, 2010, at 8:21 PM, Wayne Watson wrote: > Well, I think you are wrong about my post, but you do not know the > reason why. The reason is this. First, The Bisque writes very > professional astronomy software for their products, one of which is a > hig quality GEM robotic mount. Further, Orchestrate is able to utilize > programs written in Visual Basic Script, JavaScript, Perl and other high > level languages. If I'm not mistaken it does this in first three > languages by the user providing a "compiled" version to Orchestrate. > Using, say, VB, one is able to write "auxillary" programs with a GUI as > an aid to operation. > > So my follow up question is will Python work with it Python? Python can > produce exe files, as I understand it but neither the Bisque or I know > if they work. My questions stand until the moderator says otherwise. How about actually stating you question properly in the original email, rather than an email without even a proper body, just a question in the header. Originally the question was has anyone used this software, now it is has anyone got python to work with it. Those are two very different questions. The first is hardly on topic, the second is semi-on topic for this list. Also take the time to do some investigating on your own, and spend more than 30 seconds writing exactly what you are trying to find out. An email with a question in the header does not give incentive for anyone to spend their own precious time helping you out. If you have not noticed, your style over the few days have started rubbing people around the python mailing lists the wrong way, so a softer style might give you more help. Tommy From sierra_mtnview at sbcglobal.net Sun Aug 8 21:56:49 2010 From: sierra_mtnview at sbcglobal.net (Wayne Watson) Date: Sun, 08 Aug 2010 18:56:49 -0700 Subject: [AstroPy] Does anyone here use The Software Bisque Orchestrate Program? In-Reply-To: <27C815E3-3796-4703-9066-108BF4CF0E53@mac.com> References: <4C5F4047.9090001@sbcglobal.net> <4C5F4549.2080409@gmail.com> <4C5F49F7.6000805@sbcglobal.net> <27C815E3-3796-4703-9066-108BF4CF0E53@mac.com> Message-ID: <4C5F6061.7010000@sbcglobal.net> If you don't recognize what's in the title, why read it? I consider it a filter. You make a huge assumption that is incorrect. That is I haven't searched for the answer elsewhere. On 8/8/2010 5:28 PM, Tommy Grav wrote: > On Aug 8, 2010, at 8:21 PM, Wayne Watson wrote: > > >> Well, I think you are wrong about my post, but you do not know the >> reason why. The reason is this. First, The Bisque writes very >> professional astronomy software for their products, one of which is a >> hig quality GEM robotic mount. Further, Orchestrate is able to utilize >> programs written in Visual Basic Script, JavaScript, Perl and other high >> level languages. If I'm not mistaken it does this in first three >> languages by the user providing a "compiled" version to Orchestrate. >> Using, say, VB, one is able to write "auxillary" programs with a GUI as >> an aid to operation. >> >> So my follow up question is will Python work with it Python? Python can >> produce exe files, as I understand it but neither the Bisque or I know >> if they work. My questions stand until the moderator says otherwise. >> > How about actually stating you question properly in the original email, > rather than an email without even a proper body, just a question in the > header. Originally the question was has anyone used this software, now it is > has anyone got python to work with it. Those are two very different > questions. The first is hardly on topic, the second is semi-on topic > for this list. > > Also take the time to do some investigating on your own, and spend more than > 30 seconds writing exactly what you are trying to find out. An email > with a question in the header does not give incentive for anyone to spend > their own precious time helping you out. If you have not noticed, your style > over the few days have started rubbing people around the python mailing lists > the wrong way, so a softer style might give you more help. > > Tommy > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- Wayne Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39? 15' 7" N, 121? 2' 32" W, 2700 feet "An experiment is a question which science poses to Nature, and a measurement is the recording of Nature?s answer." -- Max Planck Web Page: From wkerzendorf at googlemail.com Sun Aug 8 22:26:11 2010 From: wkerzendorf at googlemail.com (Wolfgang Kerzendorf) Date: Mon, 09 Aug 2010 12:26:11 +1000 Subject: [AstroPy] Does anyone here use The Software Bisque Orchestrate Program? In-Reply-To: <4C5F6061.7010000@sbcglobal.net> References: <4C5F4047.9090001@sbcglobal.net> <4C5F4549.2080409@gmail.com> <4C5F49F7.6000805@sbcglobal.net> <27C815E3-3796-4703-9066-108BF4CF0E53@mac.com> <4C5F6061.7010000@sbcglobal.net> Message-ID: <4C5F6743.7020808@gmail.com> Dear Wayne, Let me stop this right here, before this turns into a flaming war. Obviously we don't know how long you took searching, it just appeared (also from previous questions) that you might very quickly decide to write to the list before doing a proper investigation. Regarding the question in the title, it is often more helpful if you give a very brief overview(like 3-4 words) in the subject and much more detail in the main body. for example: operating system, precise problem description, aim for the solution, ... . Without this information the people on the list become frustrated as it is not a question they can answer and they don't (and can't) see the point. Most of us on this list are also professional astronomers, meaning that we often don't know companies like bisque. I'm sure they produce quality astronomical software but probably not that useful for our problems. So if you want help on those problems, I suggest giving us much more info on those. Remember that what is well known in the amateur circles might not be at all known in professional circles. This email is not meant to discourage you to post questions to this list, but to encourage you to change your style. cheers Wolfgang On 9/08/10 11:56 AM, Wayne Watson wrote: > If you don't recognize what's in the title, why read it? I consider it a > filter. You make a huge assumption that is incorrect. That is I haven't > searched for the answer elsewhere. > > On 8/8/2010 5:28 PM, Tommy Grav wrote: >> On Aug 8, 2010, at 8:21 PM, Wayne Watson wrote: >> >> >>> Well, I think you are wrong about my post, but you do not know the >>> reason why. The reason is this. First, The Bisque writes very >>> professional astronomy software for their products, one of which is a >>> hig quality GEM robotic mount. Further, Orchestrate is able to utilize >>> programs written in Visual Basic Script, JavaScript, Perl and other high >>> level languages. If I'm not mistaken it does this in first three >>> languages by the user providing a "compiled" version to Orchestrate. >>> Using, say, VB, one is able to write "auxillary" programs with a GUI as >>> an aid to operation. >>> >>> So my follow up question is will Python work with it Python? Python can >>> produce exe files, as I understand it but neither the Bisque or I know >>> if they work. My questions stand until the moderator says otherwise. >>> >> How about actually stating you question properly in the original email, >> rather than an email without even a proper body, just a question in the >> header. Originally the question was has anyone used this software, now it is >> has anyone got python to work with it. Those are two very different >> questions. The first is hardly on topic, the second is semi-on topic >> for this list. >> >> Also take the time to do some investigating on your own, and spend more than >> 30 seconds writing exactly what you are trying to find out. An email >> with a question in the header does not give incentive for anyone to spend >> their own precious time helping you out. If you have not noticed, your style >> over the few days have started rubbing people around the python mailing lists >> the wrong way, so a softer style might give you more help. >> >> Tommy >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> >> From sierra_mtnview at sbcglobal.net Sun Aug 8 22:42:53 2010 From: sierra_mtnview at sbcglobal.net (Wayne Watson) Date: Sun, 08 Aug 2010 19:42:53 -0700 Subject: [AstroPy] Does anyone here use The Software Bisque Orchestrate Program? In-Reply-To: <4C5F6743.7020808@gmail.com> References: <4C5F4047.9090001@sbcglobal.net> <4C5F4549.2080409@gmail.com> <4C5F49F7.6000805@sbcglobal.net> <27C815E3-3796-4703-9066-108BF4CF0E53@mac.com> <4C5F6061.7010000@sbcglobal.net> <4C5F6743.7020808@gmail.com> Message-ID: <4C5F6B2D.2070509@sbcglobal.net> Well, I fully agree. Just stop. I might add though there are a fair number of professional astronomers who use the equipment. In fact, in some important searches, a virtual field of this equipment is deployed on some pretty fair sized parcels. A good number of amateurs with this equipment work with pros. On 8/8/2010 7:26 PM, Wolfgang Kerzendorf wrote: > Dear Wayne, > > Let me stop this right here, before this turns into a flaming war. > Obviously we don't know how long you took searching, it just appeared > (also from previous questions) that you might very quickly decide to > write to the list before doing a proper investigation. > > Regarding the question in the title, it is often more helpful if you > give a very brief overview(like 3-4 words) in the subject and much more > detail in the main body. for example: operating system, precise problem > description, aim for the solution, ... . Without this information the > people on the list become frustrated as it is not a question they can > answer and they don't (and can't) see the point. > > Most of us on this list are also professional astronomers, meaning that > we often don't know companies like bisque. I'm sure they produce quality > astronomical software but probably not that useful for our problems. So > if you want help on those problems, I suggest giving us much more info > on those. Remember that what is well known in the amateur circles might > not be at all known in professional circles. > > This email is not meant to discourage you to post questions to this > list, but to encourage you to change your style. > > cheers > Wolfgang > > On 9/08/10 11:56 AM, Wayne Watson wrote: > >> If you don't recognize what's in the title, why read it? I consider it a >> filter. You make a huge assumption that is incorrect. That is I haven't >> searched for the answer elsewhere. >> >> On 8/8/2010 5:28 PM, Tommy Grav wrote: >> >>> On Aug 8, 2010, at 8:21 PM, Wayne Watson wrote: >>> >>> >>> >>>> Well, I think you are wrong about my post, but you do not know the >>>> reason why. The reason is this. First, The Bisque writes very >>>> professional astronomy software for their products, one of which is a >>>> hig quality GEM robotic mount. Further, Orchestrate is able to utilize >>>> programs written in Visual Basic Script, JavaScript, Perl and other high >>>> level languages. If I'm not mistaken it does this in first three >>>> languages by the user providing a "compiled" version to Orchestrate. >>>> Using, say, VB, one is able to write "auxillary" programs with a GUI as >>>> an aid to operation. >>>> >>>> So my follow up question is will Python work with it Python? Python can >>>> produce exe files, as I understand it but neither the Bisque or I know >>>> if they work. My questions stand until the moderator says otherwise. >>>> >>>> >>> How about actually stating you question properly in the original email, >>> rather than an email without even a proper body, just a question in the >>> header. Originally the question was has anyone used this software, now it is >>> has anyone got python to work with it. Those are two very different >>> questions. The first is hardly on topic, the second is semi-on topic >>> for this list. >>> >>> Also take the time to do some investigating on your own, and spend more than >>> 30 seconds writing exactly what you are trying to find out. An email >>> with a question in the header does not give incentive for anyone to spend >>> their own precious time helping you out. If you have not noticed, your style >>> over the few days have started rubbing people around the python mailing lists >>> the wrong way, so a softer style might give you more help. >>> >>> Tommy >>> >>> _______________________________________________ >>> 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 > > -- Wayne Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39? 15' 7" N, 121? 2' 32" W, 2700 feet "An experiment is a question which science poses to Nature, and a measurement is the recording of Nature?s answer." -- Max Planck Web Page: From ejensen1 at swarthmore.edu Mon Aug 9 10:15:12 2010 From: ejensen1 at swarthmore.edu (Eric Jensen) Date: Mon, 9 Aug 2010 10:15:12 -0400 Subject: [AstroPy] Does anyone here use The Software Bisque Orchestrate Program? In-Reply-To: <4C5F6061.7010000@sbcglobal.net> References: <4C5F4047.9090001@sbcglobal.net> <4C5F4549.2080409@gmail.com> <4C5F49F7.6000805@sbcglobal.net> <27C815E3-3796-4703-9066-108BF4CF0E53@mac.com> <4C5F6061.7010000@sbcglobal.net> Message-ID: <3BC9A931-847C-4A8D-9FC6-E0A4A3EC2403@swarthmore.edu> Hi Wayne, I don't know the specific answer to your question, but here are some related items that might put you on track to an answer. First, here's a page from someone who is using Python for telescope/ camera scripting on a Windows platform: http://www.astrophotoinsight.com/content/automation-budget-part-2-software http://www.astrophotoinsight.com/content/automation-budget-part-3-operation There is some example Python code on those pages, and all the code is in a ZIP file linked at the end of the second page. That doesn't deal with Orchestrate per se, but shows that Python can be used to interface with the Windows Common Object Model (COM) interface, so to the extent that Orchestrate exposes a COM interface, you should be able to talk to it via Python. On Aug 8, 2010, at 9:56 PM, Wayne Watson wrote: > Further, Orchestrate is able to utilize > programs written in Visual Basic Script, JavaScript, Perl and other > high > level languages. If I'm not mistaken it does this in first three > languages by the user providing a "compiled" version to Orchestrate. > Using, say, VB, one is able to write "auxillary" programs with a GUI > as > an aid to operation. > > So my follow up question is will Python work with it Python? Python > can > produce exe files, as I understand it but neither the Bisque or I know > if they work. I don't think you need a compiled version of the script you want to run. All of these are interpreted languages, so all that you need is a compiled *interpreter* program to translate the script into system calls at runtime. In the case of JScript or VBScript, the interpreter is built into Windows. In the case of Perl or Python, you just need to install a Windows version of the relevant interpreter (i.e. a Windows Python distribution). Also, depending on what you want to do, you may or may not need to interface with Orchestrate directly. If your main goal is to control the telescope and you are using TheSky (just guessing since you're using Bisque software and it sounds like maybe you've got a Paramount mount), you can talk to TheSky directly from Python via its ASCOM interface. If you log into the Software Bisque support site and search there, you can find documentation of the objects and methods that TheSky exposes. If you like, contact me off-list and I can send you an example script in VBscript that just moves the telescope to a particular RA and Dec. It's not Python code, but it shows the use of some of the objects and methods for communicating with a telecope via TheSky and wouldn't be hard to translate to Python. Finally, and more generally, any software you're running that speaks ASCOM can, in principle, be controlled via Python (http://ascom-standards.org/About/CompatLang.htm ). Hope this helps - Eric From sierra_mtnview at sbcglobal.net Mon Aug 9 13:29:45 2010 From: sierra_mtnview at sbcglobal.net (Wayne Watson) Date: Mon, 09 Aug 2010 10:29:45 -0700 Subject: [AstroPy] Does anyone here use The Software Bisque Orchestrate Program? In-Reply-To: <3BC9A931-847C-4A8D-9FC6-E0A4A3EC2403@swarthmore.edu> References: <4C5F4047.9090001@sbcglobal.net> <4C5F4549.2080409@gmail.com> <4C5F49F7.6000805@sbcglobal.net> <27C815E3-3796-4703-9066-108BF4CF0E53@mac.com> <4C5F6061.7010000@sbcglobal.net> <3BC9A931-847C-4A8D-9FC6-E0A4A3EC2403@swarthmore.edu> Message-ID: <4C603B09.3000900@sbcglobal.net> You hit a home run with that. Thanks. Not even The Bisque seems to know this. On 8/9/2010 7:15 AM, Eric Jensen wrote: > Hi Wayne, > > I don't know the specific answer to your question, but here are some > related items that might put you on track to an answer. > > First, here's a page from someone who is using Python for telescope/ > camera scripting on a Windows platform: > > http://www.astrophotoinsight.com/content/automation-budget-part-2-software > http://www.astrophotoinsight.com/content/automation-budget-part-3-operation > > There is some example Python code on those pages, and all the code is > in a ZIP file linked at the end of the second page. > > That doesn't deal with Orchestrate per se, but shows that Python can > be used to interface with the Windows Common Object Model (COM) > interface, so to the extent that Orchestrate exposes a COM interface, > you should be able to talk to it via Python. > > > On Aug 8, 2010, at 9:56 PM, Wayne Watson wrote: > > >> Further, Orchestrate is able to utilize >> programs written in Visual Basic Script, JavaScript, Perl and other >> high >> level languages. If I'm not mistaken it does this in first three >> languages by the user providing a "compiled" version to Orchestrate. >> Using, say, VB, one is able to write "auxillary" programs with a GUI >> as >> an aid to operation. >> >> So my follow up question is will Python work with it Python? Python >> can >> produce exe files, as I understand it but neither the Bisque or I know >> if they work. >> > I don't think you need a compiled version of the script you want to > run. All of these are interpreted languages, so all that you need is > a compiled *interpreter* program to translate the script into system > calls at runtime. In the case of JScript or VBScript, the interpreter > is built into Windows. In the case of Perl or Python, you just need > to install a Windows version of the relevant interpreter (i.e. a > Windows Python distribution). > > Also, depending on what you want to do, you may or may not need to > interface with Orchestrate directly. If your main goal is to control > the telescope and you are using TheSky (just guessing since you're > using Bisque software and it sounds like maybe you've got a Paramount > mount), you can talk to TheSky directly from Python via its ASCOM > interface. If you log into the Software Bisque support site and > search there, you can find documentation of the objects and methods > that TheSky exposes. If you like, contact me off-list and I can send > you an example script in VBscript that just moves the telescope to a > particular RA and Dec. It's not Python code, but it shows the use of > some of the objects and methods for communicating with a telecope via > TheSky and wouldn't be hard to translate to Python. > > Finally, and more generally, any software you're running that speaks > ASCOM can, in principle, be controlled via Python (http://ascom-standards.org/About/CompatLang.htm > ). > > Hope this helps - > > Eric > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- Wayne Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39? 15' 7" N, 121? 2' 32" W, 2700 feet "An experiment is a question which science poses to Nature, and a measurement is the recording of Nature?s answer." -- Max Planck Web Page: From rays at blue-cove.com Mon Aug 9 14:16:25 2010 From: rays at blue-cove.com (RayS) Date: Mon, 09 Aug 2010 11:16:25 -0700 Subject: [AstroPy] Does anyone here use The Software Bisque Orchestrate Program? In-Reply-To: <4C603B09.3000900@sbcglobal.net> References: <4C5F4047.9090001@sbcglobal.net> <4C5F4549.2080409@gmail.com> <4C5F49F7.6000805@sbcglobal.net> <27C815E3-3796-4703-9066-108BF4CF0E53@mac.com> <4C5F6061.7010000@sbcglobal.net> <3BC9A931-847C-4A8D-9FC6-E0A4A3EC2403@swarthmore.edu> <4C603B09.3000900@sbcglobal.net> Message-ID: <6.2.3.4.2.20100809111105.028d94d8@blue-cove.com> A py2exe distribution should behave identically to a Python script with the interpreter installed (py2exe just creates a stub and packages up the interpreter and object files). py2.6+ are now more finicky to compile, what with the VS2008 DLLs and manifests. Also, if you're using LX200 protocols one could try the classes I wrote for direct scope control http://rjs.org/Python/LX200/ http://rjs.org/Python/LX200.zip Ray At 10:29 AM 8/9/2010, Wayne Watson wrote: >You hit a home run with that. Thanks. Not even The Bisque seems to know >this. > >On 8/9/2010 7:15 AM, Eric Jensen wrote: > > Hi Wayne, > > > > I don't know the specific answer to your question, but here are some > > related items that might put you on track to an answer. > > > > First, here's a page from someone who is using Python for telescope/ > > camera scripting on a Windows platform: > > > > http://www.astrophotoinsight.com/content/automation-budget-part-2-software > > http://www.astrophotoinsight.com/content/automation-budget-part-3-operation > > > > There is some example Python code on those pages, and all the code is > > in a ZIP file linked at the end of the second page. > > > > That doesn't deal with Orchestrate per se, but shows that Python can > > be used to interface with the Windows Common Object Model (COM) > > interface, so to the extent that Orchestrate exposes a COM interface, > > you should be able to talk to it via Python. > > > > > > On Aug 8, 2010, at 9:56 PM, Wayne Watson wrote: > > > > > >> Further, Orchestrate is able to utilize > >> programs written in Visual Basic Script, JavaScript, Perl and other > >> high > >> level languages. If I'm not mistaken it does this in first three > >> languages by the user providing a "compiled" version to Orchestrate. > >> Using, say, VB, one is able to write "auxillary" programs with a GUI > >> as > >> an aid to operation. > >> > >> So my follow up question is will Python work with it Python? Python > >> can > >> produce exe files, as I understand it but neither the Bisque or I know > >> if they work. > >> > > I don't think you need a compiled version of the script you want to > > run. All of these are interpreted languages, so all that you need is > > a compiled *interpreter* program to translate the script into system > > calls at runtime. In the case of JScript or VBScript, the interpreter > > is built into Windows. In the case of Perl or Python, you just need > > to install a Windows version of the relevant interpreter (i.e. a > > Windows Python distribution). > > > > Also, depending on what you want to do, you may or may not need to > > interface with Orchestrate directly. If your main goal is to control > > the telescope and you are using TheSky (just guessing since you're > > using Bisque software and it sounds like maybe you've got a Paramount > > mount), you can talk to TheSky directly from Python via its ASCOM > > interface. If you log into the Software Bisque support site and > > search there, you can find documentation of the objects and methods > > that TheSky exposes. If you like, contact me off-list and I can send > > you an example script in VBscript that just moves the telescope to a > > particular RA and Dec. It's not Python code, but it shows the use of > > some of the objects and methods for communicating with a telecope via > > TheSky and wouldn't be hard to translate to Python. > > > > Finally, and more generally, any software you're running that speaks > > ASCOM can, in principle, be controlled via > Python > (http://ascom-standards.org/About/CompatLang.htm > > ). > > > > Hope this helps - > > > > Eric > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > >-- > Wayne Watson (Watson Adventures, Prop., Nevada City, CA) > > (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) > Obz Site: 39? 15' 7" N, 121? 2' 32" W, 2700 feet > > "An experiment is a question which science poses to > Nature, and a measurement is the recording of > Nature?s answer." -- Max Planck > > > Web Page: > >_______________________________________________ >AstroPy mailing list >AstroPy at scipy.org >http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sierra_mtnview at sbcglobal.net Mon Aug 9 16:18:23 2010 From: sierra_mtnview at sbcglobal.net (Wayne Watson) Date: Mon, 09 Aug 2010 13:18:23 -0700 Subject: [AstroPy] Does anyone here use The Software Bisque Orchestrate Program? In-Reply-To: <6.2.3.4.2.20100809111105.028d94d8@blue-cove.com> References: <4C5F4047.9090001@sbcglobal.net> <4C5F4549.2080409@gmail.com> <4C5F49F7.6000805@sbcglobal.net> <27C815E3-3796-4703-9066-108BF4CF0E53@mac.com> <4C5F6061.7010000@sbcglobal.net> <3BC9A931-847C-4A8D-9FC6-E0A4A3EC2403@swarthmore.edu> <4C603B09.3000900@sbcglobal.net> <6.2.3.4.2.20100809111105.028d94d8@blue-cove.com> Message-ID: <4C60628F.10908@sbcglobal.net> An HTML attachment was scrubbed... URL: From jslavin at cfa.harvard.edu Tue Aug 10 09:16:44 2010 From: jslavin at cfa.harvard.edu (Jonathan Slavin) Date: Tue, 10 Aug 2010 09:16:44 -0400 Subject: [AstroPy] plot of data and residuals Message-ID: <1281446204.17495.10.camel@shevek> To AstroPy'ers: I'd like to make a plot using matplotlib with two subplots, a larger one with the data and model and a lower (smaller height) abutting one with the residuals (sharing the x-axis). Since this is a common sort of plot in astronomy, I thought maybe one of you might have figured out how to do this, saving me the trouble of figuring it out for myself. I don't see any examples quite like that on the matplotlib examples page. If I don't get any response, I'll do it myself and (if not too kludgey) will post my method. Jon -- ______________________________________________________________ Jonathan D. Slavin Harvard-Smithsonian CfA jslavin at cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 cell: (781) 363-0035 USA ______________________________________________________________ From fabricio at ferrari.pro.br Tue Aug 10 09:32:06 2010 From: fabricio at ferrari.pro.br (Fabricio Ferrari) Date: Tue, 10 Aug 2010 10:32:06 -0300 Subject: [AstroPy] plot of data and residuals Message-ID: Hello Jonathan in fact, there was no direct way of doing this in the pre-1.0 versions of Matplotlib. In the 1.0.0 version there is something called 'gridspec' which does exactly what you want. Anyway, if you can't install v.1.0.0 I found a way of doing this, shown below (I put only the relevant code) . . . # definitions for the axes left = 0.05 width = 0.65 bottom = 0.05 height = 0.65 bottom_h = left+width+0.02 left_h = left+width+0.02 rect_image = [left, bottom, width, height] rect_profx = [left, bottom_h, width, 0.2] rect_profy = [left_h, bottom+0.04, 0.2, height] # start with a rectangular Figure fig = P.figure(1, figsize=(8,8)) axProfX = P.axes(rect_profx) axProfX.plot(x,y) axImage = P.axes(rect_image) axImage.imshow(data,origin='lower',interpolation='nearest') axProfY = P.axes(rect_profy) axProfY.plot(x2,y2) . . . When you need to access plot properties in a particular subplot, you must invoke the functions via the axis class instances, axProfY, axProfX, and so on... ..-. ..-. Fabricio Ferrari? ? ?? [www.ferrari.pro.br] Universidade Federal do Pampa Bag? RS Brasil From thomas.robitaille at gmail.com Tue Aug 10 09:38:01 2010 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 10 Aug 2010 09:38:01 -0400 Subject: [AstroPy] plot of data and residuals In-Reply-To: <1281446204.17495.10.camel@shevek> References: <1281446204.17495.10.camel@shevek> Message-ID: Hi Jon, The easiest way to do something like this is just to define your axes size relative to the figure: import matplotlib as mpl mpl.use('Agg') import matplotlib.pyplot as plt fig = plt.figure() ax1 = fig.add_axes([0.1,0.35,0.8,0.50]) ax2 = fig.add_axes([0.1,0.1,0.8,0.20]) fig.savefig('data_residuals.png') The format of the axes specifications is [xmin, ymin, dx, dy]. You can then use ax1 and ax2 to plot in the respective axes. Cheers, Tom On Aug 10, 2010, at 9:16 AM, Jonathan Slavin wrote: > To AstroPy'ers: > > I'd like to make a plot using matplotlib with two subplots, a larger one > with the data and model and a lower (smaller height) abutting one with > the residuals (sharing the x-axis). Since this is a common sort of plot > in astronomy, I thought maybe one of you might have figured out how to > do this, saving me the trouble of figuring it out for myself. I don't > see any examples quite like that on the matplotlib examples page. If I > don't get any response, I'll do it myself and (if not too kludgey) will > post my method. > > Jon > -- > ______________________________________________________________ > Jonathan D. Slavin Harvard-Smithsonian CfA > jslavin at cfa.harvard.edu 60 Garden Street, MS 83 > phone: (617) 496-7981 Cambridge, MA 02138-1516 > cell: (781) 363-0035 USA > ______________________________________________________________ > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From derek at astro.physik.uni-goettingen.de Tue Aug 10 11:00:15 2010 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Tue, 10 Aug 2010 17:00:15 +0200 Subject: [AstroPy] plot of data and residuals In-Reply-To: References: <1281446204.17495.10.camel@shevek> Message-ID: <8C5A7E45-D251-4C02-AD7B-2C934BEA1351@astro.physik.uni-goettingen.de> Hi, > The easiest way to do something like this is just to define your > axes size relative to the figure: > > import matplotlib as mpl > mpl.use('Agg') > import matplotlib.pyplot as plt > > fig = plt.figure() > ax1 = fig.add_axes([0.1,0.35,0.8,0.50]) > ax2 = fig.add_axes([0.1,0.1,0.8,0.20]) > fig.savefig('data_residuals.png') > > The format of the axes specifications is [xmin, ymin, dx, dy]. You > can then use ax1 and ax2 to plot in the respective axes. I found the new subplot utility provided with matplotlib 1.0.0 also gives a number of useful hints to start with, e.g. it lets you do fig, axarr = plt.subplots(2, sharex=True) axarr[0].plot(x, y) axarr[1].plot(x, sigy) This still produces independent plot frames and x axis labels, so it's not quite be what you (or I) might envisage yet, but it automatically keeps the x ranges synchronised, and the source could be a good place to start for further refinements. You could implement the same functionality in Tom's example by passing the 'sharex' keyword to add_axes as below. It's also possible to get the axes adjacent, which lets you hide the x labels of ax1, but unfortunately you can't really get rid of them (since the x axis is now shared, any tampering with the xtick[labels] will affect ax2 in the same way): fig = plt.figure() ax1 = fig.add_axes([0.1,0.3,0.8,0.6]) ax2 = fig.add_axes([0.1,0.1,0.8,0.20], sharex=ax1) Note that logarithmic axis mappings should be done individually, e.g. axarr[0].semilogx(); axarr[1].semilogx() otherwise the labels may get mangled. Cheers, Derek -- ------------------------------------------------------------------------- Derek Homeier Institut f?r Astrophysik G?ttingen Georg-August-Universit?t Phone: +49 551 39-7980 Friedrich-Hund-Platz 1 Fax: +49 551 39-5043 D-37077 G?ttingen, Germany Feet: E.04.104 Web: http://www.astro.physik.uni-goettingen.de/~derek/ ------------------------------------------------------------------------- From jslavin at cfa.harvard.edu Tue Aug 10 15:11:48 2010 From: jslavin at cfa.harvard.edu (Jonathan Slavin) Date: Tue, 10 Aug 2010 15:11:48 -0400 Subject: [AstroPy] plot of data and residuals In-Reply-To: References: Message-ID: <1281467508.26381.8.camel@shevek> Thanks for all the suggestions regarding my question on plotting data and a model with residuals. Here is the simple function I wrote which gets the jobs done for me. It's not too flexible, but it's what I wanted. Jon def plot_model(xdata,ydata,edata,ymod,dcolor='b',mcolor='g'): """ Plot data and a model on one plot and the residuals on a plot stacked below. Returns the figure object and an array of the axes objects for the main plot and the residuals plot. f,a = plot_model(xdata,ydata,edata,ymod,dcolor='b',mcolor='g') where xdata, ydata, edata are the x, y and error values for the data and ymod are the model values. The keyword arguments dcolor (color of data points) and mcolor (color of model line) are accepted. """ fig = plt.figure() ax1 = fig.add_axes([0.1,0.3,0.8,0.6]) ax2 = fig.add_axes([0.1,0.1,0.8,0.2]) # I prefer not to have horizontal "caps" on my error bars ax1.errorbar(xdata,ydata,yerr=edata,marker='o',capsize=0,color=dcolor) ax1.plot(xdata,ymod,color=mcolor) xticklabels = ax1.get_xticklabels() plt.setp(xticklabels,visible=False) resid = ydata - ymod ax2.errorbar(xdata,resid,yerr=edata,marker='o',capsize=0,color=dcolor) ax2.axhline(0.,color='k') axes = np.array([ax1,ax2]) return fig, axes From lee.j.joon at gmail.com Wed Aug 11 03:03:21 2010 From: lee.j.joon at gmail.com (Jae-Joon Lee) Date: Wed, 11 Aug 2010 16:03:21 +0900 Subject: [AstroPy] plot of data and residuals In-Reply-To: <1281467508.26381.8.camel@shevek> References: <1281467508.26381.8.camel@shevek> Message-ID: On Wed, Aug 11, 2010 at 4:11 AM, Jonathan Slavin wrote: > Thanks for all the suggestions regarding my question on plotting data > and a model with residuals. ?Here is the simple function I wrote which > gets the jobs done for me. ?It's not too flexible, but it's what I > wanted. > > Jon > With matplotlib v1.0, you may consider to use the new gridspec functionality. http://matplotlib.sourceforge.net/users/gridspec.html#gridspec-with-varying-cell-sizes Regards, -JJ From kellecruz at gmail.com Thu Aug 12 14:59:59 2010 From: kellecruz at gmail.com (Kelle Cruz) Date: Thu, 12 Aug 2010 14:59:59 -0400 Subject: [AstroPy] Databases and Python Message-ID: Hey Guys, There's a question on the AstroBetter Facebook Discussion board about databases and SQL in Python: "i am looking for a tool to easily build databases - which would change/track changes and be SQL searchable....anyone with experience with SQLalchemy?" http://www.facebook.com/pages/AstroBetter/220025848560?v=app_2373072738#!/topic.php?uid=220025848560&topic=15212 i prefer you respond on the FB page...or take up the conversation on AstroPython. but do what you will. kelle -- Kelle Cruz, PhD http://kellecruz.com/ main: 917.725.1334 mobile: 917.837.9748 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkerzendorf at googlemail.com Thu Aug 12 21:08:58 2010 From: wkerzendorf at googlemail.com (Wolfgang Kerzendorf) Date: Fri, 13 Aug 2010 11:08:58 +1000 Subject: [AstroPy] Databases and Python In-Reply-To: References: Message-ID: <4C649B2A.4070109@gmail.com> Hello, I've used oursql to connect to mysql databases. The people on #python suggest that for mysql. I think for postgres you want psycopg2. Hope that helps Wolfgang P.S.: This post is also on Facebook On 13/08/10 4:59 AM, Kelle Cruz wrote: > Hey Guys, > > There's a question on the AstroBetter Facebook Discussion board about > databases and SQL in Python: > "i am looking for a tool to easily build databases - which would > change/track changes and be SQL searchable....anyone with experience > with SQLalchemy?" > http://www.facebook.com/pages/AstroBetter/220025848560?v=app_2373072738#!/topic.php?uid=220025848560&topic=15212 > > > > i prefer you respond on the FB page...or take up the conversation on > AstroPython. but do what you will. > > kelle > > -- > Kelle Cruz, PhD > http://kellecruz.com/ > main: 917.725.1334 > mobile: 917.837.9748 > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From erwin at mpe.mpg.de Wed Aug 18 14:40:58 2010 From: erwin at mpe.mpg.de (Peter Erwin) Date: Wed, 18 Aug 2010 20:40:58 +0200 Subject: [AstroPy] Problem running pywcs example Message-ID: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> Hi, I decided to check out pywcs (in part because using Pyraf to get pixel values from RA,Dec pairs seemed to be overkill, and wcwcstran was failing to work for SDSS images with declinations close to zero). The installation ("python setup.py install") seemd to go fine, but I ran into the following when I tried running the example from http://stsdas.stsci.edu/astrolib/pywcs/examples.html <> In [164]: hdulist = pyfits.open("pgc1905g_94-220.fits") # this is an SDSS g-band image In [165]: wcs = pywcs.WCS(hdulist[0].header) --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) /Users/erwin/Documents/Working/ESO_observing/WFI/targets/pgc1905_808/ in () /Users/erwin/lib/python/pywcs/pywcs.py in __init__(self, header, fobj, key, minerr, relax, naxis) 176 self.naxis = wcsprm.naxis 177 --> 178 det2im = self._read_det2im_kw(header, fobj) 179 cpdis = self._read_distortion_kw( 180 header, fobj, key=key,dist='CPDIS', err=minerr) /Users/erwin/lib/python/pywcs/pywcs.py in _read_det2im_kw(self, header, fobj) 278 cdelt = [1.,1.] 279 --> 280 if not isinstance(fobj, pyfits.NP_pyfits.HDUList): 281 return (None, None) 282 AttributeError: 'module' object has no attribute 'NP_pyfits' <> My system is: MacBook Pro (2009) running Mac OS 10.6.4, Python 2.6.5 (standard framework install from python.org) via ipython 0.10 numpy 1.4.1 pyfits 2.3.1 [same problem occurred for pyfits 2.2.2; I pywcs v1.9-4.4.4 (All packages are installed inside the framework directory, *except* for pyfits, which installed in ~/lib/python ) Any suggestions? -- Peter ============================================================= Peter Erwin Max-Planck-Insitute for Extraterrestrial erwin at mpe.mpg.de Physics, Giessenbachstrasse tel. +49 (0)89 30000 3695 85748 Garching, Germany fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin From mdroe at stsci.edu Wed Aug 18 15:04:48 2010 From: mdroe at stsci.edu (Michael Droettboom) Date: Wed, 18 Aug 2010 15:04:48 -0400 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> Message-ID: <4C6C2ED0.10101@stsci.edu> This problem occurs due to a version incompatibility between pyfits and pywcs. Recent versions of pyfits (2.3 and later) were refactored to no longer support numarray. pywcs required a change to be compatible with this (this change first appeared in pywcs 1.8). Given the versions you list, you should be ok -- however it seems that you are not running the version of pywcs you think you are. Perhaps you need to blitz the installation directory (in your case, /Users/erwin/lib/python/pywcs) and reinstall. Mike On 08/18/2010 02:40 PM, Peter Erwin wrote: > Hi, > > I decided to check out pywcs (in part because using Pyraf to get pixel values from > RA,Dec pairs seemed to be overkill, and wcwcstran was failing to work for SDSS > images with declinations close to zero). > > The installation ("python setup.py install") seemd to go fine, but I ran into the following when I tried > running the example from http://stsdas.stsci.edu/astrolib/pywcs/examples.html > > <> > In [164]: hdulist = pyfits.open("pgc1905g_94-220.fits") # this is an SDSS g-band image > In [165]: wcs = pywcs.WCS(hdulist[0].header) > --------------------------------------------------------------------------- > AttributeError Traceback (most recent call last) > > /Users/erwin/Documents/Working/ESO_observing/WFI/targets/pgc1905_808/ in() > > /Users/erwin/lib/python/pywcs/pywcs.py in __init__(self, header, fobj, key, minerr, relax, naxis) > 176 self.naxis = wcsprm.naxis > 177 > --> 178 det2im = self._read_det2im_kw(header, fobj) > 179 cpdis = self._read_distortion_kw( > 180 header, fobj, key=key,dist='CPDIS', err=minerr) > > /Users/erwin/lib/python/pywcs/pywcs.py in _read_det2im_kw(self, header, fobj) > 278 cdelt = [1.,1.] > 279 > --> 280 if not isinstance(fobj, pyfits.NP_pyfits.HDUList): > 281 return (None, None) > 282 > > AttributeError: 'module' object has no attribute 'NP_pyfits' > <> > > My system is: MacBook Pro (2009) running Mac OS 10.6.4, Python 2.6.5 (standard framework install > from python.org) via ipython 0.10 > numpy 1.4.1 > pyfits 2.3.1 [same problem occurred for pyfits 2.2.2; I > pywcs v1.9-4.4.4 > > (All packages are installed inside the framework directory, *except* for pyfits, which installed in > ~/lib/python ) > > Any suggestions? > > -- Peter > > ============================================================= > Peter Erwin Max-Planck-Insitute for Extraterrestrial > erwin at mpe.mpg.de Physics, Giessenbachstrasse > tel. +49 (0)89 30000 3695 85748 Garching, Germany > fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA From erwin at mpe.mpg.de Wed Aug 18 15:56:03 2010 From: erwin at mpe.mpg.de (Peter Erwin) Date: Wed, 18 Aug 2010 21:56:03 +0200 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <4C6C2ED0.10101@stsci.edu> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> Message-ID: Hi Mike, Thanks for the quick reply! It looks like what happened is that *was* an earlier version of pywcs hiding in /Users/erwin/lib/python [as opposed to /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 , which is where pywcs 1.9 got installed]. Possibly it got installed as part of an earlier installation of stsci_python ... Anyway, I nuked the earlier installation, and now pywcs seems to work. Am I missing something, or does the documentation for pywcs mention anywhere what "sky coordinates" actually means (i.e., allowed formats, types, order, etc.?). (From my experiments so far, I'm guessing that the output of WCS.wcs_pix2sky() for a single pair of pixel coordinates is [[Dec, RA]], with both in decimal degrees...?) cheers, Peter On Aug 18, 2010, at 9:04 PM, Michael Droettboom wrote: > This problem occurs due to a version incompatibility between pyfits and > pywcs. > > Recent versions of pyfits (2.3 and later) were refactored to no longer > support numarray. pywcs required a change to be compatible with this > (this change first appeared in pywcs 1.8). > > Given the versions you list, you should be ok -- however it seems that > you are not running the version of pywcs you think you are. Perhaps you > need to blitz the installation directory (in your case, > /Users/erwin/lib/python/pywcs) and reinstall. > > Mike > > On 08/18/2010 02:40 PM, Peter Erwin wrote: >> Hi, >> >> I decided to check out pywcs (in part because using Pyraf to get pixel values from >> RA,Dec pairs seemed to be overkill, and wcwcstran was failing to work for SDSS >> images with declinations close to zero). >> >> The installation ("python setup.py install") seemd to go fine, but I ran into the following when I tried >> running the example from http://stsdas.stsci.edu/astrolib/pywcs/examples.html >> >> <> >> In [164]: hdulist = pyfits.open("pgc1905g_94-220.fits") # this is an SDSS g-band image >> In [165]: wcs = pywcs.WCS(hdulist[0].header) >> --------------------------------------------------------------------------- >> AttributeError Traceback (most recent call last) >> >> /Users/erwin/Documents/Working/ESO_observing/WFI/targets/pgc1905_808/ in() >> >> /Users/erwin/lib/python/pywcs/pywcs.py in __init__(self, header, fobj, key, minerr, relax, naxis) >> 176 self.naxis = wcsprm.naxis >> 177 >> --> 178 det2im = self._read_det2im_kw(header, fobj) >> 179 cpdis = self._read_distortion_kw( >> 180 header, fobj, key=key,dist='CPDIS', err=minerr) >> >> /Users/erwin/lib/python/pywcs/pywcs.py in _read_det2im_kw(self, header, fobj) >> 278 cdelt = [1.,1.] >> 279 >> --> 280 if not isinstance(fobj, pyfits.NP_pyfits.HDUList): >> 281 return (None, None) >> 282 >> >> AttributeError: 'module' object has no attribute 'NP_pyfits' >> <> >> >> My system is: MacBook Pro (2009) running Mac OS 10.6.4, Python 2.6.5 (standard framework install >> from python.org) via ipython 0.10 >> numpy 1.4.1 >> pyfits 2.3.1 [same problem occurred for pyfits 2.2.2; I >> pywcs v1.9-4.4.4 >> >> (All packages are installed inside the framework directory, *except* for pyfits, which installed in >> ~/lib/python ) >> >> Any suggestions? >> >> -- Peter >> >> ============================================================= >> Peter Erwin Max-Planck-Insitute for Extraterrestrial >> erwin at mpe.mpg.de Physics, Giessenbachstrasse >> tel. +49 (0)89 30000 3695 85748 Garching, Germany >> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > Baltimore, Maryland, USA > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy ============================================================= Peter Erwin Max-Planck-Insitute for Extraterrestrial erwin at mpe.mpg.de Physics, Giessenbachstrasse tel. +49 (0)89 30000 3695 85748 Garching, Germany fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin From thomas.robitaille at gmail.com Wed Aug 18 19:03:13 2010 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Wed, 18 Aug 2010 19:03:13 -0400 Subject: [AstroPy] IDLSave 0.9.7 released Message-ID: I am happy to announce the availability of IDLSave 0.9.7. IDLSave is a pure Python module to import variables from IDL ?save? files into Python, and does not require IDL to work. I am also happy to announce that the IDLSave code has now also been included in scipy.io (thanks to Matthew Brett). The idlsave.read function is available via scipy.io.readsav and/or scipy.io.idl.readsav. Most of the changes in 0.9.6 and 0.9.7 are related to the move to scipy. In particular, unit tests are now present, and several small bugs uncovered in the process have been fixed. For the foreseeable future, IDLSave will be maintained in parallel with the scipy.io version, so there is no obligation to change to the scipy.io version at this stage. More information and download/installation instructions are available at http://idlsave.sourceforge.net/ Please let me know if you encounter any problems, or have any suggestions, Best regards, Thomas Robitaille From mdroe at stsci.edu Thu Aug 19 09:23:48 2010 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 19 Aug 2010 09:23:48 -0400 Subject: [AstroPy] Problem running pywcs example In-Reply-To: References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> Message-ID: <4C6D3064.5010500@stsci.edu> On 08/18/2010 03:56 PM, Peter Erwin wrote: > Hi Mike, > > Thanks for the quick reply! > > It looks like what happened is that *was* an earlier version of pywcs hiding > in /Users/erwin/lib/python [as opposed to > /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 , > which is where pywcs 1.9 got installed]. Possibly it got installed as part of > an earlier installation of stsci_python ... > > Anyway, I nuked the earlier installation, and now pywcs seems to work. > > > Am I missing something, or does the documentation for pywcs mention anywhere what > "sky coordinates" actually means (i.e., allowed formats, types, order, etc.?). > The order is described in the wcs_sky2pix docstring: """ Either two or three arguments may be provided. * 2 arguments: An /N/ x /naxis/ array of /x/- and /y/-coordinates, and an /origin/. * 3 arguments: 2 one-dimensional arrays of /x/ and /y/ coordinates, and an /origin/. """ As for types, it may be any numeric type (and the underlying calculations are performed in doubles). > (From my experiments so far, I'm guessing that the output of WCS.wcs_pix2sky() > for a single pair of pixel coordinates is [[Dec, RA]], with both in decimal degrees...?) > The fact that it's decimal degrees is somewhat buried (in the description of the lower-level wcslib functions.) I will move this information up to the higher-level functions -- and that should make it into the next version of the docs. Mike > cheers, > > Peter > > On Aug 18, 2010, at 9:04 PM, Michael Droettboom wrote: > > >> This problem occurs due to a version incompatibility between pyfits and >> pywcs. >> >> Recent versions of pyfits (2.3 and later) were refactored to no longer >> support numarray. pywcs required a change to be compatible with this >> (this change first appeared in pywcs 1.8). >> >> Given the versions you list, you should be ok -- however it seems that >> you are not running the version of pywcs you think you are. Perhaps you >> need to blitz the installation directory (in your case, >> /Users/erwin/lib/python/pywcs) and reinstall. >> >> Mike >> >> On 08/18/2010 02:40 PM, Peter Erwin wrote: >> >>> Hi, >>> >>> I decided to check out pywcs (in part because using Pyraf to get pixel values from >>> RA,Dec pairs seemed to be overkill, and wcwcstran was failing to work for SDSS >>> images with declinations close to zero). >>> >>> The installation ("python setup.py install") seemd to go fine, but I ran into the following when I tried >>> running the example from http://stsdas.stsci.edu/astrolib/pywcs/examples.html >>> >>> <> >>> In [164]: hdulist = pyfits.open("pgc1905g_94-220.fits") # this is an SDSS g-band image >>> In [165]: wcs = pywcs.WCS(hdulist[0].header) >>> --------------------------------------------------------------------------- >>> AttributeError Traceback (most recent call last) >>> >>> /Users/erwin/Documents/Working/ESO_observing/WFI/targets/pgc1905_808/ in() >>> >>> /Users/erwin/lib/python/pywcs/pywcs.py in __init__(self, header, fobj, key, minerr, relax, naxis) >>> 176 self.naxis = wcsprm.naxis >>> 177 >>> --> 178 det2im = self._read_det2im_kw(header, fobj) >>> 179 cpdis = self._read_distortion_kw( >>> 180 header, fobj, key=key,dist='CPDIS', err=minerr) >>> >>> /Users/erwin/lib/python/pywcs/pywcs.py in _read_det2im_kw(self, header, fobj) >>> 278 cdelt = [1.,1.] >>> 279 >>> --> 280 if not isinstance(fobj, pyfits.NP_pyfits.HDUList): >>> 281 return (None, None) >>> 282 >>> >>> AttributeError: 'module' object has no attribute 'NP_pyfits' >>> <> >>> >>> My system is: MacBook Pro (2009) running Mac OS 10.6.4, Python 2.6.5 (standard framework install >>> from python.org) via ipython 0.10 >>> numpy 1.4.1 >>> pyfits 2.3.1 [same problem occurred for pyfits 2.2.2; I >>> pywcs v1.9-4.4.4 >>> >>> (All packages are installed inside the framework directory, *except* for pyfits, which installed in >>> ~/lib/python ) >>> >>> Any suggestions? >>> >>> -- Peter >>> >>> ============================================================= >>> Peter Erwin Max-Planck-Insitute for Extraterrestrial >>> erwin at mpe.mpg.de Physics, Giessenbachstrasse >>> tel. +49 (0)89 30000 3695 85748 Garching, Germany >>> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >>> >>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >>> >> >> -- >> Michael Droettboom >> Science Software Branch >> Space Telescope Science Institute >> Baltimore, Maryland, USA >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > ============================================================= > Peter Erwin Max-Planck-Insitute for Extraterrestrial > erwin at mpe.mpg.de Physics, Giessenbachstrasse > tel. +49 (0)89 30000 3695 85748 Garching, Germany > fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Thu Aug 19 10:11:20 2010 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 19 Aug 2010 10:11:20 -0400 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <4C6D3064.5010500@stsci.edu> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> <4C6D3064.5010500@stsci.edu> Message-ID: <4C6D3B88.3070002@stsci.edu> On 08/19/2010 09:23 AM, Michael Droettboom wrote: > On 08/18/2010 03:56 PM, Peter Erwin wrote: >> Hi Mike, >> >> Thanks for the quick reply! >> >> It looks like what happened is that *was* an earlier version of pywcs hiding >> in /Users/erwin/lib/python [as opposed to >> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 , >> which is where pywcs 1.9 got installed]. Possibly it got installed as part of >> an earlier installation of stsci_python ... >> >> Anyway, I nuked the earlier installation, and now pywcs seems to work. >> >> >> Am I missing something, or does the documentation for pywcs mention anywhere what >> "sky coordinates" actually means (i.e., allowed formats, types, order, etc.?). >> > > The order is described in the wcs_sky2pix docstring: > > """ > > Either two or three arguments may be provided. > > * 2 arguments: An /N/ x /naxis/ array of /x/- and > /y/-coordinates, and an /origin/. > * 3 arguments: 2 one-dimensional arrays of /x/ and /y/ > coordinates, and an /origin/. > > """ > > As for types, it may be any numeric type (and the underlying > calculations are performed in doubles). And for additional clarification, I should add that the order (whether it's [dec, ra] or [ra, dec]) depends on the CTYPEia arguments in the FITS header. You can determine that programmatically (if necessary) from the .lat, .lng, .lattype and .lngtype members. Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From erwin at mpe.mpg.de Thu Aug 19 12:22:05 2010 From: erwin at mpe.mpg.de (Peter Erwin) Date: Thu, 19 Aug 2010 18:22:05 +0200 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <4C6D3B88.3070002@stsci.edu> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> <4C6D3064.5010500@stsci.edu> <4C6D3B88.3070002@stsci.edu> Message-ID: <0348D639-68F5-43D6-8625-151D69869216@mpe.mpg.de> Hi Mike, It probably would be useful to mention the units explicitly in the documentation, yes. Your note about the RA,Dec order depending on the CTYPE arguments does help explain some weird, inconsistent results I was getting for SDSS images (some of which turned out to have CTYPE1="DEC--TAN", while the majority have CTYPE1="RA--TAN"). That explains why WCS.wcs_pix2sky was returning (RA, Dec) for some images and (Dec, RA) for others. It might be useful putting a short note about this in the documentation, since I expect a fair number of people will be like me (i.e., expecting things to be RA,Dec by default and unaware that this can be mixed up depending on the details of the image header). cheers, Peter On Aug 19, 2010, at 4:11 PM, Michael Droettboom wrote: > On 08/19/2010 09:23 AM, Michael Droettboom wrote: >> On 08/18/2010 03:56 PM, Peter Erwin wrote: >>> Hi Mike, >>> >>> Thanks for the quick reply! >>> >>> It looks like what happened is that *was* an earlier version of pywcs hiding >>> in /Users/erwin/lib/python [as opposed to >>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 , >>> which is where pywcs 1.9 got installed]. Possibly it got installed as part of >>> an earlier installation of stsci_python ... >>> >>> Anyway, I nuked the earlier installation, and now pywcs seems to work. >>> >>> >>> Am I missing something, or does the documentation for pywcs mention anywhere what >>> "sky coordinates" actually means (i.e., allowed formats, types, order, etc.?). >>> >>> >> The order is described in the wcs_sky2pix docstring: >> """ >> Either two or three arguments may be provided. >> ? 2 arguments: An N x naxis array of x- and y-coordinates, and an origin. >> ? 3 arguments: 2 one-dimensional arrays of x and y coordinates, and an origin. >> """ >> >> As for types, it may be any numeric type (and the underlying calculations are performed in doubles). > And for additional clarification, I should add that the order (whether it's [dec, ra] or [ra, dec]) depends on the CTYPEia arguments in the FITS header. You can determine that programmatically (if necessary) from the .lat, .lng, .lattype and .lngtype members. > > Mike > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > Baltimore, Maryland, USA > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy ============================================================= Peter Erwin Max-Planck-Insitute for Extraterrestrial erwin at mpe.mpg.de Physics, Giessenbachstrasse tel. +49 (0)89 30000 3695 85748 Garching, Germany fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin From mdroe at stsci.edu Thu Aug 19 14:24:50 2010 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 19 Aug 2010 14:24:50 -0400 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <0348D639-68F5-43D6-8625-151D69869216@mpe.mpg.de> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> <4C6D3064.5010500@stsci.edu> <4C6D3B88.3070002@stsci.edu> <0348D639-68F5-43D6-8625-151D69869216@mpe.mpg.de> Message-ID: <4C6D76F2.8040207@stsci.edu> I've added a note in the documentation about this. Also of note is the "sub" method which creates a new WCS with the axes in the order you specify. Therefore, given an arbitrary WCS where you don't know the order of the axes (or even how many axes it has), you can do: new_wcs = wcs.sub(['latitude', 'longitude']) to get a new wcs that will always work in (ra, dec). http://stsdas.stsci.edu/astrolib/pywcs/api_wcs.html#pywcs.WCS.sub Mike On 08/19/2010 12:22 PM, Peter Erwin wrote: > Hi Mike, > > It probably would be useful to mention the units explicitly in the documentation, yes. > > Your note about the RA,Dec order depending on the CTYPE arguments does help > explain some weird, inconsistent results I was getting for SDSS images (some of which > turned out to have CTYPE1="DEC--TAN", while the majority have CTYPE1="RA--TAN"). > That explains why WCS.wcs_pix2sky was returning (RA, Dec) for some images and > (Dec, RA) for others. > > It might be useful putting a short note about this in the documentation, since I expect > a fair number of people will be like me (i.e., expecting things to be RA,Dec by default > and unaware that this can be mixed up depending on the details of the image header). > > cheers, > > Peter > > On Aug 19, 2010, at 4:11 PM, Michael Droettboom wrote: > > >> On 08/19/2010 09:23 AM, Michael Droettboom wrote: >> >>> On 08/18/2010 03:56 PM, Peter Erwin wrote: >>> >>>> Hi Mike, >>>> >>>> Thanks for the quick reply! >>>> >>>> It looks like what happened is that *was* an earlier version of pywcs hiding >>>> in /Users/erwin/lib/python [as opposed to >>>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 , >>>> which is where pywcs 1.9 got installed]. Possibly it got installed as part of >>>> an earlier installation of stsci_python ... >>>> >>>> Anyway, I nuked the earlier installation, and now pywcs seems to work. >>>> >>>> >>>> Am I missing something, or does the documentation for pywcs mention anywhere what >>>> "sky coordinates" actually means (i.e., allowed formats, types, order, etc.?). >>>> >>>> >>>> >>> The order is described in the wcs_sky2pix docstring: >>> """ >>> Either two or three arguments may be provided. >>> ? 2 arguments: An N x naxis array of x- and y-coordinates, and an origin. >>> ? 3 arguments: 2 one-dimensional arrays of x and y coordinates, and an origin. >>> """ >>> >>> As for types, it may be any numeric type (and the underlying calculations are performed in doubles). >>> >> And for additional clarification, I should add that the order (whether it's [dec, ra] or [ra, dec]) depends on the CTYPEia arguments in the FITS header. You can determine that programmatically (if necessary) from the .lat, .lng, .lattype and .lngtype members. >> >> Mike >> >> -- >> Michael Droettboom >> Science Software Branch >> Space Telescope Science Institute >> Baltimore, Maryland, USA >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > ============================================================= > Peter Erwin Max-Planck-Insitute for Extraterrestrial > erwin at mpe.mpg.de Physics, Giessenbachstrasse > tel. +49 (0)89 30000 3695 85748 Garching, Germany > fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA From mdroe at stsci.edu Thu Aug 19 14:30:14 2010 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 19 Aug 2010 14:30:14 -0400 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <4C6D76F2.8040207@stsci.edu> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> <4C6D3064.5010500@stsci.edu> <4C6D3B88.3070002@stsci.edu> <0348D639-68F5-43D6-8625-151D69869216@mpe.mpg.de> <4C6D76F2.8040207@stsci.edu> Message-ID: <4C6D7836.9080407@stsci.edu> I mis-typed. I meant: new_wcs = wcs.sub(['longitude', 'latitude']) Mike On 08/19/2010 02:24 PM, Michael Droettboom wrote: > I've added a note in the documentation about this. > > Also of note is the "sub" method which creates a new WCS with the axes > in the order you specify. Therefore, given an arbitrary WCS where you > don't know the order of the axes (or even how many axes it has), you can do: > > new_wcs = wcs.sub(['latitude', 'longitude']) > > to get a new wcs that will always work in (ra, dec). > > http://stsdas.stsci.edu/astrolib/pywcs/api_wcs.html#pywcs.WCS.sub > > Mike > > On 08/19/2010 12:22 PM, Peter Erwin wrote: > >> Hi Mike, >> >> It probably would be useful to mention the units explicitly in the documentation, yes. >> >> Your note about the RA,Dec order depending on the CTYPE arguments does help >> explain some weird, inconsistent results I was getting for SDSS images (some of which >> turned out to have CTYPE1="DEC--TAN", while the majority have CTYPE1="RA--TAN"). >> That explains why WCS.wcs_pix2sky was returning (RA, Dec) for some images and >> (Dec, RA) for others. >> >> It might be useful putting a short note about this in the documentation, since I expect >> a fair number of people will be like me (i.e., expecting things to be RA,Dec by default >> and unaware that this can be mixed up depending on the details of the image header). >> >> cheers, >> >> Peter >> >> On Aug 19, 2010, at 4:11 PM, Michael Droettboom wrote: >> >> >> >>> On 08/19/2010 09:23 AM, Michael Droettboom wrote: >>> >>> >>>> On 08/18/2010 03:56 PM, Peter Erwin wrote: >>>> >>>> >>>>> Hi Mike, >>>>> >>>>> Thanks for the quick reply! >>>>> >>>>> It looks like what happened is that *was* an earlier version of pywcs hiding >>>>> in /Users/erwin/lib/python [as opposed to >>>>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 , >>>>> which is where pywcs 1.9 got installed]. Possibly it got installed as part of >>>>> an earlier installation of stsci_python ... >>>>> >>>>> Anyway, I nuked the earlier installation, and now pywcs seems to work. >>>>> >>>>> >>>>> Am I missing something, or does the documentation for pywcs mention anywhere what >>>>> "sky coordinates" actually means (i.e., allowed formats, types, order, etc.?). >>>>> >>>>> >>>>> >>>>> >>>> The order is described in the wcs_sky2pix docstring: >>>> """ >>>> Either two or three arguments may be provided. >>>> ? 2 arguments: An N x naxis array of x- and y-coordinates, and an origin. >>>> ? 3 arguments: 2 one-dimensional arrays of x and y coordinates, and an origin. >>>> """ >>>> >>>> As for types, it may be any numeric type (and the underlying calculations are performed in doubles). >>>> >>>> >>> And for additional clarification, I should add that the order (whether it's [dec, ra] or [ra, dec]) depends on the CTYPEia arguments in the FITS header. You can determine that programmatically (if necessary) from the .lat, .lng, .lattype and .lngtype members. >>> >>> Mike >>> >>> -- >>> Michael Droettboom >>> Science Software Branch >>> Space Telescope Science Institute >>> Baltimore, Maryland, USA >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >>> >> ============================================================= >> Peter Erwin Max-Planck-Insitute for Extraterrestrial >> erwin at mpe.mpg.de Physics, Giessenbachstrasse >> tel. +49 (0)89 30000 3695 85748 Garching, Germany >> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> >> > > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA From erwin at mpe.mpg.de Fri Aug 20 08:42:30 2010 From: erwin at mpe.mpg.de (Peter Erwin) Date: Fri, 20 Aug 2010 14:42:30 +0200 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <4C6D76F2.8040207@stsci.edu> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> <4C6D3064.5010500@stsci.edu> <4C6D3B88.3070002@stsci.edu> <0348D639-68F5-43D6-8625-151D69869216@mpe.mpg.de> <4C6D76F2.8040207@stsci.edu> Message-ID: <9733622F-22A8-4476-9A29-97A6286A8B08@mpe.mpg.de> Hi Mike, Thanks for the "sub" suggestion... however, that seems to have the side effect of reversing the x,y output order from new_wcs.wcs_sky2pix when the FITS header has CTYPE1="DEC--TAN" i.e., the output from new_wsc.wcs_sky2pix(ra, dec) is [ array([y]), array([x]) ] when CTYPE1="DEC--TAN", instead of [ array([x]), array([y]) ] cheers, Peter On Aug 19, 2010, at 8:24 PM, Michael Droettboom wrote: > I've added a note in the documentation about this. > > Also of note is the "sub" method which creates a new WCS with the axes > in the order you specify. Therefore, given an arbitrary WCS where you > don't know the order of the axes (or even how many axes it has), you can do: > > new_wcs = wcs.sub(['latitude', 'longitude']) > > to get a new wcs that will always work in (ra, dec). > > http://stsdas.stsci.edu/astrolib/pywcs/api_wcs.html#pywcs.WCS.sub > > Mike > > On 08/19/2010 12:22 PM, Peter Erwin wrote: >> Hi Mike, >> >> It probably would be useful to mention the units explicitly in the documentation, yes. >> >> Your note about the RA,Dec order depending on the CTYPE arguments does help >> explain some weird, inconsistent results I was getting for SDSS images (some of which >> turned out to have CTYPE1="DEC--TAN", while the majority have CTYPE1="RA--TAN"). >> That explains why WCS.wcs_pix2sky was returning (RA, Dec) for some images and >> (Dec, RA) for others. >> >> It might be useful putting a short note about this in the documentation, since I expect >> a fair number of people will be like me (i.e., expecting things to be RA,Dec by default >> and unaware that this can be mixed up depending on the details of the image header). >> >> cheers, >> >> Peter >> >> On Aug 19, 2010, at 4:11 PM, Michael Droettboom wrote: >> >> >>> On 08/19/2010 09:23 AM, Michael Droettboom wrote: >>> >>>> On 08/18/2010 03:56 PM, Peter Erwin wrote: >>>> >>>>> Hi Mike, >>>>> >>>>> Thanks for the quick reply! >>>>> >>>>> It looks like what happened is that *was* an earlier version of pywcs hiding >>>>> in /Users/erwin/lib/python [as opposed to >>>>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 , >>>>> which is where pywcs 1.9 got installed]. Possibly it got installed as part of >>>>> an earlier installation of stsci_python ... >>>>> >>>>> Anyway, I nuked the earlier installation, and now pywcs seems to work. >>>>> >>>>> >>>>> Am I missing something, or does the documentation for pywcs mention anywhere what >>>>> "sky coordinates" actually means (i.e., allowed formats, types, order, etc.?). >>>>> >>>>> >>>>> >>>> The order is described in the wcs_sky2pix docstring: >>>> """ >>>> Either two or three arguments may be provided. >>>> ? 2 arguments: An N x naxis array of x- and y-coordinates, and an origin. >>>> ? 3 arguments: 2 one-dimensional arrays of x and y coordinates, and an origin. >>>> """ >>>> >>>> As for types, it may be any numeric type (and the underlying calculations are performed in doubles). >>>> >>> And for additional clarification, I should add that the order (whether it's [dec, ra] or [ra, dec]) depends on the CTYPEia arguments in the FITS header. You can determine that programmatically (if necessary) from the .lat, .lng, .lattype and .lngtype members. >>> >>> Mike >>> >>> -- >>> Michael Droettboom >>> Science Software Branch >>> Space Telescope Science Institute >>> Baltimore, Maryland, USA >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >> ============================================================= >> Peter Erwin Max-Planck-Insitute for Extraterrestrial >> erwin at mpe.mpg.de Physics, Giessenbachstrasse >> tel. +49 (0)89 30000 3695 85748 Garching, Germany >> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > Baltimore, Maryland, USA > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy ============================================================= Peter Erwin Max-Planck-Insitute for Extraterrestrial erwin at mpe.mpg.de Physics, Giessenbachstrasse tel. +49 (0)89 30000 3695 85748 Garching, Germany fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin From hodge at stsci.edu Fri Aug 20 09:10:22 2010 From: hodge at stsci.edu (Phil Hodge) Date: Fri, 20 Aug 2010 09:10:22 -0400 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <9733622F-22A8-4476-9A29-97A6286A8B08@mpe.mpg.de> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> <4C6D3064.5010500@stsci.edu> <4C6D3B88.3070002@stsci.edu> <0348D639-68F5-43D6-8625-151D69869216@mpe.mpg.de> <4C6D76F2.8040207@stsci.edu> <9733622F-22A8-4476-9A29-97A6286A8B08@mpe.mpg.de> Message-ID: <4C6E7EBE.9040807@stsci.edu> Peter, > Thanks for the "sub" suggestion... however, that seems to have the side effect of reversing > the x,y output order from new_wcs.wcs_sky2pix when the FITS header has CTYPE1="DEC--TAN" > > i.e., the output from new_wsc.wcs_sky2pix(ra, dec) is [ array([y]), array([x]) ] when > CTYPE1="DEC--TAN", instead of [ array([x]), array([y]) ] That sounds like a bug. Mike and I talked about this (the order of the results depending on CTYPEi) yesterday. I can understand that when you have other coordinate types (e.g. wavelength) together with celestial coordinates, the least confusing result is that the order of the output world coordinates be the same as CTYPEi. If you extract just the celestial coordinates and specify the order with the sub() method, however, you really shouldn't have to care about the order of CTYPEi in the header; the celestial coordinates in the world coordinate vector should agree with what you specified in sub(), and the pixel coordinates should always be in the order [x, y]. (In my humble opinion.) Phil From mdroe at stsci.edu Fri Aug 20 09:42:41 2010 From: mdroe at stsci.edu (Michael Droettboom) Date: Fri, 20 Aug 2010 09:42:41 -0400 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <9733622F-22A8-4476-9A29-97A6286A8B08@mpe.mpg.de> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> <4C6D3064.5010500@stsci.edu> <4C6D3B88.3070002@stsci.edu> <0348D639-68F5-43D6-8625-151D69869216@mpe.mpg.de> <4C6D76F2.8040207@stsci.edu> <9733622F-22A8-4476-9A29-97A6286A8B08@mpe.mpg.de> Message-ID: <4C6E8651.4020506@stsci.edu> Peter, Can you send me one of your FITS files with CTYPE1 == "DEC--TAN" so I can investigate this further? Mike On 08/20/2010 08:42 AM, Peter Erwin wrote: > Hi Mike, > > Thanks for the "sub" suggestion... however, that seems to have the side effect of reversing > the x,y output order from new_wcs.wcs_sky2pix when the FITS header has CTYPE1="DEC--TAN" > > i.e., the output from new_wsc.wcs_sky2pix(ra, dec) is [ array([y]), array([x]) ] when > CTYPE1="DEC--TAN", instead of [ array([x]), array([y]) ] > > cheers, > > Peter > > On Aug 19, 2010, at 8:24 PM, Michael Droettboom wrote: > > >> I've added a note in the documentation about this. >> >> Also of note is the "sub" method which creates a new WCS with the axes >> in the order you specify. Therefore, given an arbitrary WCS where you >> don't know the order of the axes (or even how many axes it has), you can do: >> >> new_wcs = wcs.sub(['latitude', 'longitude']) >> >> to get a new wcs that will always work in (ra, dec). >> >> http://stsdas.stsci.edu/astrolib/pywcs/api_wcs.html#pywcs.WCS.sub >> >> Mike >> >> On 08/19/2010 12:22 PM, Peter Erwin wrote: >> >>> Hi Mike, >>> >>> It probably would be useful to mention the units explicitly in the documentation, yes. >>> >>> Your note about the RA,Dec order depending on the CTYPE arguments does help >>> explain some weird, inconsistent results I was getting for SDSS images (some of which >>> turned out to have CTYPE1="DEC--TAN", while the majority have CTYPE1="RA--TAN"). >>> That explains why WCS.wcs_pix2sky was returning (RA, Dec) for some images and >>> (Dec, RA) for others. >>> >>> It might be useful putting a short note about this in the documentation, since I expect >>> a fair number of people will be like me (i.e., expecting things to be RA,Dec by default >>> and unaware that this can be mixed up depending on the details of the image header). >>> >>> cheers, >>> >>> Peter >>> >>> On Aug 19, 2010, at 4:11 PM, Michael Droettboom wrote: >>> >>> >>> >>>> On 08/19/2010 09:23 AM, Michael Droettboom wrote: >>>> >>>> >>>>> On 08/18/2010 03:56 PM, Peter Erwin wrote: >>>>> >>>>> >>>>>> Hi Mike, >>>>>> >>>>>> Thanks for the quick reply! >>>>>> >>>>>> It looks like what happened is that *was* an earlier version of pywcs hiding >>>>>> in /Users/erwin/lib/python [as opposed to >>>>>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 , >>>>>> which is where pywcs 1.9 got installed]. Possibly it got installed as part of >>>>>> an earlier installation of stsci_python ... >>>>>> >>>>>> Anyway, I nuked the earlier installation, and now pywcs seems to work. >>>>>> >>>>>> >>>>>> Am I missing something, or does the documentation for pywcs mention anywhere what >>>>>> "sky coordinates" actually means (i.e., allowed formats, types, order, etc.?). >>>>>> >>>>>> >>>>>> >>>>>> >>>>> The order is described in the wcs_sky2pix docstring: >>>>> """ >>>>> Either two or three arguments may be provided. >>>>> ? 2 arguments: An N x naxis array of x- and y-coordinates, and an origin. >>>>> ? 3 arguments: 2 one-dimensional arrays of x and y coordinates, and an origin. >>>>> """ >>>>> >>>>> As for types, it may be any numeric type (and the underlying calculations are performed in doubles). >>>>> >>>>> >>>> And for additional clarification, I should add that the order (whether it's [dec, ra] or [ra, dec]) depends on the CTYPEia arguments in the FITS header. You can determine that programmatically (if necessary) from the .lat, .lng, .lattype and .lngtype members. >>>> >>>> Mike >>>> >>>> -- >>>> Michael Droettboom >>>> Science Software Branch >>>> Space Telescope Science Institute >>>> Baltimore, Maryland, USA >>>> >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/astropy >>>> >>>> >>> ============================================================= >>> Peter Erwin Max-Planck-Insitute for Extraterrestrial >>> erwin at mpe.mpg.de Physics, Giessenbachstrasse >>> tel. +49 (0)89 30000 3695 85748 Garching, Germany >>> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >>> >>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >>> >> >> -- >> Michael Droettboom >> Science Software Branch >> Space Telescope Science Institute >> Baltimore, Maryland, USA >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > ============================================================= > Peter Erwin Max-Planck-Insitute for Extraterrestrial > erwin at mpe.mpg.de Physics, Giessenbachstrasse > tel. +49 (0)89 30000 3695 85748 Garching, Germany > fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA From erwin at mpe.mpg.de Fri Aug 20 10:08:36 2010 From: erwin at mpe.mpg.de (Peter Erwin) Date: Fri, 20 Aug 2010 16:08:36 +0200 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <4C6E8651.4020506@stsci.edu> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> <4C6D3064.5010500@stsci.edu> <4C6D3B88.3070002@stsci.edu> <0348D639-68F5-43D6-8625-151D69869216@mpe.mpg.de> <4C6D76F2.8040207@stsci.edu> <9733622F-22A8-4476-9A29-97A6286A8B08@mpe.mpg.de> <4C6E8651.4020506@stsci.edu> Message-ID: <77E0CDD8-9D3C-43A1-ABE2-4597F5048A1A@mpe.mpg.de> Hi Mike, You should be able to download it directly from the SDSS archive, via: http://das.sdss.org/imaging/94/40/corr/2/fpC-000094-g2-0220.fit.gz cheers, Peter On Aug 20, 2010, at 3:42 PM, Michael Droettboom wrote: > Peter, > > Can you send me one of your FITS files with CTYPE1 == "DEC--TAN" so I > can investigate this further? > > Mike > > On 08/20/2010 08:42 AM, Peter Erwin wrote: >> Hi Mike, >> >> Thanks for the "sub" suggestion... however, that seems to have the side effect of reversing >> the x,y output order from new_wcs.wcs_sky2pix when the FITS header has CTYPE1="DEC--TAN" >> >> i.e., the output from new_wsc.wcs_sky2pix(ra, dec) is [ array([y]), array([x]) ] when >> CTYPE1="DEC--TAN", instead of [ array([x]), array([y]) ] >> >> cheers, >> >> Peter >> >> On Aug 19, 2010, at 8:24 PM, Michael Droettboom wrote: >> >> >>> I've added a note in the documentation about this. >>> >>> Also of note is the "sub" method which creates a new WCS with the axes >>> in the order you specify. Therefore, given an arbitrary WCS where you >>> don't know the order of the axes (or even how many axes it has), you can do: >>> >>> new_wcs = wcs.sub(['latitude', 'longitude']) >>> >>> to get a new wcs that will always work in (ra, dec). >>> >>> http://stsdas.stsci.edu/astrolib/pywcs/api_wcs.html#pywcs.WCS.sub >>> >>> Mike >>> >>> On 08/19/2010 12:22 PM, Peter Erwin wrote: >>> >>>> Hi Mike, >>>> >>>> It probably would be useful to mention the units explicitly in the documentation, yes. >>>> >>>> Your note about the RA,Dec order depending on the CTYPE arguments does help >>>> explain some weird, inconsistent results I was getting for SDSS images (some of which >>>> turned out to have CTYPE1="DEC--TAN", while the majority have CTYPE1="RA--TAN"). >>>> That explains why WCS.wcs_pix2sky was returning (RA, Dec) for some images and >>>> (Dec, RA) for others. >>>> >>>> It might be useful putting a short note about this in the documentation, since I expect >>>> a fair number of people will be like me (i.e., expecting things to be RA,Dec by default >>>> and unaware that this can be mixed up depending on the details of the image header). >>>> >>>> cheers, >>>> >>>> Peter >>>> >>>> On Aug 19, 2010, at 4:11 PM, Michael Droettboom wrote: >>>> >>>> >>>> >>>>> On 08/19/2010 09:23 AM, Michael Droettboom wrote: >>>>> >>>>> >>>>>> On 08/18/2010 03:56 PM, Peter Erwin wrote: >>>>>> >>>>>> >>>>>>> Hi Mike, >>>>>>> >>>>>>> Thanks for the quick reply! >>>>>>> >>>>>>> It looks like what happened is that *was* an earlier version of pywcs hiding >>>>>>> in /Users/erwin/lib/python [as opposed to >>>>>>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 , >>>>>>> which is where pywcs 1.9 got installed]. Possibly it got installed as part of >>>>>>> an earlier installation of stsci_python ... >>>>>>> >>>>>>> Anyway, I nuked the earlier installation, and now pywcs seems to work. >>>>>>> >>>>>>> >>>>>>> Am I missing something, or does the documentation for pywcs mention anywhere what >>>>>>> "sky coordinates" actually means (i.e., allowed formats, types, order, etc.?). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> The order is described in the wcs_sky2pix docstring: >>>>>> """ >>>>>> Either two or three arguments may be provided. >>>>>> ? 2 arguments: An N x naxis array of x- and y-coordinates, and an origin. >>>>>> ? 3 arguments: 2 one-dimensional arrays of x and y coordinates, and an origin. >>>>>> """ >>>>>> >>>>>> As for types, it may be any numeric type (and the underlying calculations are performed in doubles). >>>>>> >>>>>> >>>>> And for additional clarification, I should add that the order (whether it's [dec, ra] or [ra, dec]) depends on the CTYPEia arguments in the FITS header. You can determine that programmatically (if necessary) from the .lat, .lng, .lattype and .lngtype members. >>>>> >>>>> Mike >>>>> >>>>> -- >>>>> Michael Droettboom >>>>> Science Software Branch >>>>> Space Telescope Science Institute >>>>> Baltimore, Maryland, USA >>>>> >>>>> _______________________________________________ >>>>> AstroPy mailing list >>>>> AstroPy at scipy.org >>>>> http://mail.scipy.org/mailman/listinfo/astropy >>>>> >>>>> >>>> ============================================================= >>>> Peter Erwin Max-Planck-Insitute for Extraterrestrial >>>> erwin at mpe.mpg.de Physics, Giessenbachstrasse >>>> tel. +49 (0)89 30000 3695 85748 Garching, Germany >>>> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >>>> >>>> >>>> >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/astropy >>>> >>>> >>> >>> -- >>> Michael Droettboom >>> Science Software Branch >>> Space Telescope Science Institute >>> Baltimore, Maryland, USA >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >> ============================================================= >> Peter Erwin Max-Planck-Insitute for Extraterrestrial >> erwin at mpe.mpg.de Physics, Giessenbachstrasse >> tel. +49 (0)89 30000 3695 85748 Garching, Germany >> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > Baltimore, Maryland, USA > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy ============================================================= Peter Erwin Max-Planck-Insitute for Extraterrestrial erwin at mpe.mpg.de Physics, Giessenbachstrasse tel. +49 (0)89 30000 3695 85748 Garching, Germany fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin From mdroe at stsci.edu Fri Aug 20 15:33:19 2010 From: mdroe at stsci.edu (Michael Droettboom) Date: Fri, 20 Aug 2010 15:33:19 -0400 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <77E0CDD8-9D3C-43A1-ABE2-4597F5048A1A@mpe.mpg.de> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> <4C6D3064.5010500@stsci.edu> <4C6D3B88.3070002@stsci.edu> <0348D639-68F5-43D6-8625-151D69869216@mpe.mpg.de> <4C6D76F2.8040207@stsci.edu> <9733622F-22A8-4476-9A29-97A6286A8B08@mpe.mpg.de> <4C6E8651.4020506@stsci.edu> <77E0CDD8-9D3C-43A1-ABE2-4597F5048A1A@mpe.mpg.de> Message-ID: <4C6ED87F.7090205@stsci.edu> Indeed, the problem you describe exists, because sub() merely swaps all of the parameters for each of the axes. I have a proposed solution in SVN which adds a new kwarg "ra_dec_order" to all the methods that convert to/from sky coordinates. When "ra_dec_order" is True, the input and output sky coordinate vectors will always be of the form (ra, dec) regardless of the order of the CTYPE keywords. I'd consider this functionality totally experimental until we have a chance to play with it and see if it's a good idea or not. Are you able to build pywcs yourself from SVN? It would be great to have your feedback. The svn address is: http://svn6.assembla.com/svn/astrolib/trunk/pywcs Contact me off list if you need instructions building/installing it. Mike On 08/20/2010 10:08 AM, Peter Erwin wrote: > Hi Mike, > > You should be able to download it directly from the SDSS archive, via: > > http://das.sdss.org/imaging/94/40/corr/2/fpC-000094-g2-0220.fit.gz > > > cheers, > > Peter > > On Aug 20, 2010, at 3:42 PM, Michael Droettboom wrote: > > >> Peter, >> >> Can you send me one of your FITS files with CTYPE1 == "DEC--TAN" so I >> can investigate this further? >> >> Mike >> >> On 08/20/2010 08:42 AM, Peter Erwin wrote: >> >>> Hi Mike, >>> >>> Thanks for the "sub" suggestion... however, that seems to have the side effect of reversing >>> the x,y output order from new_wcs.wcs_sky2pix when the FITS header has CTYPE1="DEC--TAN" >>> >>> i.e., the output from new_wsc.wcs_sky2pix(ra, dec) is [ array([y]), array([x]) ] when >>> CTYPE1="DEC--TAN", instead of [ array([x]), array([y]) ] >>> >>> cheers, >>> >>> Peter >>> >>> On Aug 19, 2010, at 8:24 PM, Michael Droettboom wrote: >>> >>> >>> >>>> I've added a note in the documentation about this. >>>> >>>> Also of note is the "sub" method which creates a new WCS with the axes >>>> in the order you specify. Therefore, given an arbitrary WCS where you >>>> don't know the order of the axes (or even how many axes it has), you can do: >>>> >>>> new_wcs = wcs.sub(['latitude', 'longitude']) >>>> >>>> to get a new wcs that will always work in (ra, dec). >>>> >>>> http://stsdas.stsci.edu/astrolib/pywcs/api_wcs.html#pywcs.WCS.sub >>>> >>>> Mike >>>> >>>> On 08/19/2010 12:22 PM, Peter Erwin wrote: >>>> >>>> >>>>> Hi Mike, >>>>> >>>>> It probably would be useful to mention the units explicitly in the documentation, yes. >>>>> >>>>> Your note about the RA,Dec order depending on the CTYPE arguments does help >>>>> explain some weird, inconsistent results I was getting for SDSS images (some of which >>>>> turned out to have CTYPE1="DEC--TAN", while the majority have CTYPE1="RA--TAN"). >>>>> That explains why WCS.wcs_pix2sky was returning (RA, Dec) for some images and >>>>> (Dec, RA) for others. >>>>> >>>>> It might be useful putting a short note about this in the documentation, since I expect >>>>> a fair number of people will be like me (i.e., expecting things to be RA,Dec by default >>>>> and unaware that this can be mixed up depending on the details of the image header). >>>>> >>>>> cheers, >>>>> >>>>> Peter >>>>> >>>>> On Aug 19, 2010, at 4:11 PM, Michael Droettboom wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> On 08/19/2010 09:23 AM, Michael Droettboom wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 08/18/2010 03:56 PM, Peter Erwin wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi Mike, >>>>>>>> >>>>>>>> Thanks for the quick reply! >>>>>>>> >>>>>>>> It looks like what happened is that *was* an earlier version of pywcs hiding >>>>>>>> in /Users/erwin/lib/python [as opposed to >>>>>>>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 , >>>>>>>> which is where pywcs 1.9 got installed]. Possibly it got installed as part of >>>>>>>> an earlier installation of stsci_python ... >>>>>>>> >>>>>>>> Anyway, I nuked the earlier installation, and now pywcs seems to work. >>>>>>>> >>>>>>>> >>>>>>>> Am I missing something, or does the documentation for pywcs mention anywhere what >>>>>>>> "sky coordinates" actually means (i.e., allowed formats, types, order, etc.?). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> The order is described in the wcs_sky2pix docstring: >>>>>>> """ >>>>>>> Either two or three arguments may be provided. >>>>>>> ? 2 arguments: An N x naxis array of x- and y-coordinates, and an origin. >>>>>>> ? 3 arguments: 2 one-dimensional arrays of x and y coordinates, and an origin. >>>>>>> """ >>>>>>> >>>>>>> As for types, it may be any numeric type (and the underlying calculations are performed in doubles). >>>>>>> >>>>>>> >>>>>>> >>>>>> And for additional clarification, I should add that the order (whether it's [dec, ra] or [ra, dec]) depends on the CTYPEia arguments in the FITS header. You can determine that programmatically (if necessary) from the .lat, .lng, .lattype and .lngtype members. >>>>>> >>>>>> Mike >>>>>> >>>>>> -- >>>>>> Michael Droettboom >>>>>> Science Software Branch >>>>>> Space Telescope Science Institute >>>>>> Baltimore, Maryland, USA >>>>>> >>>>>> _______________________________________________ >>>>>> AstroPy mailing list >>>>>> AstroPy at scipy.org >>>>>> http://mail.scipy.org/mailman/listinfo/astropy >>>>>> >>>>>> >>>>>> >>>>> ============================================================= >>>>> Peter Erwin Max-Planck-Insitute for Extraterrestrial >>>>> erwin at mpe.mpg.de Physics, Giessenbachstrasse >>>>> tel. +49 (0)89 30000 3695 85748 Garching, Germany >>>>> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> AstroPy mailing list >>>>> AstroPy at scipy.org >>>>> http://mail.scipy.org/mailman/listinfo/astropy >>>>> >>>>> >>>>> >>>> -- >>>> Michael Droettboom >>>> Science Software Branch >>>> Space Telescope Science Institute >>>> Baltimore, Maryland, USA >>>> >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/astropy >>>> >>>> >>> ============================================================= >>> Peter Erwin Max-Planck-Insitute for Extraterrestrial >>> erwin at mpe.mpg.de Physics, Giessenbachstrasse >>> tel. +49 (0)89 30000 3695 85748 Garching, Germany >>> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >>> >>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >>> >> >> -- >> Michael Droettboom >> Science Software Branch >> Space Telescope Science Institute >> Baltimore, Maryland, USA >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > ============================================================= > Peter Erwin Max-Planck-Insitute for Extraterrestrial > erwin at mpe.mpg.de Physics, Giessenbachstrasse > tel. +49 (0)89 30000 3695 85748 Garching, Germany > fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA From erwin at mpe.mpg.de Sat Aug 21 16:43:57 2010 From: erwin at mpe.mpg.de (Peter Erwin) Date: Sat, 21 Aug 2010 22:43:57 +0200 Subject: [AstroPy] Problem running pywcs example In-Reply-To: <4C6ED87F.7090205@stsci.edu> References: <8E87466A-3E32-4C35-A079-F9F06DA0827C@mpe.mpg.de> <4C6C2ED0.10101@stsci.edu> <4C6D3064.5010500@stsci.edu> <4C6D3B88.3070002@stsci.edu> <0348D639-68F5-43D6-8625-151D69869216@mpe.mpg.de> <4C6D76F2.8040207@stsci.edu> <9733622F-22A8-4476-9A29-97A6286A8B08@mpe.mpg.de> <4C6E8651.4020506@stsci.edu> <77E0CDD8-9D3C-43A1-ABE2-4597F5048A1A@mpe.mpg.de> <4C6ED87F.7090205@stsci.edu> Message-ID: <3CD6CE3A-D519-4DE1-A828-77FB6B318BF6@mpe.mpg.de> Yes, I should be able to retrieve it via SVN; I'll give it a try during the next few days. cheers, Peter On Aug 20, 2010, at 9:33 PM, Michael Droettboom wrote: > Indeed, the problem you describe exists, because sub() merely swaps all > of the parameters for each of the axes. > > I have a proposed solution in SVN which adds a new kwarg "ra_dec_order" > to all the methods that convert to/from sky coordinates. When > "ra_dec_order" is True, the input and output sky coordinate vectors will > always be of the form (ra, dec) regardless of the order of the CTYPE > keywords. > > I'd consider this functionality totally experimental until we have a > chance to play with it and see if it's a good idea or not. > > Are you able to build pywcs yourself from SVN? It would be great to > have your feedback. The svn address is: > > http://svn6.assembla.com/svn/astrolib/trunk/pywcs > > Contact me off list if you need instructions building/installing it. > > Mike > > On 08/20/2010 10:08 AM, Peter Erwin wrote: >> Hi Mike, >> >> You should be able to download it directly from the SDSS archive, via: >> >> http://das.sdss.org/imaging/94/40/corr/2/fpC-000094-g2-0220.fit.gz >> >> >> cheers, >> >> Peter >> >> On Aug 20, 2010, at 3:42 PM, Michael Droettboom wrote: >> >> >>> Peter, >>> >>> Can you send me one of your FITS files with CTYPE1 == "DEC--TAN" so I >>> can investigate this further? >>> >>> Mike >>> >>> On 08/20/2010 08:42 AM, Peter Erwin wrote: >>> >>>> Hi Mike, >>>> >>>> Thanks for the "sub" suggestion... however, that seems to have the side effect of reversing >>>> the x,y output order from new_wcs.wcs_sky2pix when the FITS header has CTYPE1="DEC--TAN" >>>> >>>> i.e., the output from new_wsc.wcs_sky2pix(ra, dec) is [ array([y]), array([x]) ] when >>>> CTYPE1="DEC--TAN", instead of [ array([x]), array([y]) ] >>>> >>>> cheers, >>>> >>>> Peter >>>> >>>> On Aug 19, 2010, at 8:24 PM, Michael Droettboom wrote: >>>> >>>> >>>> >>>>> I've added a note in the documentation about this. >>>>> >>>>> Also of note is the "sub" method which creates a new WCS with the axes >>>>> in the order you specify. Therefore, given an arbitrary WCS where you >>>>> don't know the order of the axes (or even how many axes it has), you can do: >>>>> >>>>> new_wcs = wcs.sub(['latitude', 'longitude']) >>>>> >>>>> to get a new wcs that will always work in (ra, dec). >>>>> >>>>> http://stsdas.stsci.edu/astrolib/pywcs/api_wcs.html#pywcs.WCS.sub >>>>> >>>>> Mike >>>>> >>>>> On 08/19/2010 12:22 PM, Peter Erwin wrote: >>>>> >>>>> >>>>>> Hi Mike, >>>>>> >>>>>> It probably would be useful to mention the units explicitly in the documentation, yes. >>>>>> >>>>>> Your note about the RA,Dec order depending on the CTYPE arguments does help >>>>>> explain some weird, inconsistent results I was getting for SDSS images (some of which >>>>>> turned out to have CTYPE1="DEC--TAN", while the majority have CTYPE1="RA--TAN"). >>>>>> That explains why WCS.wcs_pix2sky was returning (RA, Dec) for some images and >>>>>> (Dec, RA) for others. >>>>>> >>>>>> It might be useful putting a short note about this in the documentation, since I expect >>>>>> a fair number of people will be like me (i.e., expecting things to be RA,Dec by default >>>>>> and unaware that this can be mixed up depending on the details of the image header). >>>>>> >>>>>> cheers, >>>>>> >>>>>> Peter >>>>>> >>>>>> On Aug 19, 2010, at 4:11 PM, Michael Droettboom wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 08/19/2010 09:23 AM, Michael Droettboom wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 08/18/2010 03:56 PM, Peter Erwin wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi Mike, >>>>>>>>> >>>>>>>>> Thanks for the quick reply! >>>>>>>>> >>>>>>>>> It looks like what happened is that *was* an earlier version of pywcs hiding >>>>>>>>> in /Users/erwin/lib/python [as opposed to >>>>>>>>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 , >>>>>>>>> which is where pywcs 1.9 got installed]. Possibly it got installed as part of >>>>>>>>> an earlier installation of stsci_python ... >>>>>>>>> >>>>>>>>> Anyway, I nuked the earlier installation, and now pywcs seems to work. >>>>>>>>> >>>>>>>>> >>>>>>>>> Am I missing something, or does the documentation for pywcs mention anywhere what >>>>>>>>> "sky coordinates" actually means (i.e., allowed formats, types, order, etc.?). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> The order is described in the wcs_sky2pix docstring: >>>>>>>> """ >>>>>>>> Either two or three arguments may be provided. >>>>>>>> ? 2 arguments: An N x naxis array of x- and y-coordinates, and an origin. >>>>>>>> ? 3 arguments: 2 one-dimensional arrays of x and y coordinates, and an origin. >>>>>>>> """ >>>>>>>> >>>>>>>> As for types, it may be any numeric type (and the underlying calculations are performed in doubles). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> And for additional clarification, I should add that the order (whether it's [dec, ra] or [ra, dec]) depends on the CTYPEia arguments in the FITS header. You can determine that programmatically (if necessary) from the .lat, .lng, .lattype and .lngtype members. >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> -- >>>>>>> Michael Droettboom >>>>>>> Science Software Branch >>>>>>> Space Telescope Science Institute >>>>>>> Baltimore, Maryland, USA >>>>>>> >>>>>>> _______________________________________________ >>>>>>> AstroPy mailing list >>>>>>> AstroPy at scipy.org >>>>>>> http://mail.scipy.org/mailman/listinfo/astropy >>>>>>> >>>>>>> >>>>>>> >>>>>> ============================================================= >>>>>> Peter Erwin Max-Planck-Insitute for Extraterrestrial >>>>>> erwin at mpe.mpg.de Physics, Giessenbachstrasse >>>>>> tel. +49 (0)89 30000 3695 85748 Garching, Germany >>>>>> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> AstroPy mailing list >>>>>> AstroPy at scipy.org >>>>>> http://mail.scipy.org/mailman/listinfo/astropy >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Michael Droettboom >>>>> Science Software Branch >>>>> Space Telescope Science Institute >>>>> Baltimore, Maryland, USA >>>>> >>>>> _______________________________________________ >>>>> AstroPy mailing list >>>>> AstroPy at scipy.org >>>>> http://mail.scipy.org/mailman/listinfo/astropy >>>>> >>>>> >>>> ============================================================= >>>> Peter Erwin Max-Planck-Insitute for Extraterrestrial >>>> erwin at mpe.mpg.de Physics, Giessenbachstrasse >>>> tel. +49 (0)89 30000 3695 85748 Garching, Germany >>>> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >>>> >>>> >>>> >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/astropy >>>> >>>> >>> >>> -- >>> Michael Droettboom >>> Science Software Branch >>> Space Telescope Science Institute >>> Baltimore, Maryland, USA >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >> ============================================================= >> Peter Erwin Max-Planck-Insitute for Extraterrestrial >> erwin at mpe.mpg.de Physics, Giessenbachstrasse >> tel. +49 (0)89 30000 3695 85748 Garching, Germany >> fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > Baltimore, Maryland, USA > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy ============================================================= Peter Erwin Max-Planck-Insitute for Extraterrestrial erwin at mpe.mpg.de Physics, Giessenbachstrasse tel. +49 (0)89 30000 3695 85748 Garching, Germany fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin