From astropy at liska.ath.cx Fri Apr 1 09:03:11 2011 From: astropy at liska.ath.cx (Ole Streicher) Date: Fri, 01 Apr 2011 15:03:11 +0200 Subject: [AstroPy] [pywcs] Unit question Message-ID: <4D95CD0F.7080801@liska.ath.cx> Dear list, I am a bit struggling with the PyWCS coordinate transformation. I want to extract a subset of a data cube and keep the WCS information valid. In my case, the third coordinate is the wavelength, in "nm" units: (error-checking etc. is removed here) import pyfits, pywcs l0 = 6e-7 l1 = 7e-7 wcs = pywcs.WCS(hdu.header) edges = [ [ wcs.wcs.crval[0], wcs.wcs.crval[1], l0], [ wcs.wcs.crval[0], wcs.wcs.crval[1], l1] ] pix_coords = numpy.copy(wcs.wcs_sky2pix(edges, 0)) h = pyfits.ImageHDU( data = hdu.data[int(pix_coords[0][2]):int(pix_coords[1][2])+1,:, :], header = hdu.header) # Here comes the funny stuff start = [0, 0, int(pix_coords[0][2])] h.header['CRVAL3'] = wcs.wcs_pix2sky([start], 1)[0][2] The problem here is that "pix2sky" returns the wavelength in meters while I want to put it in the unit that was used in the original file. Is there an easy way to convert this? Regards Ole From jturner at gemini.edu Fri Apr 1 12:24:20 2011 From: jturner at gemini.edu (James Turner) Date: Fri, 1 Apr 2011 13:24:20 -0300 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D95CD0F.7080801@liska.ath.cx> References: <4D95CD0F.7080801@liska.ath.cx> Message-ID: <4D95FC34.4050603@gemini.edu> > h = pyfits.ImageHDU( > data = hdu.data[int(pix_coords[0][2]):int(pix_coords[1][2])+1,:, :], > header = hdu.header) > > # Here comes the funny stuff > start = [0, 0, int(pix_coords[0][2])] > h.header['CRVAL3'] = wcs.wcs_pix2sky([start], 1)[0][2] > > The problem here is that "pix2sky" returns the wavelength in meters > while I want to put it in the unit that was used in the original file. > Is there an easy way to convert this? Don't you just need to set CUNIT3 in the header? See paper I, S2.3: http://www.atnf.csiro.au/people/mcalabre/WCS/wcs.pdf Cheers, James. From jturner at gemini.edu Fri Apr 1 12:30:00 2011 From: jturner at gemini.edu (James Turner) Date: Fri, 1 Apr 2011 13:30:00 -0300 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D95FC34.4050603@gemini.edu> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> Message-ID: <4D95FD88.7000808@gemini.edu> Oh, sorry, that probably didn't make sense; it couldn't convert to m it didn't know what it was. Should think longer before posting... I did notice that there's a units class in pywcs (under API documentation), so maybe that will help? From aldcroft at head.cfa.harvard.edu Sun Apr 3 19:04:35 2011 From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft) Date: Sun, 3 Apr 2011 19:04:35 -0400 Subject: [AstroPy] PyWCS build failure on Windows 7 and Windows XP with EPD Message-ID: Hi - I'm am unable to build PyWCS on a Windows 7 and Windows XP machines using the latest EPD 7.0.2. In both cases I get the same compiler error. Any hints or advice would be most welcome. Below I include configuration information and the build log. Thanks, Tom --------------------------------- Windows 7 Pro 64bit, 2009, fully updated. Python version is 2.7.1 -- EPD 7.0-2 (64bit) Here is what I get with "python setup.py install" command from the directory indicated, where I unzipped the pywcs tar ball: C:\Python27\Scripts\pywcs-1.10-4.7>python setup.py install running install running build running build_py copying lib\svn_version.py -> build\lib.win-amd64-2.7\pywcs running build_ext building 'pywcs._pywcs' extension C:\Python27\Scripts\gcc.exe -mno-cygwin -mdll -O -Wall -DMS_WIN64 -DECHO -DWCSTR IG_MACRO -DPYWCS_BUILD -D_GNU_SOURCE -DNDEBUG -DYY_NO_UNISTD_H -D_CRT_SECURE_NO_ WARNINGS -UDEBUG -IC:\Python27\lib\site-packages\numpy\core\include -I.\wcslib\C -Iwcslib\C -I.\src -IC:\Python27\include -IC:\Python27\PC -c wcslib\C\flexed/wc sbth.c -o build\temp.win-amd64-2.7\Release\wcslib\c\flexed\wcsbth.o In file included from wcsbth.l:118:0: .\wcslib\C/wcs.h:1396:5: error: conflicting types for 'wcsset' c:/python27/egg-info/mingw/usr/lib/gcc/../../x86_64-w64-mingw32/include/string.h :161:20: note: previous declaration of 'wcsset' was here wcsbth.l: In function 'wcsbth': wcsbth.l:2081:1: warning: statement with no effect wcsbth.l: At top level: wcsbth.c:19886:16: warning: 'input' defined but not used error: command 'gcc' failed with exit status 1 From astropy at liska.ath.cx Mon Apr 4 08:27:34 2011 From: astropy at liska.ath.cx (Ole Streicher) Date: Mon, 04 Apr 2011 14:27:34 +0200 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D95FD88.7000808@gemini.edu> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> Message-ID: <4D99B936.4060002@liska.ath.cx> Dear James, Am 01.04.2011 18:30, schrieb James Turner: > Oh, sorry, that probably didn't make sense; it couldn't convert to m > it didn't know what it was. Should think longer before posting... I > did notice that there's a units class in pywcs (under API > documentation), so maybe that will help? This helps a bit, thank you. However, my problem is that I want to put not just the wavelength there but coordinates for all dimensions. So, I have a loop like for i, s in enumerate(wcs.wcs_pix2sky([origin], 1)[0]): conv = pywcs.UnitConverter(want = h.header['CUNIT%i' % (i+1)]) h.header['CRVAL%i' % (i+1)] = conv.convert(s) h.header['CRPIX%i' % (i+1)] = 1 The Problem here is now that wcs.UnitConverter wants the "have" unit, which is the of the wcs.wcs_sky2pix() output. How do I canonically get the measurement units of the coordinates returned by wcs_sky2pix()? Regards Ole From mdroe at stsci.edu Mon Apr 4 09:21:38 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Mon, 4 Apr 2011 09:21:38 -0400 Subject: [AstroPy] PyWCS build failure on Windows 7 and Windows XP with EPD In-Reply-To: References: Message-ID: <4D99C5E2.4000806@stsci.edu> Can you apply the attached patch and let me know if it works for you? Mike On 04/03/2011 07:04 PM, Tom Aldcroft wrote: > Hi - > > I'm am unable to build PyWCS on a Windows 7 and Windows XP machines > using the latest EPD 7.0.2. In both cases I get the same compiler > error. Any hints or advice would be most welcome. Below I include > configuration information and the build log. > > Thanks, Tom > > --------------------------------- > > Windows 7 Pro 64bit, 2009, fully updated. > > Python version is 2.7.1 -- EPD 7.0-2 (64bit) > > Here is what I get with "python setup.py install" command from the > directory indicated, where I unzipped the pywcs tar ball: > > C:\Python27\Scripts\pywcs-1.10-4.7>python setup.py install > > running install > running build > running build_py > copying lib\svn_version.py -> build\lib.win-amd64-2.7\pywcs > > running build_ext > building 'pywcs._pywcs' extension > C:\Python27\Scripts\gcc.exe -mno-cygwin -mdll -O -Wall -DMS_WIN64 -DECHO -DWCSTR > IG_MACRO -DPYWCS_BUILD -D_GNU_SOURCE -DNDEBUG -DYY_NO_UNISTD_H -D_CRT_SECURE_NO_ > WARNINGS -UDEBUG -IC:\Python27\lib\site-packages\numpy\core\include -I.\wcslib\C > -Iwcslib\C -I.\src -IC:\Python27\include -IC:\Python27\PC -c wcslib\C\flexed/wc > sbth.c -o build\temp.win-amd64-2.7\Release\wcslib\c\flexed\wcsbth.o > In file included from wcsbth.l:118:0: > .\wcslib\C/wcs.h:1396:5: error: conflicting types for 'wcsset' > c:/python27/egg-info/mingw/usr/lib/gcc/../../x86_64-w64-mingw32/include/string.h > :161:20: note: previous declaration of 'wcsset' was here > wcsbth.l: In function 'wcsbth': > wcsbth.l:2081:1: warning: statement with no effect > wcsbth.l: At top level: > wcsbth.c:19886:16: warning: 'input' defined but not used > error: command 'gcc' failed with exit status 1 > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: win32_fix.diff Type: text/x-patch Size: 818 bytes Desc: not available URL: From mdroe at stsci.edu Mon Apr 4 09:45:15 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Mon, 4 Apr 2011 09:45:15 -0400 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D99B936.4060002@liska.ath.cx> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> <4D99B936.4060002@liska.ath.cx> Message-ID: <4D99CB6B.7040909@stsci.edu> On 04/04/2011 08:27 AM, Ole Streicher wrote: > Dear James, > > Am 01.04.2011 18:30, schrieb James Turner: > >> Oh, sorry, that probably didn't make sense; it couldn't convert to m >> it didn't know what it was. Should think longer before posting... I >> did notice that there's a units class in pywcs (under API >> documentation), so maybe that will help? >> > This helps a bit, thank you. However, my problem is that I want to put > not just the wavelength there but coordinates for all dimensions. > > So, I have a loop like > > for i, s in enumerate(wcs.wcs_pix2sky([origin], 1)[0]): > conv = pywcs.UnitConverter(want = h.header['CUNIT%i' % (i+1)]) > h.header['CRVAL%i' % (i+1)] = conv.convert(s) > h.header['CRPIX%i' % (i+1)] = 1 > > The Problem here is now that wcs.UnitConverter wants the "have" unit, > which is the of the wcs.wcs_sky2pix() output. How do I canonically get > the measurement units of the coordinates returned by wcs_sky2pix()? > > I'm having a little trouble following what you are trying to do. In WCS, the spectral axes values in the file (in pixel space) are in undefined arbitrary units, and the WCS defines a translation from that to a standard unit (of which many are supported) defined in CUNITi. So there's no way to really canonically get the measurement units of the coordinates returned by wcs_sky2pix. To get the units returned by wcs_pix2sky, use wcs.wcs.units[wcs.wcs.spec]. If you want to get the original values back, you can run them through wcs_sky2pix, or just copy them from the original array. In the above example, the "have" argument should be the input unit, and here you are passing the output of pix2sky, so it's in sky space. That unit can be obtained with wcs.wcs.unit[wcs.wcs.spec]. Then your "want" unit can be whatever canonical unit you want to standardize on. I hope this makes sense. Feel free to attach your input FITS file so we can experiment further and get a sense of what you're trying to do. Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA From Gerard.Fitzpatrick at ucdconnect.ie Mon Apr 4 18:48:28 2011 From: Gerard.Fitzpatrick at ucdconnect.ie (Gerard Fitzpatrick) Date: Mon, 04 Apr 2011 23:48:28 +0100 Subject: [AstroPy] PyFits not reading END value from header? Message-ID: <73d0d9a3ec68.4d9a58cc@ucd.ie> Hello all, I've run into a small problem with pyfits. I am not sure if this is a problem or simply down to my ignorance!? I am reading in ?a header and table data from one file, then appending it to another. The code throws an error: IOError: Header missing END card. I can print the header and see that it is missing the End value. I have tried this on three different fits files and continually run into the same problem, this leads me to suspect that there is a subtlety that I am missing.? I am using version 2.3.1 on ubuntu 10.10 The code is something like this: import pyfits as pf file='blah.fits' fits_file=pf.open(file) hdr_1=fits_file[1].header table_1=fits_file[1].data fits_file.close() pf.update('test.fits',table_1,hdr_1) In place of pf.update I have also tried pf.append & pf.writeto. Regards, G -------------- next part -------------- An HTML attachment was scrubbed... URL: From astropy at liska.ath.cx Tue Apr 5 03:16:24 2011 From: astropy at liska.ath.cx (Ole Streicher) Date: Tue, 05 Apr 2011 09:16:24 +0200 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D99CB6B.7040909@stsci.edu> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> <4D99B936.4060002@liska.ath.cx> <4D99CB6B.7040909@stsci.edu> Message-ID: <4D9AC1C8.1050607@liska.ath.cx> Dear Michael, Am 04.04.2011 15:45, schrieb Michael Droettboom: > I'm having a little trouble following what you are trying to do. I am going to write a small program to cut out parts of an 2d/3d image based on WCS coordinates and/or wavelength. The easy part is now to convert these coordinates into pixel coords using pywcs and slicing the required part of the image. But the resulting image needs now a new WCS header since the origin may have been changed, and I am wondering how one could easily built one. For CRVALx I have to calculate the world coordinates of the origin of the resulting image within the coordinate system of the primary image, in the units defined by CUNITx. > To get the units returned by wcs_pix2sky, use wcs.wcs.units[wcs.wcs.spec]. This is what I needed, thank you (wcs.wcs.cunit). BTW, I would propose to implement an iterator there (or as wcs.unit)? Best regards Ole From nico.nell at gmail.com Tue Apr 5 03:33:56 2011 From: nico.nell at gmail.com (Nico Nell) Date: Tue, 5 Apr 2011 01:33:56 -0600 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D9AC1C8.1050607@liska.ath.cx> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> <4D99B936.4060002@liska.ath.cx> <4D99CB6B.7040909@stsci.edu> <4D9AC1C8.1050607@liska.ath.cx> Message-ID: Ole: This can be done easily with astLib (http://astlib.sourceforge.net/). See function clipImageSectionWCS (http://astlib.sourceforge.net/docs/astLib/astLib.astImages-module.html#clipImageSectionWCS). Here is an example that I used to make clips from big GALEX fits files (http://casa.colorado.edu/~nell/cgit/cgit.cgi/pyscripts/tree/plotting/galex-clips.py) Hopefully this makes things easier for you! ~Nico On Tue, Apr 5, 2011 at 1:16 AM, Ole Streicher wrote: > Dear Michael, > > Am 04.04.2011 15:45, schrieb Michael Droettboom: >> I'm having a little trouble following what you are trying to do. > > I am going to write a small program to cut out parts of an 2d/3d image > based on WCS coordinates and/or wavelength. > > The easy part is now to convert these coordinates into pixel coords > using pywcs and slicing the required part of the image. > > But the resulting image needs now a new WCS header since the origin may > have been changed, and I am wondering how one could easily built one. > For CRVALx I have to calculate the world coordinates of the origin of > the resulting image within the coordinate system of the primary image, > in the units defined by CUNITx. > >> To get the units returned by wcs_pix2sky, use wcs.wcs.units[wcs.wcs.spec]. > > This is what I needed, thank you (wcs.wcs.cunit). BTW, I would propose > to implement an iterator there (or as wcs.unit)? > > Best regards > > Ole > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From astropy at liska.ath.cx Tue Apr 5 06:18:22 2011 From: astropy at liska.ath.cx (Ole Streicher) Date: Tue, 05 Apr 2011 12:18:22 +0200 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> <4D99B936.4060002@liska.ath.cx> <4D99CB6B.7040909@stsci.edu> <4D9AC1C8.1050607@liska.ath.cx> Message-ID: <4D9AEC6E.2040208@liska.ath.cx> Am 05.04.2011 09:33, schrieb Nico Nell: > This can be done easily with astLib (http://astlib.sourceforge.net/). > See function clipImageSectionWCS > (http://astlib.sourceforge.net/docs/astLib/astLib.astImages-module.html#clipImageSectionWCS). > > Here is an example that I used to make clips from big GALEX fits files > (http://casa.colorado.edu/~nell/cgit/cgit.cgi/pyscripts/tree/plotting/galex-clips.py) > > Hopefully this makes things easier for you! Thank you, Nico. However, I started now using pywcs, and I would probably stick to that unless I cannot use the problem with it. I am still quite confused why there are parallel packages doing mainly the same thing: astLib and astrolib are quite for the same purpose, and having both f.e. a wcslib wrapper. In my opinion, this parallel development seems to me quite unnecessary and delays cooperation since everyone historically uses his own preferred library. For different programming languages, I could understand this, but I dont see a real reason to have different pywcs modules. Are there any attempts to unify the different approaches for astro(python|lib)? What is the common opinion about the fragmentation problem? Cheers Ole From perry at stsci.edu Tue Apr 5 08:04:45 2011 From: perry at stsci.edu (Perry Greenfield) Date: Tue, 5 Apr 2011 08:04:45 -0400 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D9AEC6E.2040208@liska.ath.cx> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> <4D99B936.4060002@liska.ath.cx> <4D99CB6B.7040909@stsci.edu> <4D9AC1C8.1050607@liska.ath.cx> <4D9AEC6E.2040208@liska.ath.cx> Message-ID: On Apr 5, 2011, at 6:18 AM, Ole Streicher wrote: > Am 05.04.2011 09:33, schrieb Nico Nell: >> This can be done easily with astLib (http://astlib.sourceforge.net/). >> See function clipImageSectionWCS >> (http://astlib.sourceforge.net/docs/astLib/astLib.astImages-module.html#clipImageSectionWCS >> ). >> >> Here is an example that I used to make clips from big GALEX fits >> files >> (http://casa.colorado.edu/~nell/cgit/cgit.cgi/pyscripts/tree/plotting/galex-clips.py >> ) >> >> Hopefully this makes things easier for you! > > Thank you, Nico. > > However, I started now using pywcs, and I would probably stick to that > unless I cannot use the problem with it. > > I am still quite confused why there are parallel packages doing mainly > the same thing: astLib and astrolib are quite for the same purpose, > and > having both f.e. a wcslib wrapper. In my opinion, this parallel > development seems to me quite unnecessary and delays cooperation since > everyone historically uses his own preferred library. For different > programming languages, I could understand this, but I dont see a real > reason to have different pywcs modules. > > Are there any attempts to unify the different approaches for > astro(python|lib)? What is the common opinion about the fragmentation > problem? Actually, I'd like to help such a unification. WCS seems like an obvious place to start (it's not the only case though). Mind you, I'm not adverse to people trying different approaches early on to see what works best, but after some point consolidation is usually a good idea. So perhaps this is a good starting point for doing so with WCS. I haven't studied the details of this particular instance that much, but it certainly makes sense that one should be able to easily generate a new WCS for a subarray. If pywcs can't do that yet, we should add that capability. To the maintainers of the other wcs packages, what capabilities do you think pywcs is missing? Is there some way of merging the missing capabilities? Or is there a disagreement on the proper object model or interfaces? This seems like a good time to start such a discussion. Perry From mdroe at stsci.edu Tue Apr 5 07:45:59 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 5 Apr 2011 07:45:59 -0400 Subject: [AstroPy] PyWCS build failure on Windows 7 and Windows XP with EPD In-Reply-To: References: <4D99C5E2.4000806@stsci.edu> Message-ID: <4D9B00F7.60504@stsci.edu> There must be some difference in the mingw32 headers you have and the ones I have (I'm on 32-bit and you seem to be on 64-bit, though I don't know if that's relevant.) In my headers, the _NO_OLDNAMES #define turns off definining the deprecated "wcsset" function in the MS non-standard string library -- MS takes "wcs" to mean "wide character string" :) Can you send me (off list) a copy of this file? c:/python27/egg-info/mingw/usr/lib/gcc/../../x86_64-w64-mingw32/include/string.h Mike On 04/04/2011 03:00 PM, Tom Aldcroft wrote: > Hi Mike, > > No joy on the install with the new defsetup.py file: > > C:\Python27\Scripts\pywcs-1.10-4.7>python setup.py install > running install > running build > running build_py > copying lib\svn_version.py -> build\lib.win-amd64-2.7\pywcs > running build_ext > building 'pywcs._pywcs' extension > C:\Python27\Scripts\gcc.exe -mno-cygwin -mdll -O -Wall -DMS_WIN64 -DECHO -DWCSTR > IG_MACRO -DPYWCS_BUILD -D_GNU_SOURCE -DNDEBUG -DYY_NO_UNISTD_H -D_CRT_SECURE_NO_ > WARNINGS -D_NO_OLDNAMES -UDEBUG -IC:\Python27\lib\site-packages\numpy\core\inclu > de -I.\wcslib\C -Iwcslib\C -I.\src -IC:\Python27\include -IC:\Python27\PC -c wcs > lib\C\flexed/wcsbth.c -o build\temp.win-amd64-2.7\Release\wcslib\c\flexed\wcsbth > > .o > In file included from wcsbth.l:118:0: > .\wcslib\C/wcs.h:1396:5: error: conflicting types for 'wcsset' > c:/python27/egg-info/mingw/usr/lib/gcc/../../x86_64-w64-mingw32/include/string.h > :161:20: note: previous declaration of 'wcsset' was here > wcsbth.l: In function 'wcsbth': > wcsbth.l:2081:1: warning: statement with no effect > wcsbth.l: At top level: > wcsbth.c:19886:16: warning: 'input' defined but not used > error: command 'gcc' failed with exit status 1 > > The error looks basically the same, although the presence of the > -D_NO_OLDNAMES in the build log indicates that the patch was applied > and that the new defsetup.py was being used. > > - Tom > > On Mon, Apr 4, 2011 at 9:21 AM, Michael Droettboom wrote: > >> Can you apply the attached patch and let me know if it works for you? >> >> Mike >> >> On 04/03/2011 07:04 PM, Tom Aldcroft wrote: >> >>> Hi - >>> >>> I'm am unable to build PyWCS on a Windows 7 and Windows XP machines >>> using the latest EPD 7.0.2. In both cases I get the same compiler >>> error. Any hints or advice would be most welcome. Below I include >>> configuration information and the build log. >>> >>> Thanks, Tom >>> >>> --------------------------------- >>> >>> Windows 7 Pro 64bit, 2009, fully updated. >>> >>> Python version is 2.7.1 -- EPD 7.0-2 (64bit) >>> >>> Here is what I get with "python setup.py install" command from the >>> directory indicated, where I unzipped the pywcs tar ball: >>> >>> C:\Python27\Scripts\pywcs-1.10-4.7>python setup.py install >>> >>> running install >>> running build >>> running build_py >>> copying lib\svn_version.py -> build\lib.win-amd64-2.7\pywcs >>> >>> running build_ext >>> building 'pywcs._pywcs' extension >>> C:\Python27\Scripts\gcc.exe -mno-cygwin -mdll -O -Wall -DMS_WIN64 -DECHO >>> -DWCSTR >>> IG_MACRO -DPYWCS_BUILD -D_GNU_SOURCE -DNDEBUG -DYY_NO_UNISTD_H >>> -D_CRT_SECURE_NO_ >>> WARNINGS -UDEBUG -IC:\Python27\lib\site-packages\numpy\core\include >>> -I.\wcslib\C >>> -Iwcslib\C -I.\src -IC:\Python27\include -IC:\Python27\PC -c >>> wcslib\C\flexed/wc >>> sbth.c -o build\temp.win-amd64-2.7\Release\wcslib\c\flexed\wcsbth.o >>> In file included from wcsbth.l:118:0: >>> .\wcslib\C/wcs.h:1396:5: error: conflicting types for 'wcsset' >>> >>> c:/python27/egg-info/mingw/usr/lib/gcc/../../x86_64-w64-mingw32/include/string.h >>> :161:20: note: previous declaration of 'wcsset' was here >>> wcsbth.l: In function 'wcsbth': >>> wcsbth.l:2081:1: warning: statement with no effect >>> wcsbth.l: At top level: >>> wcsbth.c:19886:16: warning: 'input' defined but not used >>> error: command 'gcc' failed with exit status 1 >>> _______________________________________________ >>> 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 >> >> >> -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA From mdroe at stsci.edu Tue Apr 5 07:56:43 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 5 Apr 2011 07:56:43 -0400 Subject: [AstroPy] PyFits not reading END value from header? In-Reply-To: <73d0d9a3ec68.4d9a58cc@ucd.ie> References: <73d0d9a3ec68.4d9a58cc@ucd.ie> Message-ID: <4D9B037B.1000003@stsci.edu> Can you send me (off list) the input fits files you are using? For me, with your example code, pyfits rightfully complains since an extension HDU is being put in the zero'th place. Cheers, Mike In [6]: pf.update('test.fits',table_1,hdr_1) --------------------------------------------------------------------------- VerifyError Traceback (most recent call last) /wonkabar/sc1/scraps/fitswriter_data/miri/ in () ----> 1 pf.update('test.fits',table_1,hdr_1) /home/mdroe/usr/lib/python2.7/site-packages/pyfits/core.pyc in update(filename, data, *ext, **extkeys) 11030 hdulist[_ext] = new_hdu 11031 > 11032 hdulist.close(closed=closed) 11033 11034 /home/mdroe/usr/lib/python2.7/site-packages/pyfits/core.pyc in close(self, output_verify, verbose, closed) 10192 if self.__file != None: 10193 if self.__file.mode in ['append', 'update']: > 10194 self.flush(output_verify=output_verify, verbose=verbose) 10195 10196 if closed and hasattr(self.__file, 'close'): /home/mdroe/usr/lib/python2.7/site-packages/pyfits/core.pyc in flush(self, output_verify, verbose, classExtensions) 9843 9844 self.update_tbhdu() -> 9845 self.verify(option=output_verify) 9846 9847 if self.__file.mode in ('append', 'ostream'): /home/mdroe/usr/lib/python2.7/site-packages/pyfits/core.pyc in verify(self, option) 259 warnings.warn(x) 260 if _option == 'exception' and x: --> 261 raise VerifyError, '\n'+x 262 263 def _pad(input): VerifyError: HDUList's 0th element is not a primary HDU. On 04/04/2011 06:48 PM, Gerard Fitzpatrick wrote: > > Hello all, > > > I've run into a small problem with pyfits. I am not sure if this is a > problem or simply down to my ignorance! > > > I am reading in a header and table data from one file, then appending > it to another. The code throws an error: IOError: Header missing END > card. I can print the header and see that it is missing the End value. > I have tried this on three different fits files and continually run > into the same problem, this leads me to suspect that there is a > subtlety that I am missing. > > > I am using version 2.3.1 on ubuntu 10.10 > > > The code is something like this: > > > import pyfits as pf > > > file='blah.fits' > fits_file=pf.open(file) > hdr_1=fits_file[1].header > table_1=fits_file[1].data > fits_file.close() > pf.update('test.fits',table_1,hdr_1) > > > > > > > In place of pf.update I have also tried pf.append & pf.writeto. > > > Regards, > > > G > > > _______________________________________________ > 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 Tue Apr 5 08:02:12 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 5 Apr 2011 08:02:12 -0400 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D9AC1C8.1050607@liska.ath.cx> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> <4D99B936.4060002@liska.ath.cx> <4D99CB6B.7040909@stsci.edu> <4D9AC1C8.1050607@liska.ath.cx> Message-ID: <4D9B04C4.2010607@stsci.edu> On 04/05/2011 03:16 AM, Ole Streicher wrote: > Dear Michael, > > Am 04.04.2011 15:45, schrieb Michael Droettboom: > >> I'm having a little trouble following what you are trying to do. >> > I am going to write a small program to cut out parts of an 2d/3d image > based on WCS coordinates and/or wavelength. > > The easy part is now to convert these coordinates into pixel coords > using pywcs and slicing the required part of the image. > > But the resulting image needs now a new WCS header since the origin may > have been changed, and I am wondering how one could easily built one. > For CRVALx I have to calculate the world coordinates of the origin of > the resulting image within the coordinate system of the primary image, > in the units defined by CUNITx. > I see. That makes sense. So the user input is in some unit, and you need to get to the world units used by the existing WCS. The UnitConverter class with have = input_unit (whatever that may be) and want = wcs.wcs.cuint[wcs.wcs.spec] should do what you need. > >> To get the units returned by wcs_pix2sky, use wcs.wcs.units[wcs.wcs.spec]. >> > This is what I needed, thank you (wcs.wcs.cunit). BTW, I would propose > to implement an iterator there (or as wcs.unit)? > I'm not sure what you mean by having an iterator there. Right now it returns a list, with one entry for each axis. As the number of axes is always really small, I'm not sure what advantage an iterator would have. Cheers, Mike > Best regards > > Ole > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA From astropy at liska.ath.cx Tue Apr 5 10:22:59 2011 From: astropy at liska.ath.cx (Ole Streicher) Date: Tue, 05 Apr 2011 16:22:59 +0200 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D9B04C4.2010607@stsci.edu> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> <4D99B936.4060002@liska.ath.cx> <4D99CB6B.7040909@stsci.edu> <4D9AC1C8.1050607@liska.ath.cx> <4D9B04C4.2010607@stsci.edu> Message-ID: <4D9B25C3.3020807@liska.ath.cx> Am 05.04.2011 14:02, schrieb Michael Droettboom: > On 04/05/2011 03:16 AM, Ole Streicher wrote: >> But the resulting image needs now a new WCS header since the origin may >> have been changed, and I am wondering how one could easily built one. >> For CRVALx I have to calculate the world coordinates of the origin of >> the resulting image within the coordinate system of the primary image, >> in the units defined by CUNITx. >> > I see. That makes sense. So the user input is in some unit, and you > need to get to the world units used by the existing WCS. The > UnitConverter class with have = input_unit (whatever that may be) and > want = wcs.wcs.cuint[wcs.wcs.spec] should do what you need. Yes, this is what I do now, and it works fine. >> This is what I needed, thank you (wcs.wcs.cunit). BTW, I would propose >> to implement an iterator there (or as wcs.unit)? > I'm not sure what you mean by having an iterator there. Right now it > returns a list, with one entry for each axis. As the number of axes is > always really small, I'm not sure what advantage an iterator would have. The code snipped that does the conversion was supposed to be like: ----------------8<--------------------------------------------------- origin_sky = wcs.wcs_pix2sky([ origin ], 1)[0] fits_units = [ hdu.header['CUNIT%i' % (i+1)] for i in range(len(origin_sky)) ] crval_keys = [ 'CRVAL%i' % (i+1) for i in range(len(origin_sky)) ] for value, unit, fitsunit, key in zip(origin_sky, wcs.wcs.cunit, fits_units, crval_keys): conv = pywcs.UnitConverter(have = unit, want = fitsunit) hdu.header[key] = conv.convert([value])[0] ----------------8<--------------------------------------------------- but this does not work since wcs.wcs.cunit has indexing but is not a list. Even builing a list like list(wcs.wcs.cunit) does not work here. This is not a big problem since using wcs_units = [ wcs.wcs.cunit[i] for i in len(wcs.wcs.cunit) ] works well; however I would prefer to iterate directly over the list. I could have a look into str_list_proxy.c and provide you a patch, if I find some time? Regards Ole From mdroe at stsci.edu Tue Apr 5 09:26:54 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 5 Apr 2011 09:26:54 -0400 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D9B25C3.3020807@liska.ath.cx> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> <4D99B936.4060002@liska.ath.cx> <4D99CB6B.7040909@stsci.edu> <4D9AC1C8.1050607@liska.ath.cx> <4D9B04C4.2010607@stsci.edu> <4D9B25C3.3020807@liska.ath.cx> Message-ID: <4D9B189E.2060005@stsci.edu> On 04/05/2011 10:22 AM, Ole Streicher wrote: > but this does not work since wcs.wcs.cunit has indexing but is not a > list. Even builing a list like list(wcs.wcs.cunit) does not work here. > > This is not a big problem since using > > wcs_units = [ wcs.wcs.cunit[i] for i in len(wcs.wcs.cunit) ] > > works well; however I would prefer to iterate directly over the list. > I could have a look into str_list_proxy.c and provide you a patch, if I > find some time? > Ah -- I understand your question now. I will look into this and keep you posted on progress. Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA From mperrin at stsci.edu Tue Apr 5 10:45:06 2011 From: mperrin at stsci.edu (Marshall Perrin) Date: Tue, 5 Apr 2011 14:45:06 +0000 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D9AEC6E.2040208@liska.ath.cx> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> <4D99B936.4060002@liska.ath.cx> <4D99CB6B.7040909@stsci.edu> <4D9AC1C8.1050607@liska.ath.cx> <4D9AEC6E.2040208@liska.ath.cx> Message-ID: On Apr 5, 2011, at 4:18 AM, Ole Streicher wrote: > I am still quite confused why there are parallel packages doing mainly > the same thing: astLib and astrolib are quite for the same purpose, and > having both f.e. a wcslib wrapper. In my opinion, this parallel > development seems to me quite unnecessary and delays cooperation since > everyone historically uses his own preferred library. For different > programming languages, I could understand this, but I dont see a real > reason to have different pywcs modules. > > Are there any attempts to unify the different approaches for > astro(python|lib)? What is the common opinion about the fragmentation > problem? This is not a new concern (see http://mail.scipy.org/pipermail/astropy/2009-June/000841.html ) , but it seems that the community is still lacking sufficient impetus to make any unification/simplification a real priority. Hopefully with time, though... - Marshall From mdroe at stsci.edu Tue Apr 5 11:36:36 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 5 Apr 2011 11:36:36 -0400 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D9B189E.2060005@stsci.edu> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> <4D99B936.4060002@liska.ath.cx> <4D99CB6B.7040909@stsci.edu> <4D9AC1C8.1050607@liska.ath.cx> <4D9B04C4.2010607@stsci.edu> <4D9B25C3.3020807@liska.ath.cx> <4D9B189E.2060005@stsci.edu> Message-ID: <4D9B3704.5010300@stsci.edu> On 04/05/2011 09:26 AM, Michael Droettboom wrote: > On 04/05/2011 10:22 AM, Ole Streicher wrote: > >> but this does not work since wcs.wcs.cunit has indexing but is not a >> list. Even builing a list like list(wcs.wcs.cunit) does not work here. >> >> This is not a big problem since using >> >> wcs_units = [ wcs.wcs.cunit[i] for i in len(wcs.wcs.cunit) ] >> >> works well; however I would prefer to iterate directly over the list. >> I could have a look into str_list_proxy.c and provide you a patch, if I >> find some time? >> >> > Ah -- I understand your question now. I will look into this and keep > you posted on progress. > > > Hmm. Once looking into this, it seems this works for me -- Python creates an implicit iterator when __getitem__ and __len__ are defined. What version of pywcs and Python are you using? In [1]: import pywcs In [2]: wcs = pywcs.WCS() In [3]: wcs.wcs.cunit Out[3]: ['', ''] In [4]: type(wcs.wcs.cunit) Out[4]: pywcs.StrListProxy In [5]: for x in wcs.wcs.cunit: ...: print repr(x) ...: '' '' In [6]: list(wcs.wcs.cunit) Out[6]: ['', ''] Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA From jslavin at cfa.harvard.edu Tue Apr 5 14:32:16 2011 From: jslavin at cfa.harvard.edu (Jonathan Slavin) Date: Tue, 05 Apr 2011 14:32:16 -0400 Subject: [AstroPy] all-sky map Message-ID: <1302028336.498.23.camel@shevek> To all: I'm looking for a way to plot an all-sky map of modeled data using a Hammer-Aitoff projection. The way I've done this in IDL is to create a uniform x-y grid, translate that l, b using the proper conversion for an Aitoff projection and generate the data on that grid. I then display the image and overlay an Aitoff grid (which I also generate). So the image is rectangular and extends beyond the plot edges. That is fine, but then all the labeling, etc. has to be done by hand. Is there an easier way? Any help would be appreciated. Thanks, 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 William.T.Bridgman at nasa.gov Tue Apr 5 14:42:36 2011 From: William.T.Bridgman at nasa.gov (Bridgman, William T.) Date: Tue, 5 Apr 2011 14:42:36 -0400 Subject: [AstroPy] all-sky map In-Reply-To: <1302028336.498.23.camel@shevek> References: <1302028336.498.23.camel@shevek> Message-ID: Are you looking for the labeling or the reprojection? These were done with Python http://svs.gsfc.nasa.gov/vis/a000000/a003700/a003769/index.html http://svs.gsfc.nasa.gov/vis/a000000/a003700/a003702/index.html I've used PIL for labeling on images. Tom On Apr 5, 2011, at 2:32 PM, Jonathan Slavin wrote: > To all: > > I'm looking for a way to plot an all-sky map of modeled data using a > Hammer-Aitoff projection. The way I've done this in IDL is to > create a > uniform x-y grid, translate that l, b using the proper conversion > for an > Aitoff projection and generate the data on that grid. I then display > the image and overlay an Aitoff grid (which I also generate). So the > image is rectangular and extends beyond the plot edges. That is fine, > but then all the labeling, etc. has to be done by hand. Is there an > easier way? Any help would be appreciated. > > Thanks, > 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 -- Dr. William T."Tom" Bridgman Scientific Visualization Studio Global Science & Technology, Inc. NASA/Goddard Space Flight Center Email: William.T.Bridgman at nasa.gov Code 610.3 Phone: 301-286-1346 Greenbelt, MD 20771 FAX: 301-286-1634 http://svs.gsfc.nasa.gov/ From mperrin at stsci.edu Tue Apr 5 14:50:45 2011 From: mperrin at stsci.edu (Marshall Perrin) Date: Tue, 5 Apr 2011 18:50:45 +0000 Subject: [AstroPy] all-sky map In-Reply-To: <1302028336.498.23.camel@shevek> References: <1302028336.498.23.camel@shevek> Message-ID: On Apr 5, 2011, at 12:32 PM, Jonathan Slavin wrote: > I'm looking for a way to plot an all-sky map of modeled data using a > Hammer-Aitoff projection. The way I've done this in IDL is to create a > uniform x-y grid, translate that l, b using the proper conversion for an > Aitoff projection and generate the data on that grid. I then display > the image and overlay an Aitoff grid (which I also generate). So the > image is rectangular and extends beyond the plot edges. That is fine, > but then all the labeling, etc. has to be done by hand. Is there an > easier way? Any help would be appreciated. Check out the matplotlib mpl_toolkits.basemap module. The Basemap class implements a user-selectable map projection, and yields a callable object which handles the translation between projection coordinate systems and x,y positions for plotting. Here is some code I recently wrote to do a similar task, plotting positions of objects on an all-sky Mollweide projection: # define base map class. map = Basemap(projection='moll', lat_0 = 0, lon_0 = 0, resolution = None) # do *NOT* draw Earth continents at any resolution! map.drawmapboundary() p.title("Equatorial coordinates J2000") # draw and label ra/dec grid lines every 30 degrees. degtoralabel = lambda deg : "%+d$^h$" % int(deg/15) degtodeclabel = lambda deg : "%+d$^\circ$" % deg map.drawparallels(n.arange(-90, 90, 30), fmt=degtodeclabel, labels=[1,0,0,0]) map.drawmeridians(n.arange(0, 360, 30) ) # label these manually since I don't like the default label positions: # this also demonstrates how to overplot text on map coordinates... for h in [0,6,12,18]: x,y = map(h*15,0) p.text(x,y, degtoralabel(h*15)) # draw data points px, py = map(data.radeg, data.dedeg) map.plot(px, py, "o", color="red") From ejensen1 at swarthmore.edu Tue Apr 5 14:55:04 2011 From: ejensen1 at swarthmore.edu (Eric Jensen) Date: Tue, 5 Apr 2011 14:55:04 -0400 Subject: [AstroPy] all-sky map In-Reply-To: <1302028336.498.23.camel@shevek> References: <1302028336.498.23.camel@shevek> Message-ID: Hi Jonathan, > I'm looking for a way to plot an all-sky map of modeled data using a > Hammer-Aitoff projection. You can do this using matplotlib.pyplot.subplot (http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.subplot ) by passing "projection='aitoff' " : subplot(212, projection='aitoff') # Pass the coordinates in radians, since otherwise the # aitoff projection messes up: deg2rad = pi/180. plot(l*deg2rad, b*deg2rad, 'g*') grid(True) text(0,-120*deg2rad,'Galactic longitude (degrees)', ha='center', va='center') ylabel('Galactic latitude (degrees)') show() Eric P.S. I'm not sure about subtleties of differences (if any) between Aitoff and Hammer-Aitoff, but presumably this is close to what you want. From matthewturk at gmail.com Tue Apr 5 14:56:35 2011 From: matthewturk at gmail.com (Matthew Turk) Date: Tue, 5 Apr 2011 14:56:35 -0400 Subject: [AstroPy] all-sky map In-Reply-To: References: <1302028336.498.23.camel@shevek> Message-ID: Hi Marsall, On Tue, Apr 5, 2011 at 2:50 PM, Marshall Perrin wrote: > On Apr 5, 2011, at 12:32 PM, Jonathan Slavin wrote: >> I'm looking for a way to plot an all-sky map of modeled data using a >> Hammer-Aitoff projection. ?The way I've done this in IDL is to create a >> uniform x-y grid, translate that l, b using the proper conversion for an >> Aitoff projection and generate the data on that grid. ?I then display >> the image and overlay an Aitoff grid (which I also generate). ?So the >> image is rectangular and extends beyond the plot edges. ?That is fine, >> but then all the labeling, etc. has to be done by hand. ?Is there an >> easier way? ?Any help would be appreciated. > > > Check out the matplotlib mpl_toolkits.basemap module. ? The Basemap class implements a user-selectable map projection, and yields a callable object which handles the translation between projection coordinate systems and x,y positions for plotting. ? Here is some code I recently wrote to do a similar task, plotting positions of objects on an all-sky Mollweide projection: In theory one should be able to get this going with just the standard Matplotlib projections, without basemap, which has a huge dependency set. There seems to be a bug if you don't set the figure to have aspect ratio 2:1, but this code works for me, where img is a square array. import matplotlib.figure import matplotlib.backends.backend_agg fig = matplotlib.figure.Figure((10, 5)) ax = fig.add_subplot(1,1,1,projection='mollweide') image = ax.imshow(img, extent=(-pi,pi,-pi/2,pi/2), clip_on=False, aspect=0.5) cb = fig.colorbar(image, orientation='horizontal') cb.set_label(r"$\mathrm{Column}\/\mathrm{Density}\/[\mathrm{g}/\mathrm{cm}^2]$") canvas = matplotlib.backends.backend_agg.FigureCanvasAgg(fig) canvas.print_figure("allsky.png") (a bit more discussion: http://blog.enzotools.org/yt-development-all-sky-column-density-calcula ) If anybody knows why the figure size has to be 2:1 to avoid a blank image, I'd really appreciate a tip. -Matt > > ? ? ? ?# define base map class. > ? ? ? ?map = Basemap(projection='moll', lat_0 = 0, lon_0 = 0, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?resolution = None) ?# do *NOT* draw Earth continents at any resolution! > ? ? ? ?map.drawmapboundary() > ? ? ? ?p.title("Equatorial coordinates J2000") > > ? ? ? ?# draw and label ra/dec grid lines every 30 degrees. > ? ? ? ?degtoralabel = lambda deg : "%+d$^h$" % int(deg/15) > ? ? ? ?degtodeclabel = lambda deg : "%+d$^\circ$" % deg > ? ? ? ?map.drawparallels(n.arange(-90, 90, 30), fmt=degtodeclabel, labels=[1,0,0,0]) > ? ? ? ?map.drawmeridians(n.arange(0, 360, 30) ) ?# label these manually since I don't like the default label positions: > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# this also demonstrates how to overplot text on map coordinates... > ? ? ? ?for h in [0,6,12,18]: > ? ? ? ? ? ?x,y = map(h*15,0) > ? ? ? ? ? ?p.text(x,y, degtoralabel(h*15)) > > ? ? ? ?# draw data points > ? ? ? ?px, py = map(data.radeg, data.dedeg) > ? ? ? ?map.plot(px, py, "o", color="red") > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From astropy at liska.ath.cx Wed Apr 6 03:07:47 2011 From: astropy at liska.ath.cx (Ole Streicher) Date: Wed, 06 Apr 2011 09:07:47 +0200 Subject: [AstroPy] [pywcs] Unit question In-Reply-To: <4D9B3704.5010300@stsci.edu> References: <4D95CD0F.7080801@liska.ath.cx> <4D95FC34.4050603@gemini.edu> <4D95FD88.7000808@gemini.edu> <4D99B936.4060002@liska.ath.cx> <4D99CB6B.7040909@stsci.edu> <4D9AC1C8.1050607@liska.ath.cx> <4D9B04C4.2010607@stsci.edu> <4D9B25C3.3020807@liska.ath.cx> <4D9B189E.2060005@stsci.edu> <4D9B3704.5010300@stsci.edu> Message-ID: <4D9C1143.3040109@liska.ath.cx> Am 05.04.2011 17:36, schrieb Michael Droettboom: > Hmm. Once looking into this, it seems this works for me -- Python > creates an implicit iterator when __getitem__ and __len__ are defined. > What version of pywcs and Python are you using? > In [6]: list(wcs.wcs.cunit) > Out[6]: ['', ''] I must apologize; I cannot reproduce this anymore, even on the same computer. Sorry for the confusion. Regards Ole From erik.tollerud at gmail.com Wed Apr 6 08:49:10 2011 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 6 Apr 2011 09:49:10 -0300 Subject: [AstroPy] all-sky map In-Reply-To: References: <1302028336.498.23.camel@shevek> Message-ID: > If anybody knows why the figure size has to be 2:1 to avoid a blank > image, I'd really appreciate a tip. Maybe this is a version problem? If I do the following with matplotlib 1.0.1: import matplotlib matplotlib.use('agg') #I tried a few other backends and got the same result from matplotlib.pyplot import figure,axes,imshow,savefig from numpy.random import randn from math import pi img = randn(100,100) figure(figsize=(10,5)) imshow(img,extent=(-pi,pi,-pi/2,pi/2)) savefig('filename.png') I get this result: http://dl.dropbox.com/u/8683962/moll-agg1.png And if I add aspect=.5 to the imshow call, I get http://dl.dropbox.com/u/8683962/moll-agg12.png Clearly it is not blank in either case, although the second case is presumably is what you want. On Tue, Apr 5, 2011 at 3:56 PM, Matthew Turk wrote: > Hi Marsall, > > On Tue, Apr 5, 2011 at 2:50 PM, Marshall Perrin wrote: >> On Apr 5, 2011, at 12:32 PM, Jonathan Slavin wrote: >>> I'm looking for a way to plot an all-sky map of modeled data using a >>> Hammer-Aitoff projection. ?The way I've done this in IDL is to create a >>> uniform x-y grid, translate that l, b using the proper conversion for an >>> Aitoff projection and generate the data on that grid. ?I then display >>> the image and overlay an Aitoff grid (which I also generate). ?So the >>> image is rectangular and extends beyond the plot edges. ?That is fine, >>> but then all the labeling, etc. has to be done by hand. ?Is there an >>> easier way? ?Any help would be appreciated. >> >> >> Check out the matplotlib mpl_toolkits.basemap module. ? The Basemap class implements a user-selectable map projection, and yields a callable object which handles the translation between projection coordinate systems and x,y positions for plotting. ? Here is some code I recently wrote to do a similar task, plotting positions of objects on an all-sky Mollweide projection: > > In theory one should be able to get this going with just the standard > Matplotlib projections, without basemap, which has a huge dependency > set. ?There seems to be a bug if you don't set the figure to have > aspect ratio 2:1, but this code works for me, where img is a square > array. > > import matplotlib.figure > import matplotlib.backends.backend_agg > > fig = matplotlib.figure.Figure((10, 5)) > ax = fig.add_subplot(1,1,1,projection='mollweide') > image = ax.imshow(img, extent=(-pi,pi,-pi/2,pi/2), clip_on=False, aspect=0.5) > cb = fig.colorbar(image, orientation='horizontal') > > cb.set_label(r"$\mathrm{Column}\/\mathrm{Density}\/[\mathrm{g}/\mathrm{cm}^2]$") > canvas = matplotlib.backends.backend_agg.FigureCanvasAgg(fig) > canvas.print_figure("allsky.png") > > (a bit more discussion: > http://blog.enzotools.org/yt-development-all-sky-column-density-calcula > ) > > If anybody knows why the figure size has to be 2:1 to avoid a blank > image, I'd really appreciate a tip. > > -Matt > >> >> ? ? ? ?# define base map class. >> ? ? ? ?map = Basemap(projection='moll', lat_0 = 0, lon_0 = 0, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?resolution = None) ?# do *NOT* draw Earth continents at any resolution! >> ? ? ? ?map.drawmapboundary() >> ? ? ? ?p.title("Equatorial coordinates J2000") >> >> ? ? ? ?# draw and label ra/dec grid lines every 30 degrees. >> ? ? ? ?degtoralabel = lambda deg : "%+d$^h$" % int(deg/15) >> ? ? ? ?degtodeclabel = lambda deg : "%+d$^\circ$" % deg >> ? ? ? ?map.drawparallels(n.arange(-90, 90, 30), fmt=degtodeclabel, labels=[1,0,0,0]) >> ? ? ? ?map.drawmeridians(n.arange(0, 360, 30) ) ?# label these manually since I don't like the default label positions: >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# this also demonstrates how to overplot text on map coordinates... >> ? ? ? ?for h in [0,6,12,18]: >> ? ? ? ? ? ?x,y = map(h*15,0) >> ? ? ? ? ? ?p.text(x,y, degtoralabel(h*15)) >> >> ? ? ? ?# draw data points >> ? ? ? ?px, py = map(data.radeg, data.dedeg) >> ? ? ? ?map.plot(px, py, "o", color="red") >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Erik Tollerud From samskillman at gmail.com Wed Apr 6 08:55:07 2011 From: samskillman at gmail.com (Sam Skillman) Date: Wed, 6 Apr 2011 08:55:07 -0400 Subject: [AstroPy] yt 2.1 Release Announcement Message-ID: We are proud to announce the release of yt version 2.1. This release includes several new features, bug fixes, and numerous improvements to the code base and documentation. At the yt homepage, http://yt.enzotools.org/ , an installation script, a cookbook, documentation and a guide to getting involved can be found. yt is an analysis and visualization toolkit for Adaptive Mesh Refinement data. yt provides full support for Enzo, Orion, and FLASH codes, with preliminary support for RAMSES, ART, Chombo, CASTRO and MAESTRO codes. It can be used to create many common types of data products such as: * Slices * Projections * Profiles * Arbitrary Data Selection * Cosmological Analysis * Halo finding * Parallel AMR Volume Rendering * Gravitationally Bound Objects Analysis There are a few major additions since yt-2.0 (Released January 17, 2011), including: * Streamlines for visualization and querying * A treecode implementation to calculate binding energy * Healpix / all-sky parallel volume rendering * A development bootstrap script, for getting going with modifying and contributing * CASTRO particles * Time series analysis Documentation: http://yt.enzotools.org/doc/ Installation: http://yt.enzotools.org/doc/advanced/installing.html#installing-yt Cookbook: http://yt.enzotools.org/doc/cookbook/recipes.html Get Involved: http://yt.enzotools.org/doc/advanced/developing.html#contributing-code If you can?t wait to get started, install with: $ wget http://hg.enzotools.org/yt/raw/stable/doc/install_script.sh $ bash install_script.sh Development has been sponsored by the NSF, DOE, and University funding. We invite you to get involved with developing and using yt! Please forward this announcement to interested parties. Sincerely, The yt development team: David Collins Oliver Hahn Cameron Hummels Stefan Klemer Chris Malone Christopher Moody Andrew Myers Jeff Oishi Britton Smith Devin Silvia Sam Skillman Stephen Skory Matthew Turk John Wise John ZuHone -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewturk at gmail.com Wed Apr 6 15:08:51 2011 From: matthewturk at gmail.com (Matthew Turk) Date: Wed, 6 Apr 2011 15:08:51 -0400 Subject: [AstroPy] all-sky map In-Reply-To: References: <1302028336.498.23.camel@shevek> Message-ID: Hi Eric, On Wed, Apr 6, 2011 at 8:49 AM, Erik Tollerud wrote: >> If anybody knows why the figure size has to be 2:1 to avoid a blank >> image, I'd really appreciate a tip. > > Maybe this is a version problem? If I do the following with matplotlib 1.0.1: > > import matplotlib > matplotlib.use('agg') #I tried a few other backends and got the same result > > from matplotlib.pyplot import figure,axes,imshow,savefig > from numpy.random import randn > from math import pi > > img = randn(100,100) > > figure(figsize=(10,5)) > imshow(img,extent=(-pi,pi,-pi/2,pi/2)) > savefig('filename.png') > > I get this result: http://dl.dropbox.com/u/8683962/moll-agg1.png > > And if I add aspect=.5 to the imshow call, I get > http://dl.dropbox.com/u/8683962/moll-agg12.png > > Clearly it is not blank in either case, although the second case is > presumably is what you want. Yup, that works for me, but it doesn't apply the Mollweide projection. I put up a paste here: http://dpaste.com/hold/529372/ I run this, and allsky1.png has the image. allsky2.png and allsky3.png both have empty ovals, and it's not clear to me what's causing that. -Matt > > > > On Tue, Apr 5, 2011 at 3:56 PM, Matthew Turk wrote: >> Hi Marsall, >> >> On Tue, Apr 5, 2011 at 2:50 PM, Marshall Perrin wrote: >>> On Apr 5, 2011, at 12:32 PM, Jonathan Slavin wrote: >>>> I'm looking for a way to plot an all-sky map of modeled data using a >>>> Hammer-Aitoff projection. ?The way I've done this in IDL is to create a >>>> uniform x-y grid, translate that l, b using the proper conversion for an >>>> Aitoff projection and generate the data on that grid. ?I then display >>>> the image and overlay an Aitoff grid (which I also generate). ?So the >>>> image is rectangular and extends beyond the plot edges. ?That is fine, >>>> but then all the labeling, etc. has to be done by hand. ?Is there an >>>> easier way? ?Any help would be appreciated. >>> >>> >>> Check out the matplotlib mpl_toolkits.basemap module. ? The Basemap class implements a user-selectable map projection, and yields a callable object which handles the translation between projection coordinate systems and x,y positions for plotting. ? Here is some code I recently wrote to do a similar task, plotting positions of objects on an all-sky Mollweide projection: >> >> In theory one should be able to get this going with just the standard >> Matplotlib projections, without basemap, which has a huge dependency >> set. ?There seems to be a bug if you don't set the figure to have >> aspect ratio 2:1, but this code works for me, where img is a square >> array. >> >> import matplotlib.figure >> import matplotlib.backends.backend_agg >> >> fig = matplotlib.figure.Figure((10, 5)) >> ax = fig.add_subplot(1,1,1,projection='mollweide') >> image = ax.imshow(img, extent=(-pi,pi,-pi/2,pi/2), clip_on=False, aspect=0.5) >> cb = fig.colorbar(image, orientation='horizontal') >> >> cb.set_label(r"$\mathrm{Column}\/\mathrm{Density}\/[\mathrm{g}/\mathrm{cm}^2]$") >> canvas = matplotlib.backends.backend_agg.FigureCanvasAgg(fig) >> canvas.print_figure("allsky.png") >> >> (a bit more discussion: >> http://blog.enzotools.org/yt-development-all-sky-column-density-calcula >> ) >> >> If anybody knows why the figure size has to be 2:1 to avoid a blank >> image, I'd really appreciate a tip. >> >> -Matt >> >>> >>> ? ? ? ?# define base map class. >>> ? ? ? ?map = Basemap(projection='moll', lat_0 = 0, lon_0 = 0, >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?resolution = None) ?# do *NOT* draw Earth continents at any resolution! >>> ? ? ? ?map.drawmapboundary() >>> ? ? ? ?p.title("Equatorial coordinates J2000") >>> >>> ? ? ? ?# draw and label ra/dec grid lines every 30 degrees. >>> ? ? ? ?degtoralabel = lambda deg : "%+d$^h$" % int(deg/15) >>> ? ? ? ?degtodeclabel = lambda deg : "%+d$^\circ$" % deg >>> ? ? ? ?map.drawparallels(n.arange(-90, 90, 30), fmt=degtodeclabel, labels=[1,0,0,0]) >>> ? ? ? ?map.drawmeridians(n.arange(0, 360, 30) ) ?# label these manually since I don't like the default label positions: >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# this also demonstrates how to overplot text on map coordinates... >>> ? ? ? ?for h in [0,6,12,18]: >>> ? ? ? ? ? ?x,y = map(h*15,0) >>> ? ? ? ? ? ?p.text(x,y, degtoralabel(h*15)) >>> >>> ? ? ? ?# draw data points >>> ? ? ? ?px, py = map(data.radeg, data.dedeg) >>> ? ? ? ?map.plot(px, py, "o", color="red") >>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > > > > -- > Erik Tollerud > From erik.tollerud at gmail.com Thu Apr 7 02:15:28 2011 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Thu, 7 Apr 2011 03:15:28 -0300 Subject: [AstroPy] all-sky map In-Reply-To: References: <1302028336.498.23.camel@shevek> Message-ID: Whoops, sorry, you're aboslutely right - I left out a very important line! The corrected version (the key change being the addition of the call to "axes" with the projection keyword) is: import matplotlib matplotlib.use('agg') #I tried a few other backends and got the same result from matplotlib.pyplot import figure,axes,imshow,savefig from numpy.random import randn from math import pi img = randn(100,100) figure(figsize=(10,5)) axes(projection='mollweide') imshow(img,extent=(-pi,pi,-pi/2,pi/2)) savefig('filename.png') Also, when I run your script you linked to, I get the following three images (tested both on a Snow Leopard Mac and Ubuntu Lucid, both with matplotlib 1.0.1): http://dl.dropbox.com/u/8683962/allsky1.png http://dl.dropbox.com/u/8683962/allsky2.png http://dl.dropbox.com/u/8683962/allsky3.png And as you can see, 2 and 3 have colored imshow ovals rather than blank. This makes me think this is a bug that was fixed at some point (if you're using a version earlier than 1.0.1), or some rendering problem that is platform-specific (if you're using something other than OS X or Linux)... Definitely very weird behavior, though! On Wed, Apr 6, 2011 at 4:08 PM, Matthew Turk wrote: > Hi Eric, > > On Wed, Apr 6, 2011 at 8:49 AM, Erik Tollerud wrote: >>> If anybody knows why the figure size has to be 2:1 to avoid a blank >>> image, I'd really appreciate a tip. >> >> Maybe this is a version problem? If I do the following with matplotlib 1.0.1: >> >> import matplotlib >> matplotlib.use('agg') #I tried a few other backends and got the same result >> >> from matplotlib.pyplot import figure,axes,imshow,savefig >> from numpy.random import randn >> from math import pi >> >> img = randn(100,100) >> >> figure(figsize=(10,5)) >> imshow(img,extent=(-pi,pi,-pi/2,pi/2)) >> savefig('filename.png') >> >> I get this result: http://dl.dropbox.com/u/8683962/moll-agg1.png >> >> And if I add aspect=.5 to the imshow call, I get >> http://dl.dropbox.com/u/8683962/moll-agg12.png >> >> Clearly it is not blank in either case, although the second case is >> presumably is what you want. > > Yup, that works for me, but it doesn't apply the Mollweide projection. > ?I put up a paste here: > > http://dpaste.com/hold/529372/ > > I run this, and allsky1.png has the image. ?allsky2.png and > allsky3.png both have empty ovals, and it's not clear to me what's > causing that. > > -Matt > >> >> >> >> On Tue, Apr 5, 2011 at 3:56 PM, Matthew Turk wrote: >>> Hi Marsall, >>> >>> On Tue, Apr 5, 2011 at 2:50 PM, Marshall Perrin wrote: >>>> On Apr 5, 2011, at 12:32 PM, Jonathan Slavin wrote: >>>>> I'm looking for a way to plot an all-sky map of modeled data using a >>>>> Hammer-Aitoff projection. ?The way I've done this in IDL is to create a >>>>> uniform x-y grid, translate that l, b using the proper conversion for an >>>>> Aitoff projection and generate the data on that grid. ?I then display >>>>> the image and overlay an Aitoff grid (which I also generate). ?So the >>>>> image is rectangular and extends beyond the plot edges. ?That is fine, >>>>> but then all the labeling, etc. has to be done by hand. ?Is there an >>>>> easier way? ?Any help would be appreciated. >>>> >>>> >>>> Check out the matplotlib mpl_toolkits.basemap module. ? The Basemap class implements a user-selectable map projection, and yields a callable object which handles the translation between projection coordinate systems and x,y positions for plotting. ? Here is some code I recently wrote to do a similar task, plotting positions of objects on an all-sky Mollweide projection: >>> >>> In theory one should be able to get this going with just the standard >>> Matplotlib projections, without basemap, which has a huge dependency >>> set. ?There seems to be a bug if you don't set the figure to have >>> aspect ratio 2:1, but this code works for me, where img is a square >>> array. >>> >>> import matplotlib.figure >>> import matplotlib.backends.backend_agg >>> >>> fig = matplotlib.figure.Figure((10, 5)) >>> ax = fig.add_subplot(1,1,1,projection='mollweide') >>> image = ax.imshow(img, extent=(-pi,pi,-pi/2,pi/2), clip_on=False, aspect=0.5) >>> cb = fig.colorbar(image, orientation='horizontal') >>> >>> cb.set_label(r"$\mathrm{Column}\/\mathrm{Density}\/[\mathrm{g}/\mathrm{cm}^2]$") >>> canvas = matplotlib.backends.backend_agg.FigureCanvasAgg(fig) >>> canvas.print_figure("allsky.png") >>> >>> (a bit more discussion: >>> http://blog.enzotools.org/yt-development-all-sky-column-density-calcula >>> ) >>> >>> If anybody knows why the figure size has to be 2:1 to avoid a blank >>> image, I'd really appreciate a tip. >>> >>> -Matt >>> >>>> >>>> ? ? ? ?# define base map class. >>>> ? ? ? ?map = Basemap(projection='moll', lat_0 = 0, lon_0 = 0, >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?resolution = None) ?# do *NOT* draw Earth continents at any resolution! >>>> ? ? ? ?map.drawmapboundary() >>>> ? ? ? ?p.title("Equatorial coordinates J2000") >>>> >>>> ? ? ? ?# draw and label ra/dec grid lines every 30 degrees. >>>> ? ? ? ?degtoralabel = lambda deg : "%+d$^h$" % int(deg/15) >>>> ? ? ? ?degtodeclabel = lambda deg : "%+d$^\circ$" % deg >>>> ? ? ? ?map.drawparallels(n.arange(-90, 90, 30), fmt=degtodeclabel, labels=[1,0,0,0]) >>>> ? ? ? ?map.drawmeridians(n.arange(0, 360, 30) ) ?# label these manually since I don't like the default label positions: >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# this also demonstrates how to overplot text on map coordinates... >>>> ? ? ? ?for h in [0,6,12,18]: >>>> ? ? ? ? ? ?x,y = map(h*15,0) >>>> ? ? ? ? ? ?p.text(x,y, degtoralabel(h*15)) >>>> >>>> ? ? ? ?# draw data points >>>> ? ? ? ?px, py = map(data.radeg, data.dedeg) >>>> ? ? ? ?map.plot(px, py, "o", color="red") >>>> >>>> >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/astropy >>>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >>> >> >> >> >> -- >> Erik Tollerud >> > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Erik Tollerud From mdroe at stsci.edu Thu Apr 7 12:39:41 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 7 Apr 2011 12:39:41 -0400 Subject: [AstroPy] all-sky map In-Reply-To: References: <1302028336.498.23.camel@shevek> Message-ID: <4D9DE8CD.1000106@stsci.edu> I can confirm Erik's non-blank results with the latest git master and v1.0.1. Let us know which version of matplotlib you are using -- I would like to determine whether it's a "bug since fixed" or some interaction with another library on your platform that is causing this. If the latter, we should get to the bottom of it and add a workaround to matplotlib. Cheers, Mike On 04/07/2011 02:15 AM, Erik Tollerud wrote: > Whoops, sorry, you're aboslutely right - I left out a very important > line! The corrected version (the key change being the addition of the > call to "axes" with the projection keyword) is: > > import matplotlib > matplotlib.use('agg') #I tried a few other backends and got the same result > > from matplotlib.pyplot import figure,axes,imshow,savefig > from numpy.random import randn > from math import pi > > img = randn(100,100) > > figure(figsize=(10,5)) > axes(projection='mollweide') > imshow(img,extent=(-pi,pi,-pi/2,pi/2)) > savefig('filename.png') > > > > Also, when I run your script you linked to, I get the following three > images (tested both on a Snow Leopard Mac and Ubuntu Lucid, both with > matplotlib 1.0.1): > http://dl.dropbox.com/u/8683962/allsky1.png > http://dl.dropbox.com/u/8683962/allsky2.png > http://dl.dropbox.com/u/8683962/allsky3.png > > And as you can see, 2 and 3 have colored imshow ovals rather than > blank. This makes me think this is a bug that was fixed at some point > (if you're using a version earlier than 1.0.1), or some rendering > problem that is platform-specific (if you're using something other > than OS X or Linux)... Definitely very weird behavior, though! > > > On Wed, Apr 6, 2011 at 4:08 PM, Matthew Turk wrote: >> Hi Eric, >> >> On Wed, Apr 6, 2011 at 8:49 AM, Erik Tollerud wrote: >>>> If anybody knows why the figure size has to be 2:1 to avoid a blank >>>> image, I'd really appreciate a tip. >>> Maybe this is a version problem? If I do the following with matplotlib 1.0.1: >>> >>> import matplotlib >>> matplotlib.use('agg') #I tried a few other backends and got the same result >>> >>> from matplotlib.pyplot import figure,axes,imshow,savefig >>> from numpy.random import randn >>> from math import pi >>> >>> img = randn(100,100) >>> >>> figure(figsize=(10,5)) >>> imshow(img,extent=(-pi,pi,-pi/2,pi/2)) >>> savefig('filename.png') >>> >>> I get this result: http://dl.dropbox.com/u/8683962/moll-agg1.png >>> >>> And if I add aspect=.5 to the imshow call, I get >>> http://dl.dropbox.com/u/8683962/moll-agg12.png >>> >>> Clearly it is not blank in either case, although the second case is >>> presumably is what you want. >> Yup, that works for me, but it doesn't apply the Mollweide projection. >> I put up a paste here: >> >> http://dpaste.com/hold/529372/ >> >> I run this, and allsky1.png has the image. allsky2.png and >> allsky3.png both have empty ovals, and it's not clear to me what's >> causing that. >> >> -Matt >> >>> >>> >>> On Tue, Apr 5, 2011 at 3:56 PM, Matthew Turk wrote: >>>> Hi Marsall, >>>> >>>> On Tue, Apr 5, 2011 at 2:50 PM, Marshall Perrin wrote: >>>>> On Apr 5, 2011, at 12:32 PM, Jonathan Slavin wrote: >>>>>> I'm looking for a way to plot an all-sky map of modeled data using a >>>>>> Hammer-Aitoff projection. The way I've done this in IDL is to create a >>>>>> uniform x-y grid, translate that l, b using the proper conversion for an >>>>>> Aitoff projection and generate the data on that grid. I then display >>>>>> the image and overlay an Aitoff grid (which I also generate). So the >>>>>> image is rectangular and extends beyond the plot edges. That is fine, >>>>>> but then all the labeling, etc. has to be done by hand. Is there an >>>>>> easier way? Any help would be appreciated. >>>>> >>>>> Check out the matplotlib mpl_toolkits.basemap module. The Basemap class implements a user-selectable map projection, and yields a callable object which handles the translation between projection coordinate systems and x,y positions for plotting. Here is some code I recently wrote to do a similar task, plotting positions of objects on an all-sky Mollweide projection: >>>> In theory one should be able to get this going with just the standard >>>> Matplotlib projections, without basemap, which has a huge dependency >>>> set. There seems to be a bug if you don't set the figure to have >>>> aspect ratio 2:1, but this code works for me, where img is a square >>>> array. >>>> >>>> import matplotlib.figure >>>> import matplotlib.backends.backend_agg >>>> >>>> fig = matplotlib.figure.Figure((10, 5)) >>>> ax = fig.add_subplot(1,1,1,projection='mollweide') >>>> image = ax.imshow(img, extent=(-pi,pi,-pi/2,pi/2), clip_on=False, aspect=0.5) >>>> cb = fig.colorbar(image, orientation='horizontal') >>>> >>>> cb.set_label(r"$\mathrm{Column}\/\mathrm{Density}\/[\mathrm{g}/\mathrm{cm}^2]$") >>>> canvas = matplotlib.backends.backend_agg.FigureCanvasAgg(fig) >>>> canvas.print_figure("allsky.png") >>>> >>>> (a bit more discussion: >>>> http://blog.enzotools.org/yt-development-all-sky-column-density-calcula >>>> ) >>>> >>>> If anybody knows why the figure size has to be 2:1 to avoid a blank >>>> image, I'd really appreciate a tip. >>>> >>>> -Matt >>>> >>>>> # define base map class. >>>>> map = Basemap(projection='moll', lat_0 = 0, lon_0 = 0, >>>>> resolution = None) # do *NOT* draw Earth continents at any resolution! >>>>> map.drawmapboundary() >>>>> p.title("Equatorial coordinates J2000") >>>>> >>>>> # draw and label ra/dec grid lines every 30 degrees. >>>>> degtoralabel = lambda deg : "%+d$^h$" % int(deg/15) >>>>> degtodeclabel = lambda deg : "%+d$^\circ$" % deg >>>>> map.drawparallels(n.arange(-90, 90, 30), fmt=degtodeclabel, labels=[1,0,0,0]) >>>>> map.drawmeridians(n.arange(0, 360, 30) ) # label these manually since I don't like the default label positions: >>>>> # this also demonstrates how to overplot text on map coordinates... >>>>> for h in [0,6,12,18]: >>>>> x,y = map(h*15,0) >>>>> p.text(x,y, degtoralabel(h*15)) >>>>> >>>>> # draw data points >>>>> px, py = map(data.radeg, data.dedeg) >>>>> map.plot(px, py, "o", color="red") >>>>> >>>>> >>>>> _______________________________________________ >>>>> AstroPy mailing list >>>>> AstroPy at scipy.org >>>>> http://mail.scipy.org/mailman/listinfo/astropy >>>>> >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/astropy >>>> >>> >>> >>> -- >>> Erik Tollerud >>> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> > > From jslavin at cfa.harvard.edu Thu Apr 7 13:35:47 2011 From: jslavin at cfa.harvard.edu (Jonathan Slavin) Date: Thu, 07 Apr 2011 13:35:47 -0400 Subject: [AstroPy] all-sky map Message-ID: <1302197747.17833.24.camel@shevek> Erik, I tried that script on my system (Linux CentOS 5.5, but with newer versions of python and matplotlib installed) and got an empty circle (note: not an ellipse). I also got this message three times: Warning: invalid value encountered in divide I don't know what the issue is. My matplotlib version is 1.0.0. Jon > Whoops, sorry, you're aboslutely right - I left out a very important > line! The corrected version (the key change being the addition of the > call to "axes" with the projection keyword) is: > > import matplotlib > matplotlib.use('agg') #I tried a few other backends and got the same > result > > from matplotlib.pyplot import figure,axes,imshow,savefig > from numpy.random import randn > from math import pi > > img = randn(100,100) > > figure(figsize=(10,5)) > axes(projection='mollweide') > imshow(img,extent=(-pi,pi,-pi/2,pi/2)) > savefig('filename.png') > > > > Also, when I run your script you linked to, I get the following three > images (tested both on a Snow Leopard Mac and Ubuntu Lucid, both with > matplotlib 1.0.1): > http://dl.dropbox.com/u/8683962/allsky1.png > http://dl.dropbox.com/u/8683962/allsky2.png > http://dl.dropbox.com/u/8683962/allsky3.png > > And as you can see, 2 and 3 have colored imshow ovals rather than > blank. This makes me think this is a bug that was fixed at some point > (if you're using a version earlier than 1.0.1), or some rendering > problem that is platform-specific (if you're using something other > than OS X or Linux)... Definitely very weird behavior, though! From mdroe at stsci.edu Thu Apr 7 14:25:37 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 7 Apr 2011 14:25:37 -0400 Subject: [AstroPy] all-sky map In-Reply-To: <1302197747.17833.24.camel@shevek> References: <1302197747.17833.24.camel@shevek> Message-ID: <4D9E01A1.5060003@stsci.edu> I can confirm that this problem exists on v1.0.0 but is fixed in v1.0.1... So if you're able to upgrade, that seems like the path of least resistance. Mike On 04/07/2011 01:35 PM, Jonathan Slavin wrote: > Erik, > > I tried that script on my system (Linux CentOS 5.5, but with newer > versions of python and matplotlib installed) and got an empty circle > (note: not an ellipse). I also got this message three times: > Warning: invalid value encountered in divide > I don't know what the issue is. My matplotlib version is 1.0.0. > > Jon > >> Whoops, sorry, you're aboslutely right - I left out a very important >> line! The corrected version (the key change being the addition of the >> call to "axes" with the projection keyword) is: >> >> import matplotlib >> matplotlib.use('agg') #I tried a few other backends and got the same >> result >> >> from matplotlib.pyplot import figure,axes,imshow,savefig >> from numpy.random import randn >> from math import pi >> >> img = randn(100,100) >> >> figure(figsize=(10,5)) >> axes(projection='mollweide') >> imshow(img,extent=(-pi,pi,-pi/2,pi/2)) >> savefig('filename.png') >> >> >> >> Also, when I run your script you linked to, I get the following three >> images (tested both on a Snow Leopard Mac and Ubuntu Lucid, both with >> matplotlib 1.0.1): >> http://dl.dropbox.com/u/8683962/allsky1.png >> http://dl.dropbox.com/u/8683962/allsky2.png >> http://dl.dropbox.com/u/8683962/allsky3.png >> >> And as you can see, 2 and 3 have colored imshow ovals rather than >> blank. This makes me think this is a bug that was fixed at some point >> (if you're using a version earlier than 1.0.1), or some rendering >> problem that is platform-specific (if you're using something other >> than OS X or Linux)... Definitely very weird behavior, though! > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From matthewturk at gmail.com Thu Apr 7 14:31:32 2011 From: matthewturk at gmail.com (Matthew Turk) Date: Thu, 7 Apr 2011 14:31:32 -0400 Subject: [AstroPy] all-sky map In-Reply-To: <4D9E01A1.5060003@stsci.edu> References: <1302197747.17833.24.camel@shevek> <4D9E01A1.5060003@stsci.edu> Message-ID: Hi Mike, Unfortunately, it seems that one of the colorbar handling operations in yt (the package I work on) was affected by a change somewhere between 1.0.0 and the current tip. Looking over the official changelog (http://matplotlib.sourceforge.net/_static/CHANGELOG) doesn't give any hints as to what would have changed. This results in empty colorbars for all image plots as set up in yt. I'm going to try to track it down, but I think until I can figure out which aspect of the API changed I'm going to use the (10,5) figsize and 0.5 aspect ratio for sky projections. Thanks very much for your help with all this, Matt On Thu, Apr 7, 2011 at 2:25 PM, Michael Droettboom wrote: > I can confirm that this problem exists on v1.0.0 but is fixed in > v1.0.1... So if you're able to upgrade, that seems like the path of > least resistance. > > Mike > > On 04/07/2011 01:35 PM, Jonathan Slavin wrote: >> Erik, >> >> I tried that script on my system (Linux CentOS 5.5, but with newer >> versions of python and matplotlib installed) and got an empty circle >> (note: not an ellipse). ?I also got this message three times: >> Warning: invalid value encountered in divide >> I don't know what the issue is. ?My matplotlib version is 1.0.0. >> >> Jon >> >>> Whoops, sorry, you're aboslutely right - I left out a very important >>> line! ?The corrected version (the key change being the addition of the >>> call to "axes" with the projection keyword) is: >>> >>> import matplotlib >>> matplotlib.use('agg') #I tried a few other backends and got the same >>> result >>> >>> from matplotlib.pyplot import figure,axes,imshow,savefig >>> from numpy.random import randn >>> from math import pi >>> >>> img = randn(100,100) >>> >>> figure(figsize=(10,5)) >>> axes(projection='mollweide') >>> imshow(img,extent=(-pi,pi,-pi/2,pi/2)) >>> savefig('filename.png') >>> >>> >>> >>> Also, when I run your script you linked to, I get the following three >>> images (tested both on a Snow Leopard Mac and Ubuntu Lucid, both with >>> matplotlib 1.0.1): >>> http://dl.dropbox.com/u/8683962/allsky1.png >>> http://dl.dropbox.com/u/8683962/allsky2.png >>> http://dl.dropbox.com/u/8683962/allsky3.png >>> >>> And as you can see, 2 and 3 have colored imshow ovals rather than >>> blank. ?This makes me think this is a bug that was fixed at some point >>> (if you're using a version earlier than 1.0.1), or some rendering >>> problem that is platform-specific (if you're using something other >>> than OS X or Linux)... Definitely very weird behavior, though! >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From tgrav at mac.com Thu Apr 7 15:47:38 2011 From: tgrav at mac.com (Tommy Grav) Date: Thu, 07 Apr 2011 15:47:38 -0400 Subject: [AstroPy] append problem in atpy Message-ID: I am a big fan on atpy and use it extensively in reading IPAC/IRSA tables. However I get this error when trying to append two tables with strings that I do not understand. Does anyone know what is happening and how to get around it >>> import atpy >>> t = atpy.Table() >>> name = ["aa","bb","cc"] >>> t.add_column("name",name) >>> k = [1,2,3] >>> t.add_column("num",k) >>> t >>> name = ["aaa","bbb","ccc"] >>> p = atpy.Table() >>> p.add_column("name",name) >>> p.add_column("num",k) >>> t.append(p) Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/atpy/basetable.py", line 301, in append raise Exception("Columns do not match") Exception: Columns do not match >>> nn = t.name.astype("|S3") >>> t.remove_columns("name") >>> t.add_column("name",nn) >>> t.append(p) Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/atpy/basetable.py", line 302, in append self.data = np.hstack((self.data, table.data)) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/shape_base.py", line 258, in hstack return _nx.concatenate(map(atleast_1d,tup),1) TypeError: expected a readable buffer object >>> Cheers Tommy -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred.grollier at gmail.com Fri Apr 8 04:42:12 2011 From: fred.grollier at gmail.com (Frederic Grollier) Date: Fri, 8 Apr 2011 10:42:12 +0200 Subject: [AstroPy] append problem in atpy In-Reply-To: References: Message-ID: <20110408084212.GB14652@free.fr> I don't know much atpy, but as far as I can tell your problem lies in the fact that you're trying to stack two numpy structured arrays with mismatching dtypes ; at the end of your example, t.data.dtype is : [('num', ' I am a big fan on atpy and use it extensively in reading IPAC/IRSA tables. However I get this error > when trying to append two tables with strings that I do not understand. Does anyone know what is happening > and how to get around it > > >>> import atpy > >>> t = atpy.Table() > >>> name = ["aa","bb","cc"] > >>> t.add_column("name",name) > >>> k = [1,2,3] > >>> t.add_column("num",k) > >>> t >
> >>> name = ["aaa","bbb","ccc"] > >>> p = atpy.Table() > >>> p.add_column("name",name) > >>> p.add_column("num",k) > >>> t.append(p) > Traceback (most recent call last): > File "", line 1, in > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/atpy/basetable.py", line 301, in append > raise Exception("Columns do not match") > Exception: Columns do not match > >>> nn = t.name.astype("|S3") > >>> t.remove_columns("name") > >>> t.add_column("name",nn) > >>> t.append(p) > Traceback (most recent call last): > File "", line 1, in > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/atpy/basetable.py", line 302, in append > self.data = np.hstack((self.data, table.data)) > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/shape_base.py", line 258, in hstack > return _nx.concatenate(map(atleast_1d,tup),1) > TypeError: expected a readable buffer object > >>> > > Cheers > Tommy From johann.cohentanugi at gmail.com Mon Apr 11 09:25:48 2011 From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi) Date: Mon, 11 Apr 2011 15:25:48 +0200 Subject: [AstroPy] surface computing on the sphere for projected maps Message-ID: <4DA3015C.10200@gmail.com> Hello, I have a 2D skymap resulting from a given projection (say 'CAR' for instance, but not necessarily), and I would like to compute the corresponding surface on the sphere of a pixel. What is the best way to do that, with pywcs if possible, but any suggestion of other tools welcome. thanks in advance, Johann From jerome_caron_astro at ymail.com Mon Apr 11 11:28:23 2011 From: jerome_caron_astro at ymail.com (Jerome Caron) Date: Mon, 11 Apr 2011 16:28:23 +0100 (BST) Subject: [AstroPy] Re : surface computing on the sphere for projected maps In-Reply-To: <4DA3015C.10200@gmail.com> References: <4DA3015C.10200@gmail.com> Message-ID: <509814.4834.qm@web24606.mail.ird.yahoo.com> Hello, I am new on the forum since a few days. I am a French amateur astronomer, living in Netherlands, with imaging and photometry as main interests. A few months ago, I started developing my own CCD image processing routines in Python (see http://astrosurf.com/caron/python_scripts.html), starting from Pyfits. I find the discussions here very interesting. Maybe I could help about your question to compute area distorsion induced by a projection. If you know the mapping (alpha, delta) on sky --> (x,y) on map, then you could calculate it analytically, following the method explained there: http://www.uni-stuttgart.de/gi/geoengine/mappro/lecturenotes.pdf All equations simplify due to the spherical sky (instead of ellipsoidal Earth). The idea is that you calculate a matrix called C (see slide 19), and the shape distorsions in the two principal (orthogonal) directions = lambda1, lambda2, are the square roots of the eigenvalues of C (see slide 24). Area distorsion is just the product of the two shape distorsions = lambda1 * lamdba2 = sqrt(det(C)). In practice: An arc element on the sky is ???ds^2 = ddelta^2 + cos(delta)^2 * dalpha^2 An arc element on the map is ???dl^2 = dx^2 + dy^2 Then relative area distorsion induced by map projection is ??? area_distorsion = cos(delta) * abs(dx/dalpha * dy/ddelta - dx/ddelta * dy/dalpha) ? I hope this helps Kind regards Jerome ? Hello, I have a 2D skymap resulting from a given projection (say 'CAR' for instance, but not necessarily), and I would like to compute the corresponding surface on the sphere of a pixel. What is the best way to do that, with pywcs if possible, but any suggestion of other tools welcome. thanks in advance, Johann _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy ________________________________ De : Johann Cohen-Tanugi ? : "astropy at scipy.org" Envoy? le : Lun 11 avril 2011, 15h 25min 48s Objet?: [AstroPy] surface computing on the sphere for projected maps -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattyowl at gmail.com Tue Apr 12 18:47:26 2011 From: mattyowl at gmail.com (Matt Hilton) Date: Tue, 12 Apr 2011 23:47:26 +0100 Subject: [AstroPy] [pywcs] Unit question Message-ID: <201104122347.26558.matthew.hilton@nottingham.ac.uk> Hi folks, sorry for the delayed reply. I maintain the astLib package, which actually contains more than just the wcs module, though I have no idea as to whether anyone actually uses the non-WCS parts bar me. It's basically just a collection of stuff that I developed through my PhD (and afterwards...) that I thought might be generally useful. During my PhD, pywcs was not available, hence the reason for the WCS module. I have to confess that I've not actually looked at pywcs so far, and a lot of my own code (not surprisingly) uses the modules I made. I'm sure pywcs is great, but I've not felt the need to switch over just yet. I guess one good reason to switch would be handling distortion coeffs, which the version of wcslib used in WCSTools (which I wrapped) doesn't handle, but I haven't personally needed that yet. For sure, I could switch over bits of my code to use pywcs instead of astWCS, but it's a question of time and what the benefit would be (in terms of how it helps with getting my own research done). > To the maintainers of the other wcs packages, what capabilities do you > think pywcs is missing? Is there some way of merging the missing > capabilities? Or is there a disagreement on the proper object model or > interfaces? This seems like a good time to start such a discussion. Since as I say I've yet to look at pywcs, I'm not exactly sure - but I think it would be nice to have a unified image class (perhaps some sort of pyfits/pywcs hybrid beast) with e.g. various clipping functions built in, for extracting postage stamps and the like. Cheers, Matt. > On Apr 5, 2011, at 6:18 AM, Ole Streicher wrote: > > Am 05.04.2011 09:33, schrieb Nico Nell: > >> This can be done easily with astLib (http://astlib.sourceforge.net/). > >> See function clipImageSectionWCS > >> (http://astlib.sourceforge.net/docs/astLib/astLib.astImages-module.html# > >> clipImageSectionWCS ). > >> > >> Here is an example that I used to make clips from big GALEX fits > >> files > >> (http://casa.colorado.edu/~nell/cgit/cgit.cgi/pyscripts/tree/plotting/ga > >> lex-clips.py ) > >> > >> Hopefully this makes things easier for you! > > > > Thank you, Nico. > > > > However, I started now using pywcs, and I would probably stick to that > > unless I cannot use the problem with it. > > > > I am still quite confused why there are parallel packages doing mainly > > the same thing: astLib and astrolib are quite for the same purpose, > > and > > having both f.e. a wcslib wrapper. In my opinion, this parallel > > development seems to me quite unnecessary and delays cooperation since > > everyone historically uses his own preferred library. For different > > programming languages, I could understand this, but I dont see a real > > reason to have different pywcs modules. > > > > Are there any attempts to unify the different approaches for > > astro(python|lib)? What is the common opinion about the fragmentation > > problem? > > Actually, I'd like to help such a unification. WCS seems like an > obvious place to start (it's not the only case though). > > Mind you, I'm not adverse to people trying different approaches early > on to see what works best, but after some point consolidation is > usually a good idea. > > So perhaps this is a good starting point for doing so with WCS. I > haven't studied the details of this particular instance that much, but > it certainly makes sense that one should be able to easily generate a > new WCS for a subarray. If pywcs can't do that yet, we should add > that capability. > > To the maintainers of the other wcs packages, what capabilities do you > think pywcs is missing? Is there some way of merging the missing > capabilities? Or is there a disagreement on the proper object model or > interfaces? This seems like a good time to start such a discussion. > > Perry > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From astropy at liska.ath.cx Thu Apr 14 07:35:08 2011 From: astropy at liska.ath.cx (Ole Streicher) Date: Thu, 14 Apr 2011 13:35:08 +0200 Subject: [AstroPy] [Pywcs] pywcs.WCS.cd array Message-ID: <4DA6DBEC.70207@liska.ath.cx> Dear list, when I try top access the individual coefficients of a pywcs.WCS object: ----------------8<--------------------------------------------------- import pyfits, pywcs d = {'NAXIS':3, 'CD1_1':-4.12e-5, 'CD1_2':-3.72e-5, 'CD1_3':0, 'CD2_1':-3.72e-5, 'CD2_2': 4.12e-5, 'CD2_3':0, 'CD3_1': 0, 'CD3_2': 0, 'CD3_3':0.2, 'CUNIT1':'deg', 'CUNIT2':'deg', 'CUNIT3':'nm', 'CTYPE1':'RA---TAN', 'CTYPE2':'DEC--TAN','CTYPE3':'AWAV' } wcs = pywcs.WCS( pyfits.Header(pyfits.Card(k,v) for k,v in d.items())) print wcs.wcs.cd ----------------8<--------------------------------------------------- results in an only 2x2 matrix with wrong coefficients: [[ -4.12000000e-05 -3.72000000e-05] [ 0.00000000e+00 -3.72000000e-05]] Is this on purpose, and how can I acess the CDi_j coefficient matrix from the WCS object? When I do a print wcs.wcs I get the correct values cd[0][]: -4.12e-05 -3.72e-05 0 cd[1][]: -3.72e-05 4.12e-05 0 cd[2][]: 0 0 2e-10 Pywcs versions are 1.9 and 1.10. Regards Ole From mdroe at stsci.edu Thu Apr 14 12:04:30 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 14 Apr 2011 12:04:30 -0400 Subject: [AstroPy] [Pywcs] pywcs.WCS.cd array In-Reply-To: <4DA6DBEC.70207@liska.ath.cx> References: <4DA6DBEC.70207@liska.ath.cx> Message-ID: <4DA71B0E.6070607@stsci.edu> Yep. That's a bug. Fixed in SVN r1981. Are you able to check out from SVN and confirm it works for you? Mike On 04/14/2011 07:35 AM, Ole Streicher wrote: > Dear list, > > when I try top access the individual coefficients of a pywcs.WCS object: > > ----------------8<--------------------------------------------------- > import pyfits, pywcs > > d = {'NAXIS':3, > 'CD1_1':-4.12e-5, 'CD1_2':-3.72e-5, 'CD1_3':0, > 'CD2_1':-3.72e-5, 'CD2_2': 4.12e-5, 'CD2_3':0, > 'CD3_1': 0, 'CD3_2': 0, 'CD3_3':0.2, > 'CUNIT1':'deg', 'CUNIT2':'deg', 'CUNIT3':'nm', > 'CTYPE1':'RA---TAN', 'CTYPE2':'DEC--TAN','CTYPE3':'AWAV' } > > wcs = pywcs.WCS( pyfits.Header(pyfits.Card(k,v) for k,v in d.items())) > print wcs.wcs.cd > > ----------------8<--------------------------------------------------- > > results in an only 2x2 matrix with wrong coefficients: > > [[ -4.12000000e-05 -3.72000000e-05] > [ 0.00000000e+00 -3.72000000e-05]] > > Is this on purpose, and how can I acess the CDi_j coefficient matrix > from the WCS object? When I do a > > print wcs.wcs > > I get the correct values > > cd[0][]: -4.12e-05 -3.72e-05 0 > cd[1][]: -3.72e-05 4.12e-05 0 > cd[2][]: 0 0 2e-10 > > Pywcs versions are 1.9 and 1.10. > > Regards > > Ole > _______________________________________________ > 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 sergiopr at fis.ucm.es Thu Apr 14 13:18:19 2011 From: sergiopr at fis.ucm.es (Sergio Pascual) Date: Thu, 14 Apr 2011 19:18:19 +0200 Subject: [AstroPy] Aperture photometry Message-ID: Hi Let's say I have an image as a numpy array and I want to obtain the summed values of the array inside an ellipse inside the image. In other words, I wanto to make aperture photometry. Do you know of any python astronomy package that implements this. It's a fairly basic think, but I haven't found anything. Regards -- Sergio Pascual ? ? ? ? ? ? ? ? ? ? ? ?http://guaix.fis.ucm.es/~spr gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) From ianc at ucla.edu Thu Apr 14 14:16:15 2011 From: ianc at ucla.edu (Ian Crossfield) Date: Thu, 14 Apr 2011 11:16:15 -0700 Subject: [AstroPy] Aperture photometry In-Reply-To: References: Message-ID: <4DA739EF.7070600@ucla.edu> Sergio, In general, PyRAF is probably your best bet for Python-drive photometry: http://www.stsci.edu/resources/software_hardware/pyraf . This software has a long legacy and plenty of users; the learning curve is steep, but worth it in the long haul. If you need to avoid IRAF for some reason, I have some homebrew aperture photometry routines on my website; e.g.: http://astro.ucla.edu/~ianc/python/phot.html#phot.aperphot The documentation isn't terrific, but the calling syntax is: import phot observation = phot.aperphot(image, pos=[x0,y0], dap=[dap_targ, dap_skyinner, dap_skyouter]) Where: image -- can be the filename of a FITS file, or a numpy array pos -- x,y pixel coordinates of the target dap -- _diameters_ of apertures for photometry Then, e.g., "observation.phot" will give you the photometric measurement and "observation.bg" will give you the background level. But try PyRAF; you'll ultimately be glad you did. -- Ian Crossfield UCLA Astronomy KH 3-145J http://www.astro.ucla.edu/~ianc/ On 4/14/11 10:18 AM, Sergio Pascual wrote: > Hi > > Let's say I have an image as a numpy array and I want to obtain the > summed values of the array inside an ellipse inside the image. In > other words, I wanto to make aperture photometry. Do you know of any > python astronomy package that implements this. It's a fairly basic > think, but I haven't found anything. > > Regards > From superluminique at gmail.com Thu Apr 14 15:22:08 2011 From: superluminique at gmail.com (Rene Breton) Date: Thu, 14 Apr 2011 15:22:08 -0400 Subject: [AstroPy] Aperture photometry In-Reply-To: References: Message-ID: <4DA74960.8000309@gmail.com> Hi Sergio, I'm currently working on porting the IDL astrolib aperture photometry routines to python (which you can find in pyastrolib). I'm not done with them yet. Hopefully it should be done soon as I have some data reduction to perform. I can let you know if you're interested. If you want something more basic for now, have a look at the attached python script. It does the aperture photometry but doesn't handle subpixel contributions. If the radius of your aperture isn't too small it shouldn't be too far off a more careful reduction. I haven't made the script to handle multiple source positions/apertures but this could easily be fixed. Cheers, Rene On 11-04-14 01:18 PM, Sergio Pascual wrote: > Hi > > Let's say I have an image as a numpy array and I want to obtain the > summed values of the array inside an ellipse inside the image. In > other words, I wanto to make aperture photometry. Do you know of any > python astronomy package that implements this. It's a fairly basic > think, but I haven't found anything. > > Regards > -------------- next part -------------- A non-text attachment was scrubbed... Name: aperphot.py Type: text/x-python Size: 1918 bytes Desc: not available URL: From sergiopr at fis.ucm.es Thu Apr 14 17:04:42 2011 From: sergiopr at fis.ucm.es (Sergio Pascual) Date: Thu, 14 Apr 2011 23:04:42 +0200 Subject: [AstroPy] Aperture photometry In-Reply-To: <4DA739EF.7070600@ucla.edu> References: <4DA739EF.7070600@ucla.edu> Message-ID: Hi Ian 2011/4/14 Ian Crossfield : > Sergio, > > In general, PyRAF is probably your best bet for Python-drive photometry: > http://www.stsci.edu/resources/software_hardware/pyraf . ?This software > has a long legacy and plenty of users; the learning curve is steep, but > worth it in the long haul. > Well, in fact I want to avoid Iraf completely, probably because I have used it for years... On the other hand, as Iraf is the defacto standard, a python aperture photometry library should have capabilities similar to apphot. Apphot handles polygonal and circular apertures, with fractional pixels. What I can't find is how is Iraf handling the fractional pixels. In the circular case, is it computing exact values? is it approximating the circle by something else? With Iraf is difficult to know. > If you need to avoid IRAF for some reason, I have some homebrew aperture > photometry routines on my website; e.g.: > http://astro.ucla.edu/~ianc/python/phot.html#phot.aperphot > > > The documentation isn't terrific, but the calling syntax is: > > > import phot > observation = phot.aperphot(image, ?pos=[x0,y0], ?dap=[dap_targ, ?dap_skyinner, ?dap_skyouter]) > > Where: > image -- can be the filename of a FITS file, or a numpy array > pos -- x,y pixel coordinates of the target > dap -- _diameters_ of apertures for photometry > > > Then, e.g., "observation.phot" will give you the photometric measurement > and "observation.bg" will give you the background level. > > But try PyRAF; you'll ultimately be glad you did. > > -- > > Ian Crossfield > UCLA Astronomy > KH 3-145J > http://www.astro.ucla.edu/~ianc/ > > > > > On 4/14/11 10:18 AM, Sergio Pascual wrote: >> Hi >> >> Let's say I have an image as a ?numpy array and I want to obtain the >> summed values of the array inside an ellipse inside the image. In >> other words, I wanto to make aperture photometry. Do you know of any >> python astronomy package that implements this. It's a fairly basic >> think, but I haven't found anything. >> >> Regards >> > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Sergio Pascual ? ? ? ? ? ? ? ? ? ? ? ?http://guaix.fis.ucm.es/~spr gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) From sergiopr at fis.ucm.es Thu Apr 14 17:23:12 2011 From: sergiopr at fis.ucm.es (Sergio Pascual) Date: Thu, 14 Apr 2011 23:23:12 +0200 Subject: [AstroPy] Aperture photometry In-Reply-To: <4DA74960.8000309@gmail.com> References: <4DA74960.8000309@gmail.com> Message-ID: It would be great to have routines directly comparable with those from Iraf or IDL. What kind of apertures does Astrolib support? How it handles subpixel fractions? I think there's a lack of information about the algorithms used to effectively compute the subpixel fraction in the apertures. Regards, Sergio 2011/4/14 Rene Breton : > Hi Sergio, > > I'm currently working on porting the IDL astrolib aperture photometry > routines to python (which you can find in pyastrolib). I'm not done with > them yet. Hopefully it should be done soon as I have some data reduction to > perform. I can let you know if you're interested. > > If you want something more basic for now, have a look at the attached python > script. It does the aperture photometry but doesn't handle subpixel > contributions. If the radius of your aperture isn't too small it shouldn't > be too far off a more careful reduction. I haven't made the script to handle > multiple source positions/apertures but this could easily be fixed. > > Cheers, > > Rene > > > > On 11-04-14 01:18 PM, Sergio Pascual wrote: >> >> Hi >> >> Let's say I have an image as a ?numpy array and I want to obtain the >> summed values of the array inside an ellipse inside the image. In >> other words, I wanto to make aperture photometry. Do you know of any >> python astronomy package that implements this. It's a fairly basic >> think, but I haven't found anything. >> >> Regards >> > -- Sergio Pascual ? ? ? ? ? ? ? ? ? ? ? ?http://guaix.fis.ucm.es/~spr gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) From superluminique at gmail.com Thu Apr 14 17:35:54 2011 From: superluminique at gmail.com (Rene Breton) Date: Thu, 14 Apr 2011 17:35:54 -0400 Subject: [AstroPy] Aperture photometry In-Reply-To: References: <4DA74960.8000309@gmail.com> Message-ID: <4DA768BA.6070606@gmail.com> The plan is to deliver comparable functionality as the IDL astrolib routine. This means been able to perform the aperture photometry from an image array, given a list of coordinates, apertures, etc. The actual function arguments might be different to make it more modern and the algorithms might be improved, if possible. The aper.pro (http://idlastro.gsfc.nasa.gov/ftp/pro/idlphot/aper.pro) routine deals specifically with circular aperture photometry (polygonal could eventually be added if someone wants to extend the circular aperture one). According to the documentation there are two methods to deal with subpixels, a polygonal approximation and an exact calculation. Here is the quote: ; /EXACT - By default, APER counts subpixels, but uses a polygon ; approximation for the intersection of a circular aperture with ; a square pixel (and normalizes the total area of the sum of the ; pixels to exactly match the circular area). If the /EXACT ; keyword, then the intersection of the circular aperture with a ; square pixel is computed exactly. The /EXACT keyword is much ; slower and is only needed when small (~2 pixels) apertures are ; used with very undersampled data. So my idea is also to provide different algorithms. The first is the crude aperture, with no subpixel. The second will be the polygonal approximation, which is fine in most situations, and last will be the exact. I'm still at the stage of taking apart the code and reorganizing it so I can't tell much more about the algorithm. Rene On 11-04-14 05:23 PM, Sergio Pascual wrote: > It would be great to have routines directly comparable with those from > Iraf or IDL. What kind of apertures does Astrolib support? How it > handles subpixel fractions? > > I think there's a lack of information about the algorithms used to > effectively compute the subpixel fraction in the apertures. > > Regards, Sergio > > 2011/4/14 Rene Breton: >> Hi Sergio, >> >> I'm currently working on porting the IDL astrolib aperture photometry >> routines to python (which you can find in pyastrolib). I'm not done with >> them yet. Hopefully it should be done soon as I have some data reduction to >> perform. I can let you know if you're interested. >> >> If you want something more basic for now, have a look at the attached python >> script. It does the aperture photometry but doesn't handle subpixel >> contributions. If the radius of your aperture isn't too small it shouldn't >> be too far off a more careful reduction. I haven't made the script to handle >> multiple source positions/apertures but this could easily be fixed. >> >> Cheers, >> >> Rene >> >> >> >> On 11-04-14 01:18 PM, Sergio Pascual wrote: >>> >>> Hi >>> >>> Let's say I have an image as a numpy array and I want to obtain the >>> summed values of the array inside an ellipse inside the image. In >>> other words, I wanto to make aperture photometry. Do you know of any >>> python astronomy package that implements this. It's a fairly basic >>> think, but I haven't found anything. >>> >>> Regards >>> >> > > > From sergiopr at fis.ucm.es Thu Apr 14 17:50:46 2011 From: sergiopr at fis.ucm.es (Sergio Pascual) Date: Thu, 14 Apr 2011 23:50:46 +0200 Subject: [AstroPy] Aperture photometry In-Reply-To: <4DA768BA.6070606@gmail.com> References: <4DA74960.8000309@gmail.com> <4DA768BA.6070606@gmail.com> Message-ID: 2011/4/14 Rene Breton : > The plan is to deliver comparable functionality as the IDL astrolib routine. > This means been able to perform the aperture photometry from an image array, > given a list of coordinates, apertures, etc. The actual function arguments > might be different to make it more modern and the algorithms might be > improved, if possible. > > The aper.pro (http://idlastro.gsfc.nasa.gov/ftp/pro/idlphot/aper.pro) > routine deals specifically with circular aperture photometry (polygonal > could eventually be added if someone wants to extend the circular aperture > one). According to the documentation there are two methods to deal with > subpixels, a polygonal approximation and an exact calculation. Here is the > quote: > > ; /EXACT - ?By default, APER counts subpixels, but uses a polygon > ; approximation for the intersection of a circular aperture with > ; a square pixel (and normalizes the total area of the sum of the > ; pixels to exactly match the circular area). ? If the /EXACT > ; keyword, then the intersection of the circular aperture with a > ; square pixel is computed exactly. ? ?The /EXACT keyword is much > ; slower and is only needed when small (~2 pixels) apertures are > ; used with very undersampled data. > > So my idea is also to provide different algorithms. The first is the crude > aperture, with no subpixel. The second will be the polygonal approximation, > which is fine in most situations, and last will be the exact. I'm still at > the stage of taking apart the code and reorganizing it so I can't tell much > more about the algorithm. > I have implemented a exact elliptical aperture (with axis not rotated) and yes, it's very slow. I use a modified mid-point algorithm to trace the quadrants of the ellipse (and compute the subpixel contribution), but I think I should try a polygonal approximation and compare performances. Regards, Sergio > Rene > > > > On 11-04-14 05:23 PM, Sergio Pascual wrote: >> >> It would be great to have routines directly comparable with those from >> Iraf or IDL. What kind of apertures does Astrolib support? How it >> handles subpixel fractions? >> >> I think there's a lack of information about the algorithms used to >> effectively compute the subpixel fraction in the apertures. >> >> Regards, Sergio >> >> 2011/4/14 Rene Breton: >>> >>> Hi Sergio, >>> >>> I'm currently working on porting the IDL astrolib aperture photometry >>> routines to python (which you can find in pyastrolib). I'm not done with >>> them yet. Hopefully it should be done soon as I have some data reduction >>> to >>> perform. I can let you know if you're interested. >>> >>> If you want something more basic for now, have a look at the attached >>> python >>> script. It does the aperture photometry but doesn't handle subpixel >>> contributions. If the radius of your aperture isn't too small it >>> shouldn't >>> be too far off a more careful reduction. I haven't made the script to >>> handle >>> multiple source positions/apertures but this could easily be fixed. >>> >>> Cheers, >>> >>> Rene >>> >>> >>> >>> On 11-04-14 01:18 PM, Sergio Pascual wrote: >>>> >>>> Hi >>>> >>>> Let's say I have an image as a ?numpy array and I want to obtain the >>>> summed values of the array inside an ellipse inside the image. In >>>> other words, I wanto to make aperture photometry. Do you know of any >>>> python astronomy package that implements this. It's a fairly basic >>>> think, but I haven't found anything. >>>> >>>> Regards >>>> >>> >> >> >> > -- Sergio Pascual ? ? ? ? ? ? ? ? ? ? ? ?http://guaix.fis.ucm.es/~spr gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) From erik.tollerud at gmail.com Thu Apr 14 21:37:42 2011 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Thu, 14 Apr 2011 18:37:42 -0700 Subject: [AstroPy] Aperture photometry In-Reply-To: References: <4DA74960.8000309@gmail.com> <4DA768BA.6070606@gmail.com> Message-ID: Hello all, In case one of these options doesn't suit your needs, I'm attaching a rather basic script I used for some simple aperture photometry in uncrowded fields. If uses some basic robust statistics to identify sources, so you don't give it specific coordinates. it "just works" for me, although you may have to tweak some parameters, as I only tuned it to work for one particular telescope/CCD combination. It's pretty fast, though, if simple (and hence, we'll say "no warranty" :). The command-line usage is also somewhat particular to my setup, so you may have to modify it for whatever your filename scheme/filters are. Note that this is the basis for a module I intended to polish and eventually add to astropysics.phot (http://packages.python.org/Astropysics/coremods/phot.html), although the timescale for that is rather nebulous right now. On Thu, Apr 14, 2011 at 2:50 PM, Sergio Pascual wrote: > 2011/4/14 Rene Breton : >> The plan is to deliver comparable functionality as the IDL astrolib routine. >> This means been able to perform the aperture photometry from an image array, >> given a list of coordinates, apertures, etc. The actual function arguments >> might be different to make it more modern and the algorithms might be >> improved, if possible. >> >> The aper.pro (http://idlastro.gsfc.nasa.gov/ftp/pro/idlphot/aper.pro) >> routine deals specifically with circular aperture photometry (polygonal >> could eventually be added if someone wants to extend the circular aperture >> one). According to the documentation there are two methods to deal with >> subpixels, a polygonal approximation and an exact calculation. Here is the >> quote: >> >> ; /EXACT - ?By default, APER counts subpixels, but uses a polygon >> ; approximation for the intersection of a circular aperture with >> ; a square pixel (and normalizes the total area of the sum of the >> ; pixels to exactly match the circular area). ? If the /EXACT >> ; keyword, then the intersection of the circular aperture with a >> ; square pixel is computed exactly. ? ?The /EXACT keyword is much >> ; slower and is only needed when small (~2 pixels) apertures are >> ; used with very undersampled data. >> >> So my idea is also to provide different algorithms. The first is the crude >> aperture, with no subpixel. The second will be the polygonal approximation, >> which is fine in most situations, and last will be the exact. I'm still at >> the stage of taking apart the code and reorganizing it so I can't tell much >> more about the algorithm. >> > > I have implemented a exact elliptical aperture (with axis not rotated) > and yes, it's very slow. I use a modified mid-point algorithm to trace > the quadrants of the ellipse (and compute the subpixel contribution), > but I think I should try a polygonal approximation and compare > performances. > > Regards, Sergio > >> Rene >> >> >> >> On 11-04-14 05:23 PM, Sergio Pascual wrote: >>> >>> It would be great to have routines directly comparable with those from >>> Iraf or IDL. What kind of apertures does Astrolib support? How it >>> handles subpixel fractions? >>> >>> I think there's a lack of information about the algorithms used to >>> effectively compute the subpixel fraction in the apertures. >>> >>> Regards, Sergio >>> >>> 2011/4/14 Rene Breton: >>>> >>>> Hi Sergio, >>>> >>>> I'm currently working on porting the IDL astrolib aperture photometry >>>> routines to python (which you can find in pyastrolib). I'm not done with >>>> them yet. Hopefully it should be done soon as I have some data reduction >>>> to >>>> perform. I can let you know if you're interested. >>>> >>>> If you want something more basic for now, have a look at the attached >>>> python >>>> script. It does the aperture photometry but doesn't handle subpixel >>>> contributions. If the radius of your aperture isn't too small it >>>> shouldn't >>>> be too far off a more careful reduction. I haven't made the script to >>>> handle >>>> multiple source positions/apertures but this could easily be fixed. >>>> >>>> Cheers, >>>> >>>> Rene >>>> >>>> >>>> >>>> On 11-04-14 01:18 PM, Sergio Pascual wrote: >>>>> >>>>> Hi >>>>> >>>>> Let's say I have an image as a ?numpy array and I want to obtain the >>>>> summed values of the array inside an ellipse inside the image. In >>>>> other words, I wanto to make aperture photometry. Do you know of any >>>>> python astronomy package that implements this. It's a fairly basic >>>>> think, but I haven't found anything. >>>>> >>>>> Regards >>>>> >>>> >>> >>> >>> >> > > > > -- > Sergio Pascual ? ? ? ? ? ? ? ? ? ? ? ?http://guaix.fis.ucm.es/~spr > gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC > Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Erik Tollerud -------------- next part -------------- A non-text attachment was scrubbed... Name: aperphot.py Type: application/octet-stream Size: 16191 bytes Desc: not available URL: From stefano.covino at brera.inaf.it Fri Apr 15 00:56:49 2011 From: stefano.covino at brera.inaf.it (Stefano Covino) Date: Fri, 15 Apr 2011 06:56:49 +0200 Subject: [AstroPy] Aperture photometry In-Reply-To: References: <4DA74960.8000309@gmail.com> <4DA768BA.6070606@gmail.com> Message-ID: <03CD8731-7308-483F-AC66-C2426603B5DC@brera.inaf.it> Dear Sergio, apparently the world is full of python aperture photometry routines! Although, in most cases, people did not manage (yet) to make them really available. And indeed do did I. I wrote a set of "not- organized" python scripts to deal with typical practical problems in our research group (http://www.merate.mi.astro.it/utenti/covino/usermanual.html ). Among these scripts there is also an aperture photometry routine which considers the fraction of pixels contribution evaluated integrating a curve within the limit of the pixel (yes, it is slow...). Indeed the goal of the set of script dealing with photometry is to provide a tool to compute magnitudes for a set of stars with many frames of the same field not perfectly aligned. The script finds common triangles between the reference frames and each one in input, finds a rototraslation (or a subset of it) to get the position of your stars in the new frame, and then derive a full light-curve. However, it seems to me that a lot of people provided you with reliable solutions. In the unlikely case, please feel free to grab everything you need from my code, although documentation is... let's say, under development. Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerome_caron_astro at ymail.com Fri Apr 15 01:17:57 2011 From: jerome_caron_astro at ymail.com (Jerome Caron) Date: Fri, 15 Apr 2011 06:17:57 +0100 (BST) Subject: [AstroPy] Tr : Re : Aperture photometry Message-ID: <229892.86192.qm@web24616.mail.ird.yahoo.com> Dear all I realise that I forgot to put the list in copy, see my message below... It looks that there are many interesting options about aperture photometry !! It would be interesting to compare performance of each one, in terms of quality and rapidity. Is anyone willing to investigate ? Regards Jerome Caron ----- Message transf?r? ---- De : Jerome Caron ? : Sergio Pascual Envoy? le : Jeu 14 avril 2011, 21h 11min 49s Objet?: Re : [AstroPy] Aperture photometry Dear Sergio You may want to have a look at the astro library I am developping. It's?based on Pyfits: http://astrosurf.com/caron/python_scripts.html I am precisely interested in aperture photometry. I?make light curves of asteroids; some of my data is processed by observatory of Geneve, Switzerland: http://obswww.unige.ch/~behrend/page1cou.html#000121http://obswww.unige.ch/~behrend/page1cou.html#000129 http://obswww.unige.ch/~behrend/page1cou.html#000202 My main script for aperture photometry is "photometry_call.py", it calls two functions - first one finds the (x,y) positions of the stars on each frame in the serie (max pixels and/or centroid of gaussian psf) - second one makes aperture photometry I also use the two other scripts in the folder photometry to check uniformity and detect bad images. I found that my scripts give better results than common softwares as e.g.?Iris or Au-dela (http://www.astrosurf.com/buil/us/iris/iris.htm?or http://www.audela.org/). Magnitude noise is typically smaller by 10%; the reason is that I do shift every object (star, asteroid) so that its centroid, calculated by gaussian fit, is exactly centered on one pixel, before making the?photometry. The translation is made by bilinear interpolation, which exactly conserves photometric information. Then the variability of PSF from image to image does affect all the objects in the same way (asteroid and ref stars) which is not true if they are not centered, as in the standard approaches. I plan to make a web page on this before summer. This feature can be deactivated with a flag, if you don't like it. Another nice trick is that you can make photometry with as many different apertures you want in one run. At the end you can pick up the best results. The documentation is a bit short, but all functions are described. If you have any question, I'll be happy to give some help. Cheers Jerome Caron ________________________________ De : Sergio Pascual ? : astropy at scipy.org Envoy? le : Jeu 14 avril 2011, 19h 18min 19s Objet?: [AstroPy] Aperture photometry Hi Let's say I have an image as a? numpy array and I want to obtain the summed values of the array inside an ellipse inside the image. In other words, I wanto to make aperture photometry. Do you know of any python astronomy package that implements this. It's a fairly basic think, but I haven't found anything. Regards -- Sergio Pascual ? ? ? ? ? ? ? ? ? ? ? ?http://guaix.fis.ucm.es/~spr gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jslavin at cfa.harvard.edu Fri Apr 22 13:27:51 2011 From: jslavin at cfa.harvard.edu (Jonathan Slavin) Date: Fri, 22 Apr 2011 13:27:51 -0400 Subject: [AstroPy] LinearNDInterpolator Message-ID: <1303493271.31478.7.camel@shevek> Hi all, I'm wondering if anyone has used the routine scipy.interpolate.LinearNDInterpolator >From what I can tell, it should do fast multidimensional linear interpolations, which is something I could use. My problem is that it isn't well documented. What I have is a 3-D grid of data values and what I want is values at a specific group of non-gridded points. scipy.interpolate.griddata seems to do the opposite to what I want -- given a set of (non-gridded) points at which you know the data value, interpolate onto a regular grid. It seemed like LinearNDInterpolator was what I wanted, but it seems to want the same input as griddata -- points at which the data value is known. That is, it takes two inputs points and values where the number of points must match the no. of values. What I need is something more like linearinterp(gridded_data, coords) -- that is, more like what scipy.ndimage.map_coordinates does, but much faster and just linear (rather than spline) interpolation. I wrote a routine that does this, and reasonably quickly, but it's pure python and not as fast as I'd like. Jon From ianc at ucla.edu Fri Apr 22 14:41:45 2011 From: ianc at ucla.edu (Ian Crossfield) Date: Fri, 22 Apr 2011 11:41:45 -0700 Subject: [AstroPy] Transit light curve functions Message-ID: <4DB1CBE9.60904@ucla.edu> Being unable to find a Python compilation of the analytic transit light curve formulae from Mandel & Agol (2002), I have created one myself, documented here: http://astro.ucla.edu/~ianc/python/transit.html . It contains expressions for all cases treated in the original paper: uniform-disk, quadratic limb-darkening, full (4-parameter) limb-darkening, and the quick, small-planet approximation. Written in Python, these routines are a factor of 5-10 slower than the corresponding IDL versions, and perhaps slower still than an implementation in Fortran (as available from Eric Agol's website: http://www.astro.washington.edu/users/agol/ ). Nonetheless, I hope that someone may find them useful. If you do, please feel free to use them or adapt them to suit your own needs. And as always, if you find a bug please let me know. -- Ian Crossfield UCLA Astronomy KH 3-145J http://www.astro.ucla.edu/~ianc/ From erik.tollerud at gmail.com Fri Apr 22 18:48:13 2011 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Fri, 22 Apr 2011 15:48:13 -0700 Subject: [AstroPy] LinearNDInterpolator In-Reply-To: <1303493271.31478.7.camel@shevek> References: <1303493271.31478.7.camel@shevek> Message-ID: I'm not clear on what you're asking about LinearNDInterpolator in your second paragraph... what linear interpolator does is take in a list of coordinates and the corresponding values at those points (they can be gridded or not), and then can be used to give you the data value at any point inside the point values (although it does *not* extrapolate beyond the input points). Is that what you want? If not, please clarify, or if so, see the example below for a sample usage - it makes a grid of points that represent a 3d gaussian and then uses the interpolator to do (I think) what you want. from numpy import mgrid,exp,array from scipy.interpolate import LinearNDInterpolator #x,y,and z are 11x11x11 arrays with the x,y, and z values for a 3d box from -1 to 1 x,y,z = mgrid[-1:1:11j,-1:1:11j,-1:1:11j] #s is a gaussian evaluated at the grid points - replace this with your grid values s = exp(-(x**2+y**2+z**2)/2) #this reshapes the points into the kind of input LinearNDInterpolator wants: Npts x Ndims pts = array((x.ravel(),y.ravel(),z.ravel())).T #and the values should be a 1d array that matches the first dimension of pts sr = s.ravel() i = LinearNDInterpolator(pts,sr) Now to get values at whatever points you want, you call the interpolator with an array of dimensions nyourpoints x ndims. e.g. >>> i([[0,0,0]]) array([ 1.]) >>> i([[0,0,0],[0,1,0],[1,1,0],[0,0,.5]]) array([ 1. , 0.60653066, 0.36787944, 0.87919328]) Although note that if you go off the grid, you get NaN back: >>> i([[0,0,2]]) array([ nan]) On Fri, Apr 22, 2011 at 10:27 AM, Jonathan Slavin wrote: > Hi all, > > I'm wondering if anyone has used the routine > scipy.interpolate.LinearNDInterpolator > >From what I can tell, it should do fast multidimensional linear > interpolations, which is something I could use. ?My problem is that it > isn't well documented. > > What I have is a 3-D grid of data values and what I want is values at a > specific group of non-gridded points. ?scipy.interpolate.griddata seems > to do the opposite to what I want -- given a set of (non-gridded) points > at which you know the data value, interpolate onto a regular grid. ?It > seemed like LinearNDInterpolator was what I wanted, but it seems to want > the same input as griddata -- points at which the data value is known. > That is, it takes two inputs points and values where the number of > points must match the no. of values. ?What I need is something more like > linearinterp(gridded_data, coords) -- that is, more like what > scipy.ndimage.map_coordinates does, but much faster and just linear > (rather than spline) interpolation. ?I wrote a routine that does this, > and reasonably quickly, but it's pure python and not as fast as I'd > like. > > Jon > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Erik Tollerud From jslavin at cfa.harvard.edu Tue Apr 26 14:24:39 2011 From: jslavin at cfa.harvard.edu (Jonathan Slavin) Date: Tue, 26 Apr 2011 14:24:39 -0400 Subject: [AstroPy] LinearNDInterpolator Message-ID: <1303842279.12540.8.camel@shevek> Erik, Thanks for the response. I didn't understand that the object returned was a function which one then has to call with the desired coordinates. I get it now. Unfortunately it seems to be not as fast as I'd hoped. The simple function that I wrote, which takes the "effective indices" for the arrays and returns an array of interpolated values is much faster. Mostly that's because it requires a 3-D grid for input so using the effective indices is a simple vector operation. I don't know how many people would have use for my routine or if such a routine already exists out there somewhere (it seems there must) but in any case I'd be happy to make it available if anyone wants it. Jon > I'm not clear on what you're asking about LinearNDInterpolator in your > second paragraph... what linear interpolator does is take in a list of > coordinates and the corresponding values at those points (they can be > gridded or not), and then can be used to give you the data value at > any point inside the point values (although it does *not* extrapolate > beyond the input points). Is that what you want? If not, please > clarify, or if so, see the example below for a sample usage - it makes > a grid of points that represent a 3d gaussian and then uses the > interpolator to do (I think) what you want. > > > > > from numpy import mgrid,exp,array > from scipy.interpolate import LinearNDInterpolator > > #x,y,and z are 11x11x11 arrays with the x,y, and z values for a 3d box > from -1 to 1 > x,y,z = mgrid[-1:1:11j,-1:1:11j,-1:1:11j] > > #s is a gaussian evaluated at the grid points - replace this with your > grid values > s = exp(-(x**2+y**2+z**2)/2) > > #this reshapes the points into the kind of input LinearNDInterpolator > wants: Npts x Ndims > pts = array((x.ravel(),y.ravel(),z.ravel())).T > > #and the values should be a 1d array that matches the first dimension > of pts > sr = s.ravel() > > i = LinearNDInterpolator(pts,sr) > > > Now to get values at whatever points you want, you call the > interpolator with an array of dimensions nyourpoints x ndims. e.g. > > >>> i([[0,0,0]]) > array([ 1.]) > >>> i([[0,0,0],[0,1,0],[1,1,0],[0,0,.5]]) > array([ 1. , 0.60653066, 0.36787944, 0.87919328]) > > Although note that if you go off the grid, you get NaN back: > >>> i([[0,0,2]]) > array([ nan]) > > > On Fri, Apr 22, 2011 at 10:27 AM, Jonathan Slavin > wrote: > > Hi all, > > > > I'm wondering if anyone has used the routine > > scipy.interpolate.LinearNDInterpolator > > >From what I can tell, it should do fast multidimensional linear > > interpolations, which is something I could use. My problem is that > it > > isn't well documented. > > > > What I have is a 3-D grid of data values and what I want is values > at a > > specific group of non-gridded points. scipy.interpolate.griddata > seems > > to do the opposite to what I want -- given a set of (non-gridded) > points > > at which you know the data value, interpolate onto a regular grid. > It > > seemed like LinearNDInterpolator was what I wanted, but it seems to > want > > the same input as griddata -- points at which the data value is > known. > > That is, it takes two inputs points and values where the number of > > points must match the no. of values. What I need is something more > like > > linearinterp(gridded_data, coords) -- that is, more like what > > scipy.ndimage.map_coordinates does, but much faster and just linear > > (rather than spline) interpolation. I wrote a routine that does > this, > > and reasonably quickly, but it's pure python and not as fast as I'd > > like. > > > > Jon > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > -- > Erik Tollerud > From sergiopr at fis.ucm.es Wed Apr 27 12:32:02 2011 From: sergiopr at fis.ucm.es (Sergio Pascual) Date: Wed, 27 Apr 2011 18:32:02 +0200 Subject: [AstroPy] Pywcs available in Fedora testing repositories. Message-ID: Hello, I'm happy to inform you that a pywcs package has been accepted in the Fedora Package Collection. pywcs has been built for fedora releases 14 and 13 and for EPEL 6. https://admin.fedoraproject.org/updates/pywcs-1.9-3.fc14 https://admin.fedoraproject.org/updates/pywcs-1.6-1.fc13 https://admin.fedoraproject.org/updates/pywcs-1.6-1.el6 The version of pywcs available depends on the version of wcslib included in each distribution. Regards, Sergio -- Sergio Pascual ? ? ? ? ? ? ? ? ? ? ? ?http://guaix.fis.ucm.es/~spr gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) From astropy at liska.ath.cx Fri Apr 29 11:04:26 2011 From: astropy at liska.ath.cx (Ole Streicher) Date: Fri, 29 Apr 2011 17:04:26 +0200 Subject: [AstroPy] Pywcs: Creation, access to properties Message-ID: <4DBAD37A.4000501@liska.ath.cx> Hello, I have two questions about pywcs: First is, how do I create a pywcs.WCS object not from a file, but with certain parameters? The way I do it now is first to create a header with the required keywords, and then use the pywcs.WCS constructor, but this seems to me a bit indirect. The second question is on how do I access some parameters in a robust way? For example, I want to get the instrument resolution in arcsec out of the image. Currently, I implemented it like import numpy import pywcs def get_resolution(wcs, units = None) c = numpy.sqrt(numpy.sum((wcs.wcs.cd if wcs.wcs.has_cd() else wcs.wcs.pc) ** 2, axis = 0)) if units is None: return c else return [ pywcs.UnitConverter(from_unit, to_unit).convert(cc) if to_unit is not None else cc for from_unit, to_unit, cc in zip(wcs.wcs.cunit, units, c) ] but this looks a bit weird, and I feel that I still did not took all possible cases to construct the WCS. Is there a simpler way? This question arises since I often have to implement something like "give me the pixel position just 1 arcsec upwards (in CCD orientation) from the image center". Best regards Ole From mdroe at stsci.edu Fri Apr 29 12:36:57 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Fri, 29 Apr 2011 12:36:57 -0400 Subject: [AstroPy] Pywcs: Creation, access to properties In-Reply-To: <4DBAD37A.4000501@liska.ath.cx> References: <4DBAD37A.4000501@liska.ath.cx> Message-ID: <4DBAE929.2070201@stsci.edu> On 04/29/2011 11:04 AM, Ole Streicher wrote: > Hello, > > I have two questions about pywcs: > > First is, how do I create a pywcs.WCS object not from a file, but with > certain parameters? The way I do it now is first to create a header with > the required keywords, and then use the pywcs.WCS constructor, but this > seems to me a bit indirect. > Have you seen this? http://stsdas.stsci.edu/astrolib/pywcs/examples.html#building-a-wcs-structure-programmatically > The second question is on how do I access some parameters in a robust > way? For example, I want to get the instrument resolution in arcsec out > of the image. Currently, I implemented it like > > import numpy > import pywcs > > def get_resolution(wcs, units = None) > c = numpy.sqrt(numpy.sum((wcs.wcs.cd if wcs.wcs.has_cd() > else wcs.wcs.pc) ** 2, axis = 0)) > if units is None: > return c > else > return [ > pywcs.UnitConverter(from_unit, to_unit).convert(cc) > if to_unit is not None else cc > for from_unit, to_unit, cc in zip(wcs.wcs.cunit, units, c) > ] > > but this looks a bit weird, and I feel that I still did not took all > possible cases to construct the WCS. Is there a simpler way? > Are you trying to determine the size of the output frame? The WCS object has a calcFootprint method: http://stsdas.stsci.edu/astrolib/pywcs/api_wcs.html#pywcs.WCS.calcFootprint By calculating the length of the edges, one could approximate the size in arcsec of the image. I say approximate because the output frame is not necessarily rectangular. The cd and pc matrices are just affine transformations that don't necessarily have anything to do with the image size. I see that checking for either the cd or pc matrices is annoying. (I recently saw some other code that had to do this, too). Wcslib under the hood, in fact, converts everything to pc/cdelt form canonically -- but pywcs only provides access to one at a time because it then it becomes unclear which values to use if one or the other is changed. I think it would be handy to add a read-only "get_pc" and "get_cdelt" functions, though, so that one could always get the canonical form of the various alternative representations. I'll try to add this to the SVN repository today. Cheers, Mike > This question arises since I often have to implement something like > "give me the pixel position just 1 arcsec upwards (in CCD orientation) > from the image center". > > Best regards > > Ole > _______________________________________________ > 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