From rahul.poruri at gmail.com Mon Jul 1 02:01:01 2013 From: rahul.poruri at gmail.com (rahul .poruri) Date: Mon, 1 Jul 2013 11:31:01 +0530 Subject: [AstroPy] Questions & Clarifications In-Reply-To: References: Message-ID: Thanks for the help :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From streetomon at gmail.com Mon Jul 1 08:45:52 2013 From: streetomon at gmail.com (=?ISO-8859-1?Q?Andr=E9_Luiz_de_Amorim?=) Date: Mon, 1 Jul 2013 14:45:52 +0200 Subject: [AstroPy] Bounds in parametric non linear fitting (astropy.modelling) Message-ID: Hi, I am using NonLinearLSQFitter and SLSQPFitter to fit some data to a parametric model I implemented. I am trying to set some boundaries in the parameters, as some values can not be negative. It seems that the bouns are set correctly, I ran the code in debug mode and the NonLinearLSQFitter._set_bounds() method is reached, for example. The code says this fitter accepts boundary constraints, but it does no work in my tests, the parameters step outside the bounds. In the case of SLSQPFitter it does not even fit, it returns the initial guess. Attached is a minimal example showing my approach. I would like to know if I am using the API correctly before filing a bug report (and/or trying to fix it :-). Thanks, Andr?. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_bounds.py Type: application/octet-stream Size: 3446 bytes Desc: not available URL: From dencheva at stsci.edu Mon Jul 1 10:20:25 2013 From: dencheva at stsci.edu (Nadezhda Dencheva) Date: Mon, 1 Jul 2013 14:20:25 +0000 Subject: [AstroPy] Bounds in parametric non linear fitting (astropy.modelling) In-Reply-To: References: Message-ID: <0153364C9F56D944B0A795780ECF88DF404AD3A8@EXCHMAIL2.stsci.edu> Hi Andre, It's a bug. Please file an issue on github. Thanks, Nadia ________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Andr? Luiz de Amorim [streetomon at gmail.com] Sent: Monday, July 01, 2013 8:45 AM To: astropy at scipy.org Subject: [AstroPy] Bounds in parametric non linear fitting (astropy.modelling) Hi, I am using NonLinearLSQFitter and SLSQPFitter to fit some data to a parametric model I implemented. I am trying to set some boundaries in the parameters, as some values can not be negative. It seems that the bouns are set correctly, I ran the code in debug mode and the NonLinearLSQFitter._set_bounds() method is reached, for example. The code says this fitter accepts boundary constraints, but it does no work in my tests, the parameters step outside the bounds. In the case of SLSQPFitter it does not even fit, it returns the initial guess. Attached is a minimal example showing my approach. I would like to know if I am using the API correctly before filing a bug report (and/or trying to fix it :-). Thanks, Andr?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From streetomon at gmail.com Mon Jul 1 10:49:01 2013 From: streetomon at gmail.com (=?ISO-8859-1?Q?Andr=E9_Luiz_de_Amorim?=) Date: Mon, 1 Jul 2013 16:49:01 +0200 Subject: [AstroPy] Bounds in parametric non linear fitting (astropy.modelling) In-Reply-To: <0153364C9F56D944B0A795780ECF88DF404AD3A8@EXCHMAIL2.stsci.edu> References: <0153364C9F56D944B0A795780ECF88DF404AD3A8@EXCHMAIL2.stsci.edu> Message-ID: Thanks for the prompt reply, Nadia, the issue was created. Is the fix is trivial for you? If not, I will try to tackle it, as I am really needing this functionality right now. Cheers, Andr?. On Mon, Jul 1, 2013 at 4:20 PM, Nadezhda Dencheva wrote: > Hi Andre, > > It's a bug. Please file an issue on github. > > Thanks, > Nadia > > ------------------------------ > *From:* astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf > of Andr? Luiz de Amorim [streetomon at gmail.com] > *Sent:* Monday, July 01, 2013 8:45 AM > *To:* astropy at scipy.org > *Subject:* [AstroPy] Bounds in parametric non linear fitting > (astropy.modelling) > > Hi, I am using NonLinearLSQFitter and SLSQPFitter to fit some data to a > parametric model I implemented. I am trying to set some boundaries in the > parameters, as some values can not be negative. It seems that the bouns are > set correctly, I ran the code in debug mode and > the NonLinearLSQFitter._set_bounds() method is reached, for example. The > code says this fitter accepts boundary constraints, but it does no work in > my tests, the parameters step outside the bounds. In the case > of SLSQPFitter it does not even fit, it returns the initial guess. > > Attached is a minimal example showing my approach. I would like to know > if I am using the API correctly before filing a bug report (and/or trying > to fix it :-). > > Thanks, > > Andr?. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trive at astro.su.se Wed Jul 3 04:02:15 2013 From: trive at astro.su.se (=?ISO-8859-1?Q?Th=F8ger_Rivera-Thorsen?=) Date: Wed, 03 Jul 2013 10:02:15 +0200 Subject: [AstroPy] AstroPy Digest, Vol 81, Issue 32 In-Reply-To: References: Message-ID: <51D3DA87.7090801@astro.su.se> Pardon me for resurrecting this thread; I wanted to reply immediately but have been swamped so I could not. My problem with a matplotlib-based GUI is that, as far as I can see, it is bound to be essentially linear. It is do-this-then-that, and if we are lucky, we can reiterate (some older interfaces, like native VPfit, don't even allow for that - one wrong click, and you must start over). It does not seem very well fit for reactive/event-driven programming, where each view is an equal, first-class citizen that can all manipulate the same underlying object, the model. I am worried that the same will be the case for any IPython Notebook-based GUI, at least until the JS rendering capabilities have matured considerably, and as far as I can see, making the transition from a click-and-draggable script to a fully grown GUI would require an entire HTML/JS/JSON/whatever-based framework to be created first. Widgets, layout engine etc., unless something already exists that I am aware of? The logging feature of matplotlib is great, but as the workflow with an interactive app often consists of a lot of trial-and-error, simply saving this as a script to recreate it would run a lot of actions that are later undone or simply irrelevant. One basically defines two different kinds of variables in a GUI: * Some that are part of the model and the science which are the interesting ones. We want to keep only the most recent versions of these (not discussing undo history for now). * Some that are simply state variables defining the visual representation and aiding in the internal communication between submodules of the interface. There is no need to keep these, as they only drown the relevant information and can be easily, if not trivially, recreated. As an illustration and hopefully inspiration, I have put up a [standalone version][1] of the line profile builder from my `grism` project on GitHub now. It requires scipy, pandas, Chaco, Traits and TraitsUI. It works as a GUI, but all variables in the ProfileEditor class instance (which, due to my lacking skills when I started writing it, also contains the model) can simultaneously be updated from the (I)Python prompt from which it was instantiated. This means that the interface can be kept clean by only containing tasks that are not actually easier to perform from the prompt IMO there is no reason to fill it up with tasks like loading ilne lists etc., as this is much easier done from the prompt with a clever convenience function). As has been mentioned before, the dependency on Traits(UI), chaco and Pandas may not be very suitable for building an astropy-affiliated package, but at least I hope some of the design philosophy can be of some use. Cheers, Emil [1]: https://github.com/thriveth/lpbuilder On 2013-06-26 17:47, Adam wrote: >> Any GUI that involves processes like selecting absorption lines or setting >> initial guesses for fits should be able to record the process as a script >> (either in a simple DSL or even as executable code) that can reproduce the exact >> steps taken without invoking the GUI at all. > Great point. It's actually fairly easy to do in matplotlib: you can > just make your "event manager" routine record a history of events, > e.g.: > self.event_history.append(event) > > and as long as you have one overarching event manager for the GUI > (which is probably an important design decision...), it should be able > to track > exactly what has been done and repeat it. > > That said, events can be tied to individual axes, so if a window is > closed, it would be essential to re-create that window in the same > state it was originally initialized. > > Anyway, 2 cents on GUI design... From jzuhone at gmail.com Wed Jul 3 14:36:39 2013 From: jzuhone at gmail.com (John ZuHone) Date: Wed, 3 Jul 2013 13:36:39 -0500 Subject: [AstroPy] Question regarding WCS coordinates Message-ID: Hi all, This question is probably more about WCS than it is about Astropy, but I intend to use Astropy to do it so I thought I would ask. I have some projected maps of gas temperature of a galaxy cluster that I made from FLASH simulation data using yt that I have put into FITS files. I also have some simulated Chandra event files made from the MARX Chandra simulator, of the same system. I would like to match the WCS coordinates of the two files. The simulated events file already has WCS coordinates in RA and DEC, and this is the coordinate system I would like to use for the temperature map. The information I have for the temperature map is the cell spacing in kpc, and the redshift of the simulated cluster, so with the chosen cosmology I also have the distance. How can I go about this? Sorry, I realize this is a bit involved (at least it seems that way to me). Best, John ZuHone From npkuin at gmail.com Wed Jul 3 15:07:12 2013 From: npkuin at gmail.com (Paul Kuin) Date: Wed, 3 Jul 2013 20:07:12 +0100 Subject: [AstroPy] Question regarding WCS coordinates In-Reply-To: References: Message-ID: First align the center, then get the scale in there (from kpc to degrees), possibly you need to roll the image. Look up the FITS standards office which has the papers describing fits and how to put WCS parameters in it. Paul On Wed, Jul 3, 2013 at 7:36 PM, John ZuHone wrote: > Hi all, > > This question is probably more about WCS than it is about Astropy, but I > intend to use Astropy to do it so I thought I would ask. > > I have some projected maps of gas temperature of a galaxy cluster that I > made from FLASH simulation data using yt that I have put into FITS files. I > also have some simulated Chandra event files made from the MARX Chandra > simulator, of the same system. > > I would like to match the WCS coordinates of the two files. The simulated > events file already has WCS coordinates in RA and DEC, and this is the > coordinate system I would like to use for the temperature map. The > information I have for the temperature map is the cell spacing in kpc, and > the redshift of the simulated cluster, so with the chosen cosmology I also > have the distance. > > How can I go about this? Sorry, I realize this is a bit involved (at least > it seems that way to me). > > Best, > > John ZuHone > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204927 (work) -276110 (home) mobile +44(0)7806985366 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ejensen1 at swarthmore.edu Wed Jul 3 16:53:14 2013 From: ejensen1 at swarthmore.edu (Eric L. N. Jensen) Date: Wed, 3 Jul 2013 16:53:14 -0400 Subject: [AstroPy] Question regarding WCS coordinates In-Reply-To: References: Message-ID: <2B2E9C09-60B4-45CE-A348-433829569677@swarthmore.edu> Hi John, I had to do something like this recently, converting images from a simulation into FITS files with WCS in the header so I could compare directly with ALMA data. Below is the code I used - it's a little more complicated than your case since you aren't creating a FITS header from scratch, and maybe you don't need a third (velocity/frequency) dimension in your image, but hopefully it will give you an idea of how to proceed. To give credit where it's due, this code derives largely from an IDL routine supplied by Kees Dullemond with his radmc3d code - I translated it to Python and modified it somewhat. If you need more information about WCS keywords in the FITS standard, this paper is a good reference: Pence et al. 2010 A&A 524, 40, http://www.aanda.org/articles/aa/full_html/2010/16/aa15362-10/aa15362-10.html Hope this helps, Eric P.S. In the code below, the 'read image' routine returns a dictionary with various bits of information about the image, as well as the numpy array of the image itself - adapt as needed. def radmcimage_to_fits(imagename, fitsname, dpc, arcsec=False, mas=False, restfreq=None, vel_offset=None, radeg=None, decdeg=None,): import numpy as np from astropy.io import fits cc = 2.9979245800000e10 # Light speed [cm/s] pc = 3.08572e18 # Parsec [cm] im = readimage(imagename) pixdeg_x = 180.0*(im['sizepix_x']/(dpc*pc))/np.pi pixdeg_y = 180.0*(im['sizepix_y']/(dpc*pc))/np.pi freqhz = 1e4*cc/im['lambda'] image = im['image'] n_freq = len(freqhz) # Because of the way that Python stores arrays, we need to swap around # our data array before writing it, so that it is indexed in the order # (freq, y, x), rather than (x, y, freq) - the last index in the Numpy # array will become AXIS1 in the FITS image, and so on. if im['stokes']: (nx, ny, nstokes, nfreq) = np.shape(image) newimage = np.transpose(image, (3, 2, 1, 0)) else: (nx, ny, nfreq) = np.shape(image) newimage = np.transpose(image, (2, 1, 0)) # # Compute the conversion factor from erg/cm^2/s/Hz/ster to Jy/pixel # pixsurf_ster = pixdeg_x*pixdeg_y * (np.pi/180.)**2 factor = 1e+23 * pixsurf_ster # And scale the image array accordingly: image_in_jypix = factor * newimage # # Make FITS header information: # header = fits.Header() header['BTYPE'] = 'Intensity' header['BSCALE'] = 1 header['BZERO'] = 0 header['BUNIT'] = 'JY/PIXEL' if radeg is not None: header['EPOCH'] = 2000. header['LONPOLE'] = 180. header['CTYPE1'] = 'RA---SIN' header['CRVAL1'] = radeg # Figure out what units we are using per pixel: if arcsec: unit = 'arcsec' multiplier = 3600. elif mas: unit = 'mas' multiplier = 3.6e6 else: unit = 'deg' multiplier = 1 header['CDELT1'] = multiplier*pixdeg_x header['CUNIT1'] = unit # # ...Zero point of coordinate system # header['CRPIX1'] = 1.0*((nx+1)/2) if decdeg is not None: header['CTYPE2'] = 'DEC--SIN' header['CRVAL2'] = decdeg header['CDELT2'] = multiplier*pixdeg_y header['CUNIT2'] = unit # # ...Zero point of coordinate system # header['CRPIX2'] = 1.0* ((ny+1)/2) # If the keyword is set for rest frequency, add that to the header as # it gives a reference point for, e.g., the velocity of the frequency # steps relative to some line rest frequency. Note that even though # the keyword used here is 'restfreq', the FITS standard for this # field is RESTFRQ, i.e. with no second 'E'. if restfreq is not None: header['RESTFRQ'] = (float(restfreq), 'Rest frequency of this transition') # # ...Frequency # # If they have specified a velocity offset, we shift all of the # specified frequencies by that amount. This allows, e.g., mapping a # transition of a particular CO line in radmc3d, but then accounting # for the fact that a real object might have a center-of-mass radial # velocity offset. Note that we do *not* shift the input 'restfreq' # keyword, as that is presumed to be the real frequency of that # transition. if vel_offset is not None: # Assume input velocity is in km/s, so # specify speed of light in those # units: c = 2.9979245800000e5 # Light speed [km/s] freqhz *= (1. - vel_offset/c) header['COMMENT'] = "Velocity offset of %0.2f km/s applied to model." % vel_offset if n_freq > 1: # multiple frequencies - set up the header keywords to define the # third axis as frequency header['CTYPE3'] = 'FREQ' header['CUNIT3'] = 'Hz' header['CRPIX3'] = 1.0 header['CRVAL3'] = freqhz[0] # Calculate the frequency step, assuming equal steps between all: delta_freq = freqhz[1] - freqhz[0] header['CDELT3'] = delta_freq else: # only one frequency header['RESTFREQ'] = freqhz # Make a FITS file! # fits.writeto(fitsname, image_in_jypix, header, output_verify='fix') On Jul 3, 2013, at 2:36 PM, John ZuHone wrote: > Hi all, > > This question is probably more about WCS than it is about Astropy, but I intend to use Astropy to do it so I thought I would ask. > > I have some projected maps of gas temperature of a galaxy cluster that I made from FLASH simulation data using yt that I have put into FITS files. I also have some simulated Chandra event files made from the MARX Chandra simulator, of the same system. > > I would like to match the WCS coordinates of the two files. The simulated events file already has WCS coordinates in RA and DEC, and this is the coordinate system I would like to use for the temperature map. The information I have for the temperature map is the cell spacing in kpc, and the redshift of the simulated cluster, so with the chosen cosmology I also have the distance. > > How can I go about this? Sorry, I realize this is a bit involved (at least it seems that way to me). > > Best, > > John ZuHone > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ga.braganca at gmail.com Wed Jul 3 21:51:20 2013 From: ga.braganca at gmail.com (=?ISO-8859-1?Q?Gustavo_Bragan=E7a?=) Date: Wed, 3 Jul 2013 22:51:20 -0300 Subject: [AstroPy] Loading wavelength from FITS spectrum Message-ID: Hi, Is there any easy way to load the values of wavelength from a FITS spectrum using astropy? I could obtain the wavelengths by using some values of the header, but I was wondering if there is an easy way. Thanks, Gustavo Bragan?a -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at depagne.org Thu Jul 4 04:43:19 2013 From: eric at depagne.org (=?iso-8859-1?q?=C9ric_Depagne?=) Date: Thu, 4 Jul 2013 10:43:19 +0200 Subject: [AstroPy] Loading wavelength from FITS spectrum In-Reply-To: References: Message-ID: <201307041043.19269.eric@depagne.org> Le jeudi 4 juillet 2013 ? 03:51:20, Gustavo Bragan?a a ?crit : > Hi, > Hi Gustavo, > Is there any easy way to load the values of wavelength from a FITS spectrum > using astropy? > > I could obtain the wavelengths by using some values of the header, but I > was wondering if there is an easy way. > I use the following code to get the wavelength and intensity: def readspec(fitsfile): f = pyfits.open(fitsfile) cdelt1 = f[0].header['CDELT1'] crval1 = f[0].header['CRVAL1'] start = crval1 - f[0].header['CRPIX1'] * cdelt1 end = start + cdelt1 * f[0].shape[0] - cdelt1/10. x = numpy.arange(start, end, cdelt1) f.close() return x, f[0].data I'm not sure it's the best way to do so, but it works. HTH. ?ric. Un clavier azerty en vaut deux ---------------------------------------------------------- ?ric Depagne eric at depagne.org From trive at astro.su.se Thu Jul 4 04:57:59 2013 From: trive at astro.su.se (=?ISO-8859-1?Q?Th=F8ger_Rivera-Thorsen?=) Date: Thu, 04 Jul 2013 10:57:59 +0200 Subject: [AstroPy] Loading wavelength from FITS spectrum In-Reply-To: <201307041043.19269.eric@depagne.org> References: <201307041043.19269.eric@depagne.org> Message-ID: <51D53917.5020205@astro.su.se> I usually go: data, header = pyfits.getdata(fitsfile, header=True) wave = numpy.arange(data.shape[0]) * header['CDELT1'] + header['CRVAL1'] That should be about as simple as it gets :-) Cheers, Emil On 2013-07-04 10:43, ?ric Depagne wrote: > Le jeudi 4 juillet 2013 ? 03:51:20, Gustavo Bragan?a a ?crit : >> Hi, >> > Hi Gustavo, > >> Is there any easy way to load the values of wavelength from a FITS spectrum >> using astropy? >> >> I could obtain the wavelengths by using some values of the header, but I >> was wondering if there is an easy way. >> > I use the following code to get the wavelength and intensity: > def readspec(fitsfile): > f = pyfits.open(fitsfile) > cdelt1 = f[0].header['CDELT1'] > crval1 = f[0].header['CRVAL1'] > start = crval1 - f[0].header['CRPIX1'] * cdelt1 > end = start + cdelt1 * f[0].shape[0] - cdelt1/10. > x = numpy.arange(start, end, cdelt1) > f.close() > return x, f[0].data > > I'm not sure it's the best way to do so, but it works. > > HTH. > > ?ric. > > Un clavier azerty en vaut deux > ---------------------------------------------------------- > ?ric Depagne eric at depagne.org > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From ianc at mpia-hd.mpg.de Thu Jul 4 05:06:57 2013 From: ianc at mpia-hd.mpg.de (Ian Crossfield) Date: Thu, 04 Jul 2013 11:06:57 +0200 Subject: [AstroPy] Loading wavelength from FITS spectrum In-Reply-To: <51D53917.5020205@astro.su.se> References: <201307041043.19269.eric@depagne.org> <51D53917.5020205@astro.su.se> Message-ID: <51D53B31.7060403@mpia-hd.mpg.de> The previously suggested solutions work for a linear wavelength solution, but things get more complicated for higher-order polynomial relations. In these cases I use the following: from pyraf import iraf import numpy as np iraf.wspectext('input.fits', 'output.txt', header=False) wavelength_and_flux = np.loadtxt('output.txt') I agree that it would be convenient to have an AstroPy helper function for doing this sort of thing. -Ian On 7/4/13 10:57 AM, Th?ger Rivera-Thorsen wrote: > I usually go: > > data, header = pyfits.getdata(fitsfile, header=True) > wave = numpy.arange(data.shape[0]) * header['CDELT1'] + header['CRVAL1'] > > That should be about as simple as it gets :-) > > Cheers, > Emil > > > > On 2013-07-04 10:43, ?ric Depagne wrote: >> Le jeudi 4 juillet 2013 ? 03:51:20, Gustavo Bragan?a a ?crit : >>> Hi, >>> >> Hi Gustavo, >> >>> Is there any easy way to load the values of wavelength from a FITS spectrum >>> using astropy? >>> >>> I could obtain the wavelengths by using some values of the header, but I >>> was wondering if there is an easy way. >>> >> I use the following code to get the wavelength and intensity: >> def readspec(fitsfile): >> f = pyfits.open(fitsfile) >> cdelt1 = f[0].header['CDELT1'] >> crval1 = f[0].header['CRVAL1'] >> start = crval1 - f[0].header['CRPIX1'] * cdelt1 >> end = start + cdelt1 * f[0].shape[0] - cdelt1/10. >> x = numpy.arange(start, end, cdelt1) >> f.close() >> return x, f[0].data >> >> I'm not sure it's the best way to do so, but it works. >> >> HTH. >> >> ?ric. >> >> Un clavier azerty en vaut deux >> ---------------------------------------------------------- >> ?ric Depagne eric at depagne.org >> _______________________________________________ >> 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 -- Ian Crossfield http://www.mpia-hd.mpg.de/homes/ianc/ Max-Planck-Institut f?r Astronomie +49-(0)6221 528-405 Room 308/4 From d.berry at jach.hawaii.edu Thu Jul 4 08:20:09 2013 From: d.berry at jach.hawaii.edu (David Berry) Date: Thu, 4 Jul 2013 13:20:09 +0100 Subject: [AstroPy] Loading wavelength from FITS spectrum In-Reply-To: <51D53B31.7060403@mpia-hd.mpg.de> References: <201307041043.19269.eric@depagne.org> <51D53917.5020205@astro.su.se> <51D53B31.7060403@mpia-hd.mpg.de> Message-ID: Using pyast (http://dsberry.github.io/starlink/pyast.html) you can do it like this: import pyfits import starlink.Atl as Atl hdulist = pyfits.open( 'test.fit' ) frameset,encoding = Atl.readfitswcs( hdulist ) wcsvalues = frameset.trangrid( 1, hdulist[0].shape[0] ) This assumes your FITS file has only one axis. If you have more axes (RA, Dec axes for instance), you need additionally to use mapsplit to split off the mapping for the spectral axis from the complete n-dimensional FrameSet: import pyfits import starlink.Atl as Atl # The one-based index of the spectral axis spectralaxis = 1 # Read the FITS headers and get an AST FrameSet describing the # full WCS. hdulist = pyfits.open( 'test.fit' ) frameset,encoding = Atl.readfitswcs( hdulist ) # Split off the Mapping that describes just the spectral axis. wcsaxis,specmap = frameset.mapsplit( spectralaxis ) # Use this Mapping to generate a list of spectral axis values # corresponding to pixel 1, 2, 3... wcsvalues = specmap.trangrid( 1, hdulist[0].shape[pixelaxis-1] ) David On 4 July 2013 10:06, Ian Crossfield wrote: > The previously suggested solutions work for a linear wavelength > solution, but things get more complicated for higher-order polynomial > relations. In these cases I use the following: > > from pyraf import iraf > import numpy as np > iraf.wspectext('input.fits', 'output.txt', header=False) > wavelength_and_flux = np.loadtxt('output.txt') > > I agree that it would be convenient to have an AstroPy helper function > for doing this sort of thing. > > -Ian > > > > On 7/4/13 10:57 AM, Th?ger Rivera-Thorsen wrote: >> I usually go: >> >> data, header = pyfits.getdata(fitsfile, header=True) >> wave = numpy.arange(data.shape[0]) * header['CDELT1'] + header['CRVAL1'] >> >> That should be about as simple as it gets :-) >> >> Cheers, >> Emil >> >> >> >> On 2013-07-04 10:43, ?ric Depagne wrote: >>> Le jeudi 4 juillet 2013 ? 03:51:20, Gustavo Bragan?a a ?crit : >>>> Hi, >>>> >>> Hi Gustavo, >>> >>>> Is there any easy way to load the values of wavelength from a FITS spectrum >>>> using astropy? >>>> >>>> I could obtain the wavelengths by using some values of the header, but I >>>> was wondering if there is an easy way. >>>> >>> I use the following code to get the wavelength and intensity: >>> def readspec(fitsfile): >>> f = pyfits.open(fitsfile) >>> cdelt1 = f[0].header['CDELT1'] >>> crval1 = f[0].header['CRVAL1'] >>> start = crval1 - f[0].header['CRPIX1'] * cdelt1 >>> end = start + cdelt1 * f[0].shape[0] - cdelt1/10. >>> x = numpy.arange(start, end, cdelt1) >>> f.close() >>> return x, f[0].data >>> >>> I'm not sure it's the best way to do so, but it works. >>> >>> HTH. >>> >>> ?ric. >>> >>> Un clavier azerty en vaut deux >>> ---------------------------------------------------------- >>> ?ric Depagne eric at depagne.org >>> _______________________________________________ >>> 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 > > > -- > Ian Crossfield > http://www.mpia-hd.mpg.de/homes/ianc/ > Max-Planck-Institut f?r Astronomie > +49-(0)6221 528-405 > Room 308/4 > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From d.berry at jach.hawaii.edu Thu Jul 4 08:21:50 2013 From: d.berry at jach.hawaii.edu (David Berry) Date: Thu, 4 Jul 2013 13:21:50 +0100 Subject: [AstroPy] Loading wavelength from FITS spectrum In-Reply-To: References: <201307041043.19269.eric@depagne.org> <51D53917.5020205@astro.su.se> <51D53B31.7060403@mpia-hd.mpg.de> Message-ID: On 4 July 2013 13:20, David Berry wrote: > Using pyast (http://dsberry.github.io/starlink/pyast.html) you can do > it like this: > > > import pyfits > import starlink.Atl as Atl > > hdulist = pyfits.open( 'test.fit' ) > frameset,encoding = Atl.readfitswcs( hdulist ) > wcsvalues = frameset.trangrid( 1, hdulist[0].shape[0] ) > > > > This assumes your FITS file has only one axis. If you have more axes > (RA, Dec axes for instance), you need additionally to use mapsplit to > split off the mapping for the spectral axis from the complete > n-dimensional FrameSet: > > import pyfits > import starlink.Atl as Atl > > # The one-based index of the spectral axis > spectralaxis = 1 > > # Read the FITS headers and get an AST FrameSet describing the > # full WCS. > hdulist = pyfits.open( 'test.fit' ) > frameset,encoding = Atl.readfitswcs( hdulist ) > > # Split off the Mapping that describes just the spectral axis. > wcsaxis,specmap = frameset.mapsplit( spectralaxis ) > > # Use this Mapping to generate a list of spectral axis values > # corresponding to pixel 1, 2, 3... > wcsvalues = specmap.trangrid( 1, hdulist[0].shape[pixelaxis-1] ) Doh! That final "pixelaxis-1" should be "spectralaxis-1". David From ga.braganca at gmail.com Thu Jul 4 19:13:03 2013 From: ga.braganca at gmail.com (=?ISO-8859-1?Q?Gustavo_Bragan=E7a?=) Date: Thu, 4 Jul 2013 20:13:03 -0300 Subject: [AstroPy] Loading wavelength from FITS spectrum In-Reply-To: References: <51D510AE.2050403@astro.su.se> Message-ID: Hi, Thanks to all. I have tried some and others I still have to test some others. Before sending the original e-mail, I have come to this: http://nbviewer.ipython.org/urls/raw.github.com/gabraganca/S4/dev/notebooks/load-spectrum-FITS.ipynb I probably should've sent this before, but I was not getting nbviewer to render my notebook. cheers, Gustavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Fri Jul 5 12:06:08 2013 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Fri, 5 Jul 2013 12:06:08 -0400 Subject: [AstroPy] Doodle poll for Astropy Coordination Meeting In-Reply-To: References: Message-ID: This is a reminder that if you have not yet participated in this poll and want to go to the meeting, you should do so in the next day or two so we can choose an appropriate date. Thanks to all who have thus far! On Thu, Jun 20, 2013 at 9:28 AM, Erik Tollerud wrote: > Hello all, > > As you may or may not know, there have been coordination meetings the last > two years (at the CfA and STScI) to discuss progress and future plans for > the Astropy project. These meetings were crucial in helping organize the > initial stages and direction for the project. > > Since then, Astropy has grown significantly and there are a number of quite > different subpackages, each with somewhat different items to address and > consider. This has prompted discussion in the coordinating committee that we > might consider holding in-person coordination meetings less often (every 2nd > year perhaps?). Instead, we might start scheduling regular google hangouts > to deal with items that might otherwise have been targeted for the > coordination meeting. > > Or, we might continue the yearly schedule, but focus the coordination > meetings on coding sprints, rather than planning discussions. E.g., a day > or half-day of progress overviews, followed by 1 or 2 days of sprinting to > focus on specific issues that are better addressed in-person. (Perhaps we > can even dabble in pair coding.) > > > So to help in making such a decision, I have created a doodle poll at > > http://www.doodle.com/t9em8iaqm7f6hrx7 > > This poll contains a number of potential dates this fall for the > coordination meeting. The Yale Astronomy department is willing to host such > an event for this year (host=provide a space and pay for coffee and lunch), > so it will most likely be in New Haven, CT, USA. *If* you would be > interested in attending such a meeting this year, please add your name to > the poll and indicate which dates you are available. > > Please aim to respond by July 4 (2 weeks). If at that point enough people > express interest that it seems worthwhile to hold a meeting, we will > schedule a time based on the responses. If not, we will skip the meeting > this year, and instead hold one in the fall of 2014. (And if anyone has > ideas for other approaches to coordination meetings, of course feel free to > respond to this post.) > > > Thanks! > > -- > Erik T -- Erik T From erik.tollerud at gmail.com Fri Jul 5 12:58:07 2013 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Fri, 5 Jul 2013 12:58:07 -0400 Subject: [AstroPy] IRAF tasks to Astropy In-Reply-To: <7680ff4471c32.51cd60c5@uwo.ca> References: <7680ff4471c32.51cd60c5@uwo.ca> Message-ID: The answer to this probably depends on what you want to do with the tasks - those tasks have a lot of options and can be used on a variety of inputs, so there's definitely not an exact mapping onto anything in astropy. Most, if not all of the things that mkpattern seems to do can be done with just standard numpy array mechanics. E.g., if you wanted to do cl> mkpat alpha[201:250,1:50] v1=-1000 you could instead do this in python (I *think* I have the indexing conditions right, but you might want to check it) : >>> alpha[200:250, 0:50] = -1000 The other two tasks can be used in a few different ways, but are generally for creating WCS headers for fits files? In that case, you can use astropy.io.fits to generate the files, and astropy.wcs to create the WCS. To go into more details probably requires more specifics about what you want to do. On Fri, Jun 28, 2013 at 10:09 AM, Sofia Lianou wrote: > Hi, > > I was wondering if there are Python/Astropy equivalents to (or plans to do > so in the near future for) the following IRAF tasks: > noao.artdata.mkpattern > images.immatch.wregister > images.imcoords.ccsetwcs > > Thank you, > Sophia > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Erik From moritz.guenther at gmx.de Sun Jul 7 21:40:23 2013 From: moritz.guenther at gmx.de (=?ISO-8859-1?Q?Moritz_G=FCnther?=) Date: Sun, 07 Jul 2013 21:40:23 -0400 Subject: [AstroPy] Loading wavelength from FITS spectrum In-Reply-To: References: Message-ID: <51DA1887.9010508@gmx.de> Hi, this functionality is definitely planned for astropy in the future. We do have a suggested implementation for this (https://github.com/astropy/specutils/pull/18) which worked in the past, but broke due to other changes. We are working on that. If the other suggested methods don't work for you, have a look at the code, which implements the full suite of models in the IRAF/multispec format. Moritz From slianou at uwo.ca Mon Jul 15 17:57:12 2013 From: slianou at uwo.ca (Sofia Lianou) Date: Mon, 15 Jul 2013 17:57:12 -0400 Subject: [AstroPy] IRAF tasks to Astropy In-Reply-To: <77d08d75e10e8.51e4700b@uwo.ca> References: <7680ff4471c32.51cd60c5@uwo.ca> <765091dfe330f.51e46f53@uwo.ca> <76508b49e3265.51e46f8f@uwo.ca> <76108f09e7075.51e46fcd@uwo.ca> <77d08d75e10e8.51e4700b@uwo.ca> Message-ID: <7810f933e4c9c.51e437f8@uwo.ca> Of the three tasks mentioned below, the mkpattern and ccsetwcs can be dealt within astropy alone. The wregister is not clear how to deal with only using astropy or scipy, unless thinking of doing this from scratch. Thus, I am interested in alternatives to wregister within python (but not pyraf), with the following use:wregister input.fits reference.fits output.fits fluxconserve=yes Thanks, Sophia On 07/05/13, Erik Tollerud wrote: > The answer to this probably depends on what you want to do with the > tasks - those tasks have a lot of options and can be used on a variety > of inputs, so there's definitely not an exact mapping onto anything in > astropy. > > Most, if not all of the things that mkpattern seems to do can be done > with just standard numpy array mechanics. E.g., if you wanted to do > > cl> mkpat alpha[201:250,1:50] v1=-1000 > > you could instead do this in python (I *think* I have the indexing > conditions right, but you might want to check it) : > > >>> alpha[200:250, 0:50] = -1000 > > > The other two tasks can be used in a few different ways, but are > generally for creating WCS headers for fits files? In that case, you > can use astropy.io.fits to generate the files, and astropy.wcs to > create the WCS. To go into more details probably requires more > specifics about what you want to do. > > > > > > On Fri, Jun 28, 2013 at 10:09 AM, Sofia Lianou wrote: > > Hi, > > > > I was wondering if there are Python/Astropy equivalents to (or plans to do > > so in the near future for) the following IRAF tasks: > > noao.artdata.mkpattern > > images.immatch.wregister > > images.imcoords.ccsetwcs > > > > Thank you, > > Sophia > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > -- > Erik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.jenness at gmail.com Mon Jul 15 19:21:34 2013 From: tim.jenness at gmail.com (Tim Jenness) Date: Mon, 15 Jul 2013 16:21:34 -0700 Subject: [AstroPy] IRAF tasks to Astropy In-Reply-To: <7810f933e4c9c.51e437f8@uwo.ca> References: <7680ff4471c32.51cd60c5@uwo.ca> <765091dfe330f.51e46f53@uwo.ca> <76508b49e3265.51e46f8f@uwo.ca> <76108f09e7075.51e46fcd@uwo.ca> <77d08d75e10e8.51e4700b@uwo.ca> <7810f933e4c9c.51e437f8@uwo.ca> Message-ID: pyast can do wregister trivially but pyast is not part of astropy. -- Tim Jenness On Mon, Jul 15, 2013 at 2:57 PM, Sofia Lianou wrote: > Of the three tasks mentioned below, the mkpattern and ccsetwcs can be > dealt within astropy alone. The wregister is not clear how to deal with > only using astropy or scipy, unless thinking of doing this from scratch. > Thus, I am interested in alternatives to wregister within python (but not > pyraf), with the following use: > wregister input.fits reference.fits output.fits fluxconserve=yes > > Thanks, > Sophia > > On 07/05/13, *Erik Tollerud * wrote: > > The answer to this probably depends on what you want to do with the > tasks - those tasks have a lot of options and can be used on a variety > of inputs, so there's definitely not an exact mapping onto anything in > astropy. > > Most, if not all of the things that mkpattern seems to do can be done > with just standard numpy array mechanics. E.g., if you wanted to do > > cl> mkpat alpha[201:250,1:50] v1=-1000 > > you could instead do this in python (I *think* I have the indexing > conditions right, but you might want to check it) : > > >>> alpha[200:250, 0:50] = -1000 > > > The other two tasks can be used in a few different ways, but are > generally for creating WCS headers for fits files? In that case, you > can use astropy.io.fits to generate the files, and astropy.wcs to > create the WCS. To go into more details probably requires more > specifics about what you want to do. > > > > > > On Fri, Jun 28, 2013 at 10:09 AM, Sofia Lianou wrote: > > Hi, > > > > I was wondering if there are Python/Astropy equivalents to (or plans to > do > > so in the near future for) the following IRAF tasks: > > noao.artdata.mkpattern > > images.immatch.wregister > > images.imcoords.ccsetwcs > > > > Thank you, > > Sophia > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > -- > Erik > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.pasra at gmail.com Mon Jul 15 19:28:34 2013 From: sergio.pasra at gmail.com (Sergio Pascual) Date: Tue, 16 Jul 2013 01:28:34 +0200 Subject: [AstroPy] message from SOFA chair In-Reply-To: References: <5188D8A3.9050707@nrao.edu> <43A19EA6-232C-43E1-8B59-26D360085E21@gmail.com> Message-ID: Hello, any progress with the SOFA library issue? 2013/6/14 Perry Greenfield > Yes, as a matter of fact, today we got explicit permission from the Board > to relicense SOFA. That will require us to release it under a different > name, and using a different prefix for the routine names. You should be > hearing about it soon. But they will not be changing their license. > > Perry > > On Jun 14, 2013, at 12:06 PM, Sergio Pascual wrote: > > > Hello, > > > > is there any progress in this topic? I have checked today and the > license text in the SOFA webpage remains the same. > > > > Sergio > > > > > > 2013/5/7 Thomas Robitaille > > Just for information, we are currently working towards a solution > > off-list with the SOFA board, and will inform the list once things > > have been settled. So no need to propose a license text at this stage. > > > > Tom > > > > On 7 May 2013 17:15, Wolfgang Kerzendorf wrote: > > > I think what Mario and Tim are proposing is very good as it would > alleviate > > > the problems mentioned by Catherine. To speed up the process, we should > > > propose a license text and they could then see if that meets their > criteria > > > (make it as hard as possible for them to delay or refuse). > > > > > > Cheers > > > Wolfgang > > > On 2013-05-07, at 10:45 AM, Tim Jenness wrote: > > > > > > Thanks. > > > > > > > > > On Tue, May 7, 2013 at 3:34 AM, Scott Ransom wrote: > > >> > > >> > > >> On the subject of the SOFA license conditions, our Board member > Patrick > > >> Wallace is continuing discussions he had on this topic last year, > which > > >> resulted in changes to the license that enabled the Debian release to > > >> proceed. Recent emails, which unfortunately were delayed by the spam > > >> filter problems, show that further discussion is needed, and Patrick > is > > >> now in touch with Perry Greenfield, STScI Science Software Branch > lead. > > >> The nub of the problem is that SOFA software has to address two > > >> conflicting requirements: (i) the insistence by free software groups > > >> that users should not be constrained in any way and (ii) the need to > > >> prevent "counterfeit" versions coming into circulation. The second > > >> point is vital because SOFA software represents IAU standards and > indeed > > >> is cited in other standards such as IERS Conventions. > > >> > > >> > > > > > > Regarding the counterfeit argument, isn't this very similar to > encryption > > > libraries where you want to make sure that you are using the official > > > library and not one you found on the internet that happens to have a > back > > > door? OpenSSL and other libraries deal with this. People are far more > > > concerned about using the proper OpenSSL than using SOFA but the > underlying > > > principal is the same. OpenSSL has a very straightforward licence > > > (http://www.openssl.org/source/license.html) which has clearly been > approved > > > for distribution. > > > > > > -- > > > Tim Jenness > > > CCAT Software Manager > > > _______________________________________________ > > > AstroPy mailing list > > > AstroPy at scipy.org > > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > > > > > > > _______________________________________________ > > > AstroPy mailing list > > > AstroPy at scipy.org > > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsinger at caltech.edu Mon Jul 15 21:27:08 2013 From: lsinger at caltech.edu (Leo Singer) Date: Mon, 15 Jul 2013 18:27:08 -0700 Subject: [AstroPy] WCS world to pixel conversion with SIP correction? Message-ID: <69547874-AEC2-442C-9D4E-D7A6F6BEA48A@caltech.edu> Hello, I want to look up the pixel coordinates in a FITS image from the world coordinates (RA, Dec in ICRS), but the image has SIP distortion parameters. I noticed that the function WCS.wcs_world2pix does not perform the SIP transformation, and there is apparently no inverse function of WCS.all_pix2world. There is this open issue: Iterative implementation of wcs.all_world2pix https://github.com/astropy/astropy/issues/1066 Am I perhaps looking in the wrong place? Is there a sequence of existing function calls to convert from pixel to world coordinates, including the distortion correction? Thanks, Leo Singer Graduate Student @ LIGO-Caltech From d.berry at jach.hawaii.edu Tue Jul 16 03:22:02 2013 From: d.berry at jach.hawaii.edu (David Berry) Date: Tue, 16 Jul 2013 08:22:02 +0100 Subject: [AstroPy] WCS world to pixel conversion with SIP correction? In-Reply-To: <69547874-AEC2-442C-9D4E-D7A6F6BEA48A@caltech.edu> References: <69547874-AEC2-442C-9D4E-D7A6F6BEA48A@caltech.edu> Message-ID: It's not astropy, but you can do this using pyast (http://dsberry.github.io/starlink/pyast.html) - a python wrapper for the WCS library used by DS9. For example, the following reads the SIP header, converts some pixel positions into (RA,Dec) and then converts them back to pixel positions. David import pyfits import starlink.Atl as Atl # Read the FITS headers and get an AST FrameSet describing the # full WCS. hdulist = pyfits.open( "sip.fits" ) frameset,encoding = Atl.readfitswcs( hdulist ) # Transform some pixel positions into (RA,Dec) positions and display them (in radians). x = [ 30.0, 40.0, 50.0 ] y = [ 10.0, 60.0, 100.0 ] ra,dec = frameset.tran( [ x, y ] ) print( ra, dec ) # Transform them back to pixel positions. x,y = frameset.tran( [ ra, dec ], False ) print( x, y ) On 16 July 2013 02:27, Leo Singer wrote: > Hello, > > I want to look up the pixel coordinates in a FITS image from the world coordinates (RA, Dec in ICRS), but the image has SIP distortion parameters. I noticed that the function WCS.wcs_world2pix does not perform the SIP transformation, and there is apparently no inverse function of WCS.all_pix2world. > > There is this open issue: > > Iterative implementation of wcs.all_world2pix > https://github.com/astropy/astropy/issues/1066 > > Am I perhaps looking in the wrong place? Is there a sequence of existing function calls to convert from pixel to world coordinates, including the distortion correction? > > Thanks, > Leo Singer > Graduate Student @ LIGO-Caltech > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From stsci.perry at gmail.com Tue Jul 16 07:42:40 2013 From: stsci.perry at gmail.com (Perry Greenfield) Date: Tue, 16 Jul 2013 07:42:40 -0400 Subject: [AstroPy] message from SOFA chair In-Reply-To: References: <5188D8A3.9050707@nrao.edu> <43A19EA6-232C-43E1-8B59-26D360085E21@gmail.com> Message-ID: <9E4F82A1-F81B-445F-BD2E-D7BCC2742027@gmail.com> I'm sorry we didn't inform the general list, but on June 14, the SOFA board did approve the relicensing of SOFA in the form of the ERFA library that has a 3 clause BSD license, and a different prefix (not iau_ for the routine names). It is this that will be distributed with astropy. This should permit the inclusion of ERFA with many standard distributions that would not allow the inclusion of SOFA. Perry On Jul 15, 2013, at 7:28 PM, Sergio Pascual wrote: > Hello, any progress with the SOFA library issue? > > > 2013/6/14 Perry Greenfield > Yes, as a matter of fact, today we got explicit permission from the Board to relicense SOFA. That will require us to release it under a different name, and using a different prefix for the routine names. You should be hearing about it soon. But they will not be changing their license. > > Perry > > On Jun 14, 2013, at 12:06 PM, Sergio Pascual wrote: > > > Hello, > > > > is there any progress in this topic? I have checked today and the license text in the SOFA webpage remains the same. > > > > Sergio > > > > > > 2013/5/7 Thomas Robitaille > > Just for information, we are currently working towards a solution > > off-list with the SOFA board, and will inform the list once things > > have been settled. So no need to propose a license text at this stage. > > > > Tom > > > > On 7 May 2013 17:15, Wolfgang Kerzendorf wrote: > > > I think what Mario and Tim are proposing is very good as it would alleviate > > > the problems mentioned by Catherine. To speed up the process, we should > > > propose a license text and they could then see if that meets their criteria > > > (make it as hard as possible for them to delay or refuse). > > > > > > Cheers > > > Wolfgang > > > On 2013-05-07, at 10:45 AM, Tim Jenness wrote: > > > > > > Thanks. > > > > > > > > > On Tue, May 7, 2013 at 3:34 AM, Scott Ransom wrote: > > >> > > >> > > >> On the subject of the SOFA license conditions, our Board member Patrick > > >> Wallace is continuing discussions he had on this topic last year, which > > >> resulted in changes to the license that enabled the Debian release to > > >> proceed. Recent emails, which unfortunately were delayed by the spam > > >> filter problems, show that further discussion is needed, and Patrick is > > >> now in touch with Perry Greenfield, STScI Science Software Branch lead. > > >> The nub of the problem is that SOFA software has to address two > > >> conflicting requirements: (i) the insistence by free software groups > > >> that users should not be constrained in any way and (ii) the need to > > >> prevent "counterfeit" versions coming into circulation. The second > > >> point is vital because SOFA software represents IAU standards and indeed > > >> is cited in other standards such as IERS Conventions. > > >> > > >> > > > > > > Regarding the counterfeit argument, isn't this very similar to encryption > > > libraries where you want to make sure that you are using the official > > > library and not one you found on the internet that happens to have a back > > > door? OpenSSL and other libraries deal with this. People are far more > > > concerned about using the proper OpenSSL than using SOFA but the underlying > > > principal is the same. OpenSSL has a very straightforward licence > > > (http://www.openssl.org/source/license.html) which has clearly been approved > > > for distribution. > > > > > > -- > > > Tim Jenness > > > CCAT Software Manager > > > _______________________________________________ > > > AstroPy mailing list > > > AstroPy at scipy.org > > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > > > > > > > _______________________________________________ > > > AstroPy mailing list > > > AstroPy at scipy.org > > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > From sergio.pasra at gmail.com Tue Jul 16 10:16:49 2013 From: sergio.pasra at gmail.com (Sergio Pascual) Date: Tue, 16 Jul 2013 16:16:49 +0200 Subject: [AstroPy] message from SOFA chair In-Reply-To: <9E4F82A1-F81B-445F-BD2E-D7BCC2742027@gmail.com> References: <5188D8A3.9050707@nrao.edu> <43A19EA6-232C-43E1-8B59-26D360085E21@gmail.com> <9E4F82A1-F81B-445F-BD2E-D7BCC2742027@gmail.com> Message-ID: That's good news, because it will allow, finally, to include astropy in linux distributions. And other projects will benefit by having a free SOFA replacement. I assume this is the github repo, https://github.com/liberfa/erfa correct? 2013/7/16 Perry Greenfield > I'm sorry we didn't inform the general list, but on June 14, the SOFA > board did approve the relicensing of SOFA in the form of the ERFA library > that has a 3 clause BSD license, and a different prefix (not iau_ for the > routine names). It is this that will be distributed with astropy. This > should permit the inclusion of ERFA with many standard distributions that > would not allow the inclusion of SOFA. > > Perry > > On Jul 15, 2013, at 7:28 PM, Sergio Pascual wrote: > > > Hello, any progress with the SOFA library issue? > > > > > > 2013/6/14 Perry Greenfield > > Yes, as a matter of fact, today we got explicit permission from the > Board to relicense SOFA. That will require us to release it under a > different name, and using a different prefix for the routine names. You > should be hearing about it soon. But they will not be changing their > license. > > > > Perry > > > > On Jun 14, 2013, at 12:06 PM, Sergio Pascual wrote: > > > > > Hello, > > > > > > is there any progress in this topic? I have checked today and the > license text in the SOFA webpage remains the same. > > > > > > Sergio > > > > > > > > > 2013/5/7 Thomas Robitaille > > > Just for information, we are currently working towards a solution > > > off-list with the SOFA board, and will inform the list once things > > > have been settled. So no need to propose a license text at this stage. > > > > > > Tom > > > > > > On 7 May 2013 17:15, Wolfgang Kerzendorf > wrote: > > > > I think what Mario and Tim are proposing is very good as it would > alleviate > > > > the problems mentioned by Catherine. To speed up the process, we > should > > > > propose a license text and they could then see if that meets their > criteria > > > > (make it as hard as possible for them to delay or refuse). > > > > > > > > Cheers > > > > Wolfgang > > > > On 2013-05-07, at 10:45 AM, Tim Jenness > wrote: > > > > > > > > Thanks. > > > > > > > > > > > > On Tue, May 7, 2013 at 3:34 AM, Scott Ransom > wrote: > > > >> > > > >> > > > >> On the subject of the SOFA license conditions, our Board member > Patrick > > > >> Wallace is continuing discussions he had on this topic last year, > which > > > >> resulted in changes to the license that enabled the Debian release > to > > > >> proceed. Recent emails, which unfortunately were delayed by the > spam > > > >> filter problems, show that further discussion is needed, and > Patrick is > > > >> now in touch with Perry Greenfield, STScI Science Software Branch > lead. > > > >> The nub of the problem is that SOFA software has to address two > > > >> conflicting requirements: (i) the insistence by free software groups > > > >> that users should not be constrained in any way and (ii) the need to > > > >> prevent "counterfeit" versions coming into circulation. The second > > > >> point is vital because SOFA software represents IAU standards and > indeed > > > >> is cited in other standards such as IERS Conventions. > > > >> > > > >> > > > > > > > > Regarding the counterfeit argument, isn't this very similar to > encryption > > > > libraries where you want to make sure that you are using the official > > > > library and not one you found on the internet that happens to have a > back > > > > door? OpenSSL and other libraries deal with this. People are far more > > > > concerned about using the proper OpenSSL than using SOFA but the > underlying > > > > principal is the same. OpenSSL has a very straightforward licence > > > > (http://www.openssl.org/source/license.html) which has clearly been > approved > > > > for distribution. > > > > > > > > -- > > > > Tim Jenness > > > > CCAT Software Manager > > > > _______________________________________________ > > > > AstroPy mailing list > > > > AstroPy at scipy.org > > > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > > > > > > > > > > > _______________________________________________ > > > > AstroPy mailing list > > > > AstroPy at scipy.org > > > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > > _______________________________________________ > > > AstroPy mailing list > > > AstroPy at scipy.org > > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > _______________________________________________ > > > AstroPy mailing list > > > AstroPy at scipy.org > > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsci.perry at gmail.com Tue Jul 16 10:20:11 2013 From: stsci.perry at gmail.com (Perry Greenfield) Date: Tue, 16 Jul 2013 10:20:11 -0400 Subject: [AstroPy] message from SOFA chair In-Reply-To: References: <5188D8A3.9050707@nrao.edu> <43A19EA6-232C-43E1-8B59-26D360085E21@gmail.com> <9E4F82A1-F81B-445F-BD2E-D7BCC2742027@gmail.com> Message-ID: On Jul 16, 2013, at 10:16 AM, Sergio Pascual wrote: > That's good news, because it will allow, finally, to include astropy in linux distributions. And other projects will benefit by having a free SOFA replacement. > > I assume this is the github repo, > > https://github.com/liberfa/erfa > > correct? > correct. From miguel.deval at gmail.com Wed Jul 17 11:56:12 2013 From: miguel.deval at gmail.com (Miguel de Val-Borro) Date: Wed, 17 Jul 2013 11:56:12 -0400 Subject: [AstroPy] FITS image data dtype Message-ID: <20130717155612.GM9016@cfhs5> Hi, I have some FITS images that are read with pyfits 3.0.8 and a dtype of '>f8'. However I am using an AMD processor and I find some problems when handling the data. I have tried to swap the data byte order and the dtype using: >>> map = hdulist[1].data.byteswap().newbyteorder() >>> print map.dtype float64 Then the resulting array seems to be fine. Is this what needs to be done, and why is pyfits not swapping to the little-endian type based on the system architecture? Miguel From embray at stsci.edu Wed Jul 17 12:14:16 2013 From: embray at stsci.edu (Erik Bray) Date: Wed, 17 Jul 2013 12:14:16 -0400 Subject: [AstroPy] FITS image data dtype In-Reply-To: <20130717155612.GM9016@cfhs5> References: <20130717155612.GM9016@cfhs5> Message-ID: <51E6C2D8.7040504@stsci.edu> On 07/17/2013 11:56 AM, Miguel de Val-Borro wrote: > Hi, > > I have some FITS images that are read with pyfits 3.0.8 and a dtype of > '>f8'. However I am using an AMD processor and I find some problems when > handling the data. I have tried to swap the data byte order and the > dtype using: > >>>> map = hdulist[1].data.byteswap().newbyteorder() >>>> print map.dtype > float64 > > Then the resulting array seems to be fine. Is this what needs to be > done, and why is pyfits not swapping to the little-endian type based on > the system architecture? FITS files store arrays in big-endian order natively. Actually swapping the bytes to native order can be costly, especially when the data is being accessed by way of an mmap'd file (the default in PyFITS 3.1 and up). And it's generally unnecessary when working within Numpy--it is only necessary if passing those bytes to other software that is expecting values in native byte order. Erik From miguel.deval at gmail.com Wed Jul 17 15:24:27 2013 From: miguel.deval at gmail.com (Miguel de Val-Borro) Date: Wed, 17 Jul 2013 15:24:27 -0400 Subject: [AstroPy] FITS image data dtype In-Reply-To: <51E6C2D8.7040504@stsci.edu> References: <20130717155612.GM9016@cfhs5> <51E6C2D8.7040504@stsci.edu> Message-ID: <20130717192427.GO9016@cfhs5> On Wed, Jul 17, 2013 at 12:14:16PM -0400, Erik Bray wrote: > FITS files store arrays in big-endian order natively. Actually swapping the > bytes to native order can be costly, especially when the data is being accessed > by way of an mmap'd file (the default in PyFITS 3.1 and up). And it's generally > unnecessary when working within Numpy--it is only necessary if passing those > bytes to other software that is expecting values in native byte order. The matplotlib function imshow shows the original map differently than after swapping the byte order to little-endian format. imshow(hdulist[1].data) https://docs.google.com/file/d/0B3Hv-zV2q5IcSjk2amw3ZmM3Mk0/edit imshow(hdulist[1].data.byteswap().newbyteorder()) https://docs.google.com/file/d/0B3Hv-zV2q5IcTWZ2WXduMWttQUE/edit If I remember correctly I also had problems with numpy array operations on the maps with the '>f8' dtype for this kind of image data. Miguel From embray at stsci.edu Wed Jul 17 16:28:07 2013 From: embray at stsci.edu (Erik Bray) Date: Wed, 17 Jul 2013 16:28:07 -0400 Subject: [AstroPy] FITS image data dtype In-Reply-To: <20130717192427.GO9016@cfhs5> References: <20130717155612.GM9016@cfhs5> <51E6C2D8.7040504@stsci.edu> <20130717192427.GO9016@cfhs5> Message-ID: <51E6FE57.1020200@stsci.edu> On 07/17/2013 03:24 PM, Miguel de Val-Borro wrote: > On Wed, Jul 17, 2013 at 12:14:16PM -0400, Erik Bray wrote: >> FITS files store arrays in big-endian order natively. Actually swapping the >> bytes to native order can be costly, especially when the data is being accessed >> by way of an mmap'd file (the default in PyFITS 3.1 and up). And it's generally >> unnecessary when working within Numpy--it is only necessary if passing those >> bytes to other software that is expecting values in native byte order. > > The matplotlib function imshow shows the original map differently than > after swapping the byte order to little-endian format. > > imshow(hdulist[1].data) > https://docs.google.com/file/d/0B3Hv-zV2q5IcSjk2amw3ZmM3Mk0/edit > imshow(hdulist[1].data.byteswap().newbyteorder()) > https://docs.google.com/file/d/0B3Hv-zV2q5IcTWZ2WXduMWttQUE/edit > > If I remember correctly I also had problems with numpy array operations > on the maps with the '>f8' dtype for this kind of image data. Hmmm.. This sounds really familiar but I think it's actually a bug in matplotlib. Just be sure why don't you make sure that np.all(hdulist[1].data == hdulist[1].data.byteswap().newbyteorder()) If that doesn't return True I'll eat my shoe. Unfortunately I don't think I ever figured out what the exact cause was. But can you rule out for certain that the values are not different? Erik From miguel.deval at gmail.com Wed Jul 17 16:52:35 2013 From: miguel.deval at gmail.com (Miguel de Val-Borro) Date: Wed, 17 Jul 2013 16:52:35 -0400 Subject: [AstroPy] FITS image data dtype In-Reply-To: <51E6FE57.1020200@stsci.edu> References: <20130717155612.GM9016@cfhs5> <51E6C2D8.7040504@stsci.edu> <20130717192427.GO9016@cfhs5> <51E6FE57.1020200@stsci.edu> Message-ID: <20130717205235.GQ9016@cfhs5> On Wed, Jul 17, 2013 at 04:28:07PM -0400, Erik Bray wrote: > >> FITS files store arrays in big-endian order natively. Actually swapping the > >> bytes to native order can be costly, especially when the data is being accessed > >> by way of an mmap'd file (the default in PyFITS 3.1 and up). And it's generally > >> unnecessary when working within Numpy--it is only necessary if passing those > >> bytes to other software that is expecting values in native byte order. > > > > The matplotlib function imshow shows the original map differently than > > after swapping the byte order to little-endian format. > > > > imshow(hdulist[1].data) > > https://docs.google.com/file/d/0B3Hv-zV2q5IcSjk2amw3ZmM3Mk0/edit > > imshow(hdulist[1].data.byteswap().newbyteorder()) > > https://docs.google.com/file/d/0B3Hv-zV2q5IcTWZ2WXduMWttQUE/edit > > > > If I remember correctly I also had problems with numpy array operations > > on the maps with the '>f8' dtype for this kind of image data. > > Hmmm.. This sounds really familiar but I think it's actually a bug in matplotlib. > > Just be sure why don't you make sure that np.all(hdulist[1].data == > hdulist[1].data.byteswap().newbyteorder()) If that doesn't return True I'll eat > my shoe. Yes, it returns True. It could be a bug in matplotlib and not something related to pyfits, I will try to find more information to debug the problem. At least it's good to know that swapping the byte order helps to be able to display the image. Thanks, Miguel From embray at stsci.edu Wed Jul 17 17:01:23 2013 From: embray at stsci.edu (Erik Bray) Date: Wed, 17 Jul 2013 17:01:23 -0400 Subject: [AstroPy] FITS image data dtype In-Reply-To: <20130717205235.GQ9016@cfhs5> References: <20130717155612.GM9016@cfhs5> <51E6C2D8.7040504@stsci.edu> <20130717192427.GO9016@cfhs5> <51E6FE57.1020200@stsci.edu> <20130717205235.GQ9016@cfhs5> Message-ID: <51E70623.8080004@stsci.edu> On 07/17/2013 04:52 PM, Miguel de Val-Borro wrote: > On Wed, Jul 17, 2013 at 04:28:07PM -0400, Erik Bray wrote: >>>> FITS files store arrays in big-endian order natively. Actually swapping the >>>> bytes to native order can be costly, especially when the data is being accessed >>>> by way of an mmap'd file (the default in PyFITS 3.1 and up). And it's generally >>>> unnecessary when working within Numpy--it is only necessary if passing those >>>> bytes to other software that is expecting values in native byte order. >>> >>> The matplotlib function imshow shows the original map differently than >>> after swapping the byte order to little-endian format. >>> >>> imshow(hdulist[1].data) >>> https://docs.google.com/file/d/0B3Hv-zV2q5IcSjk2amw3ZmM3Mk0/edit >>> imshow(hdulist[1].data.byteswap().newbyteorder()) >>> https://docs.google.com/file/d/0B3Hv-zV2q5IcTWZ2WXduMWttQUE/edit >>> >>> If I remember correctly I also had problems with numpy array operations >>> on the maps with the '>f8' dtype for this kind of image data. >> >> Hmmm.. This sounds really familiar but I think it's actually a bug in matplotlib. >> >> Just be sure why don't you make sure that np.all(hdulist[1].data == >> hdulist[1].data.byteswap().newbyteorder()) If that doesn't return True I'll eat >> my shoe. > > Yes, it returns True. It could be a bug in matplotlib and not something > related to pyfits, I will try to find more information to debug the > problem. At least it's good to know that swapping the byte order helps > to be able to display the image. I found the old code sent to me from my coworker who had this same problem. I remember puzzling over it for some time and never quite figuring out exactly what combination of software versions was required to reproduce it. But indeed, it seems like matplotlib is rending the pixel with the max value in the array as 0, or close to it. When I swap the byte order to little-endian it renders correctly. Might be worth bringing up with the matplotlib people (though I can confirm that on my installation of mpl 1.2.0 this bug does not manifest). Erik From embray at stsci.edu Wed Jul 17 17:41:47 2013 From: embray at stsci.edu (Erik Bray) Date: Wed, 17 Jul 2013 17:41:47 -0400 Subject: [AstroPy] FITS image data dtype In-Reply-To: <51E70623.8080004@stsci.edu> References: <20130717155612.GM9016@cfhs5> <51E6C2D8.7040504@stsci.edu> <20130717192427.GO9016@cfhs5> <51E6FE57.1020200@stsci.edu> <20130717205235.GQ9016@cfhs5> <51E70623.8080004@stsci.edu> Message-ID: <51E70F9B.2050303@stsci.edu> On 07/17/2013 05:01 PM, Erik Bray wrote: > On 07/17/2013 04:52 PM, Miguel de Val-Borro wrote: >> On Wed, Jul 17, 2013 at 04:28:07PM -0400, Erik Bray wrote: >>>>> FITS files store arrays in big-endian order natively. Actually swapping the >>>>> bytes to native order can be costly, especially when the data is being accessed >>>>> by way of an mmap'd file (the default in PyFITS 3.1 and up). And it's generally >>>>> unnecessary when working within Numpy--it is only necessary if passing those >>>>> bytes to other software that is expecting values in native byte order. >>>> >>>> The matplotlib function imshow shows the original map differently than >>>> after swapping the byte order to little-endian format. >>>> >>>> imshow(hdulist[1].data) >>>> https://docs.google.com/file/d/0B3Hv-zV2q5IcSjk2amw3ZmM3Mk0/edit >>>> imshow(hdulist[1].data.byteswap().newbyteorder()) >>>> https://docs.google.com/file/d/0B3Hv-zV2q5IcTWZ2WXduMWttQUE/edit >>>> >>>> If I remember correctly I also had problems with numpy array operations >>>> on the maps with the '>f8' dtype for this kind of image data. >>> >>> Hmmm.. This sounds really familiar but I think it's actually a bug in matplotlib. >>> >>> Just be sure why don't you make sure that np.all(hdulist[1].data == >>> hdulist[1].data.byteswap().newbyteorder()) If that doesn't return True I'll eat >>> my shoe. >> >> Yes, it returns True. It could be a bug in matplotlib and not something >> related to pyfits, I will try to find more information to debug the >> problem. At least it's good to know that swapping the byte order helps >> to be able to display the image. > > I found the old code sent to me from my coworker who had this same problem. I > remember puzzling over it for some time and never quite figuring out exactly > what combination of software versions was required to reproduce it. But indeed, > it seems like matplotlib is rending the pixel with the max value in the array as > 0, or close to it. When I swap the byte order to little-endian it renders > correctly. Might be worth bringing up with the matplotlib people (though I can > confirm that on my installation of mpl 1.2.0 this bug does not manifest). I think I've tracked it down. This is about where the bug *was*: https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/colors.py#L554 But it's fixed in master, at least (and I think in 1.2). Erik From miguel.deval at gmail.com Thu Jul 18 18:52:37 2013 From: miguel.deval at gmail.com (Miguel de Val-Borro) Date: Thu, 18 Jul 2013 18:52:37 -0400 Subject: [AstroPy] PSF deconvolution Message-ID: <20130718225237.GA9016@cfhs5> Hi, Are there any python tools to do deconvolution of 2-D images? I have tried to use the fftn, ifftn, fftshift and ifftshift functions from the scipy.fftpack library to do PSF deconvolution but did not get very good results for images of extended and asymmetric sources. I have noticed there is an astropy.nddata.convolution.convolve function but I'm not sure if it could be adapted easily to be used for PSF deconvolution. Regards, Miguel From sergio.pasra at gmail.com Fri Jul 19 13:33:55 2013 From: sergio.pasra at gmail.com (Sergio Pascual) Date: Fri, 19 Jul 2013 19:33:55 +0200 Subject: [AstroPy] message from SOFA chair In-Reply-To: References: <5188D8A3.9050707@nrao.edu> <43A19EA6-232C-43E1-8B59-26D360085E21@gmail.com> <9E4F82A1-F81B-445F-BD2E-D7BCC2742027@gmail.com> Message-ID: Is there any plan to substitue SOFA by ERFA in the astropy code? It still has a sofa directory under astropy/cextern 2013/7/16 Perry Greenfield > > On Jul 16, 2013, at 10:16 AM, Sergio Pascual wrote: > > > That's good news, because it will allow, finally, to include astropy in > linux distributions. And other projects will benefit by having a free SOFA > replacement. > > > > I assume this is the github repo, > > > > https://github.com/liberfa/erfa > > > > correct? > > > correct. -------------- next part -------------- An HTML attachment was scrubbed... URL: From demitri.muna at gmail.com Fri Jul 19 14:20:23 2013 From: demitri.muna at gmail.com (Demitri Muna) Date: Fri, 19 Jul 2013 14:20:23 -0400 Subject: [AstroPy] The trouble with FITS. Message-ID: Hello, I started a thread on astropy-dev [1] about a problem I was having reading a very large (~2GB) FITS file, and it led to a discussion about the FITS format itself. I wanted to redirect that conversation here as this list is more appropriate and deserves as wide an audience in the astronomical community as possible. (Not that this is it, but it's wider than astropy-dev.) There are two - separate - issues here: 1) The FITS format is problematic, often hard to deal with, and its maintainers have given us the impression that there is negligible interest/resources to properly update the format into the 21st century. However, we acknowledge that FITS as a format is not going anywhere and needs to be supported into the indefinite future - there are literally decades of astronomical data in that format that cannot - should not! - be abandoned. 2) It is worth discussing a new astronomical format that is more modern and better to deal with. The first step in that process is coming up with a community sourced list of requirements that we would all have for this format. To this end I'd like to open discussion. I've created two Google Drive documents (one for each point above) that anyone can edit. I'd recommend that discussion be kept on this list (as opposed to the documents), and that the documents contain the points distilled from the discussion. The first document is here: http://bit.ly/12Pjt98 I will post the second one on a separate thread as I think these two discussions should remain separate. Cheers, Demitri _________________________________________ Demitri Muna Department of Astronomy Ohio State University http://scicoder.org/ [1] https://groups.google.com/forum/#!topic/astropy-dev/zRIZ6rr4JPg From demitri.muna at gmail.com Fri Jul 19 14:21:07 2013 From: demitri.muna at gmail.com (Demitri Muna) Date: Fri, 19 Jul 2013 14:21:07 -0400 Subject: [AstroPy] A replacement for the FITS format. Message-ID: <13D245F5-9F4D-44DD-90A9-82E84B8594AD@gmail.com> Hello, See introduction in the email "The trouble with FITS". The Google document I created for this is here: http://bit.ly/1dKcKih Cheers, Demitri _________________________________________ Demitri Muna Department of Astronomy Ohio State University http://scicoder.org/ From tim.jenness at gmail.com Fri Jul 19 14:27:06 2013 From: tim.jenness at gmail.com (Tim Jenness) Date: Fri, 19 Jul 2013 11:27:06 -0700 Subject: [AstroPy] The trouble with FITS. In-Reply-To: References: Message-ID: Brian Thomas started a similar discussion with a group of like-minded individuals after the Urbana ADASS. Frossie Economou and Brian have got a draft whitepaper discussing many of the issues. It might be worth building on that discussion rather than starting from scratch again. -- Tim Jenness On Fri, Jul 19, 2013 at 11:20 AM, Demitri Muna wrote: > Hello, > > I started a thread on astropy-dev [1] about a problem I was having reading > a very large (~2GB) FITS file, and it led to a discussion about the FITS > format itself. I wanted to redirect that conversation here as this list is > more appropriate and deserves as wide an audience in the astronomical > community as possible. (Not that this is it, but it's wider than > astropy-dev.) > > There are two - separate - issues here: > > 1) The FITS format is problematic, often hard to deal with, and its > maintainers have given us the impression that there is negligible > interest/resources to properly update the format into the 21st century. > However, we acknowledge that FITS as a format is not going anywhere and > needs to be supported into the indefinite future - there are literally > decades of astronomical data in that format that cannot - should not! - be > abandoned. > > 2) It is worth discussing a new astronomical format that is more modern > and better to deal with. The first step in that process is coming up with a > community sourced list of requirements that we would all have for this > format. > > To this end I'd like to open discussion. I've created two Google Drive > documents (one for each point above) that anyone can edit. I'd recommend > that discussion be kept on this list (as opposed to the documents), and > that the documents contain the points distilled from the discussion. > > The first document is here: > > http://bit.ly/12Pjt98 > > I will post the second one on a separate thread as I think these two > discussions should remain separate. > > Cheers, > Demitri > > _________________________________________ > Demitri Muna > > Department of Astronomy > Ohio State University > > http://scicoder.org/ > > > [1] https://groups.google.com/forum/#!topic/astropy-dev/zRIZ6rr4JPg > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsci.perry at gmail.com Fri Jul 19 14:35:20 2013 From: stsci.perry at gmail.com (Perry Greenfield) Date: Fri, 19 Jul 2013 14:35:20 -0400 Subject: [AstroPy] The trouble with FITS. In-Reply-To: References: Message-ID: <2C272054-AD33-47A2-BD03-22F2414ECB62@gmail.com> You can see the previous discussion on google groups by searching for "astrodataformat". My last post with WCS examples seems to have killed all activity on that list. :-( I am planning on posting my wcs examples here today along with a high level outline of where we are heading with a new format. On Jul 19, 2013, at 2:27 PM, Tim Jenness wrote: > Brian Thomas started a similar discussion with a group of like-minded individuals after the Urbana ADASS. Frossie Economou and Brian have got a draft whitepaper discussing many of the issues. It might be worth building on that discussion rather than starting from scratch again. > > -- > Tim Jenness > > > On Fri, Jul 19, 2013 at 11:20 AM, Demitri Muna wrote: > Hello, > > I started a thread on astropy-dev [1] about a problem I was having reading a very large (~2GB) FITS file, and it led to a discussion about the FITS format itself. I wanted to redirect that conversation here as this list is more appropriate and deserves as wide an audience in the astronomical community as possible. (Not that this is it, but it's wider than astropy-dev.) > > There are two - separate - issues here: > > 1) The FITS format is problematic, often hard to deal with, and its maintainers have given us the impression that there is negligible interest/resources to properly update the format into the 21st century. However, we acknowledge that FITS as a format is not going anywhere and needs to be supported into the indefinite future - there are literally decades of astronomical data in that format that cannot - should not! - be abandoned. > > 2) It is worth discussing a new astronomical format that is more modern and better to deal with. The first step in that process is coming up with a community sourced list of requirements that we would all have for this format. > > To this end I'd like to open discussion. I've created two Google Drive documents (one for each point above) that anyone can edit. I'd recommend that discussion be kept on this list (as opposed to the documents), and that the documents contain the points distilled from the discussion. > > The first document is here: > > http://bit.ly/12Pjt98 > > I will post the second one on a separate thread as I think these two discussions should remain separate. > > Cheers, > Demitri > > _________________________________________ > Demitri Muna > > Department of Astronomy > Ohio State University > > http://scicoder.org/ > > > [1] https://groups.google.com/forum/#!topic/astropy-dev/zRIZ6rr4JPg > > _______________________________________________ > 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 thomas.robitaille at gmail.com Sat Jul 20 03:33:04 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sat, 20 Jul 2013 09:33:04 +0200 Subject: [AstroPy] message from SOFA chair In-Reply-To: References: <5188D8A3.9050707@nrao.edu> <43A19EA6-232C-43E1-8B59-26D360085E21@gmail.com> <9E4F82A1-F81B-445F-BD2E-D7BCC2742027@gmail.com> Message-ID: There is an issue to keep track of this, but I don't know if anyone is actively working on this right now: https://github.com/astropy/astropy/issues/1195 It might be good to try and get it into 0.2.5 since license issue could be considered a 'bug' (I think 0.2.4 would be pushing it). Cheers, Tom On 19 July 2013 19:33, Sergio Pascual wrote: > Is there any plan to substitue SOFA by ERFA in the astropy code? It still > has a sofa directory under > astropy/cextern > > > 2013/7/16 Perry Greenfield >> >> >> On Jul 16, 2013, at 10:16 AM, Sergio Pascual wrote: >> >> > That's good news, because it will allow, finally, to include astropy in >> > linux distributions. And other projects will benefit by having a free SOFA >> > replacement. >> > >> > I assume this is the github repo, >> > >> > https://github.com/liberfa/erfa >> > >> > correct? >> > >> correct. > > From wkerzendorf at gmail.com Sat Jul 20 14:22:53 2013 From: wkerzendorf at gmail.com (Wolfgang Kerzendorf) Date: Sat, 20 Jul 2013 14:22:53 -0400 Subject: [AstroPy] Looking for students to join ESA Summer of Code Message-ID: <0C70768D-B92C-40E6-9778-CA64FC6B4AAE@gmail.com> We are seeking a student to work on specutils, the astropy affiliated package for spectrosopic data analysis, as part of the ESA Summer of Code in Space program (SOCIS)! The ESA Summer of Code in Space program (SOCIS; http://sophia.estec.esa.int/socis2013/) is designed to attract undergraduate and graduate developers to write code to for various space related open source software projects. It offers a sizeable remuneration of 4000 Euros for a coding period of 3 months (mid-August to mid-November). Astropy/specutils has been selected as a mentoring organizations and is now accepting applications (for details please go to https://github.com/astropy/specutils/wiki/SoCiS-2013-ideas; deadline is 4th of August). The Astropy Project is a community effort to develop a single core package for Astronomy in Python and foster interoperability between Python astronomy packages. Our SOCIS mentorship will focus on expanding the astropy-specutils package that is designed to deal with code that focuses on spectral data analysis. ESA has some eligibility criteria http://sophia.estec.esa.int/socis2012/?q=faq#socis_elig_restrictions. Thanks, the astropy/specutils team Please forward this email to interested parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4145 bytes Desc: not available URL: From embray at stsci.edu Mon Jul 22 10:25:49 2013 From: embray at stsci.edu (Erik Bray) Date: Mon, 22 Jul 2013 10:25:49 -0400 Subject: [AstroPy] A replacement for the FITS format. In-Reply-To: <13D245F5-9F4D-44DD-90A9-82E84B8594AD@gmail.com> References: <13D245F5-9F4D-44DD-90A9-82E84B8594AD@gmail.com> Message-ID: <51ED40ED.4020103@stsci.edu> On 07/19/2013 02:21 PM, Demitri Muna wrote: > Hello, > > See introduction in the email "The trouble with FITS". The Google document I created for this is here: > > http://bit.ly/1dKcKih > > Cheers, > Demitri I think that the last bullet point could use clarification. The way I might word this is that it should be possible to order table data in row-order or column-order depending on how it is most likely to be accessed. This is of course a determination that would have to be made by the user, and sometimes there is no right answer (but where there is a right answer it should be possible to do). From deil.christoph at googlemail.com Mon Jul 22 13:19:12 2013 From: deil.christoph at googlemail.com (Christoph Deil) Date: Mon, 22 Jul 2013 19:19:12 +0200 Subject: [AstroPy] A replacement for the FITS format. In-Reply-To: <51ED40ED.4020103@stsci.edu> References: <13D245F5-9F4D-44DD-90A9-82E84B8594AD@gmail.com> <51ED40ED.4020103@stsci.edu> Message-ID: <9400DB47-D2A4-465E-BDF1-DD243BE6E7A8@gmail.com> On Jul 22, 2013, at 4:25 PM, Erik Bray wrote: > On 07/19/2013 02:21 PM, Demitri Muna wrote: >> Hello, >> >> See introduction in the email "The trouble with FITS". The Google document I created for this is here: >> >> http://bit.ly/1dKcKih >> >> Cheers, >> Demitri > > I think that the last bullet point could use clarification. The way I might > word this is that it should be possible to order table data in row-order or > column-order depending on how it is most likely to be accessed. This is of > course a determination that would have to be made by the user, and sometimes > there is no right answer (but where there is a right answer it should be > possible to do). > For reference, the last bullet point is: ? FITS tables and compressed image are stored inefficiently. To read a column of data (e.g. for plotting purposes) requires a pointer jumping from byte to byte once per entry. Columns need to be stored in a cohesive chunk. [4] In case you hadn't seen this ? there is "column-oriented FITS" to address this issue: http://www.star.bris.ac.uk/~mbt/topcat/sun253/outColfits.html I haven't done any benchmarking if this hack results in fast column-oriented I/O for tools other than STILS / TOPCAT, though. Christoph From stsci.perry at gmail.com Wed Jul 24 10:21:09 2013 From: stsci.perry at gmail.com (Perry Greenfield) Date: Wed, 24 Jul 2013 10:21:09 -0400 Subject: [AstroPy] positions available at STScI References: Message-ID: <8419AB01-4ACA-439B-9BE3-C627BDC9242B@gmail.com> The Science Software Branch at STScI has two positions open. The first is for someone with astronomical data analysis experience coupled with significant software experience. The second position is targeted towards someone with a stronger software background (data analysis experience not required), and has experience with system internals (e.g., Python internals, numpy internals, or OS internals; things like that). If you know anyone that is good at that sort of thing and is interested in working with scientific software, let them know about this posting) To apply for either position, follow the link for that position and the corresponding link to apply online for the position Thanks, Perry Posting #1 https://rn11.ultipro.com/SPA1004/JobBoard/JobDetails.aspx?__ID=*42731B2053947E61 Posting #2 https://rn11.ultipro.com/SPA1004/JobBoard/JobDetails.aspx?__ID=*D52483D191F03B02 From thomas.robitaille at gmail.com Thu Jul 25 05:44:07 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 25 Jul 2013 11:44:07 +0200 Subject: [AstroPy] The Astropy paper and Acknowledging the use of Astropy Message-ID: Dear colleagues, I am very happy to announce that the first paper written by the Astropy Collaboration to describe the Astropy package has been accepted for publication in A&A, and is available on the arXiv today: http://arxiv.org/abs/1307.6212 The Astropy project is a community effort to develop a single core package for Astronomy in Python and foster interoperability between Python astronomy packages (see http://www.astropy.org for more details). We would be very grateful if authors of papers/publications making use of Astropy (whether directly or as a dependency to other packages) could include the following acknowledgment: "This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration, 2013)." where (Astropy Collaboration, 2013) is a citation to the Astropy paper mentioned above. You can find the required BibTeX code via ADS at: http://adsabs.harvard.edu/abs/2013arXiv1307.6212T If you wish, you can also include a link to http://www.astropy.org (if the journal allows this) in addition to the above text. The most up-to-date recommendations for acknowledging the use of Astropy can be found at the bottom of the http://www.astropy.org home page. Please help us by forwarding this to your local Python user groups or any other relevant groups! Thank you for your help, Thomas Robitaille on behalf of the Astropy Collaboration From thomas.robitaille at gmail.com Fri Jul 26 08:13:10 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Fri, 26 Jul 2013 14:13:10 +0200 Subject: [AstroPy] ANN: Astropy 0.2.4 Released Message-ID: Dear colleagues, We are happy to announce the release of Astropy v0.2.4, a core Python package for Astronomy. This is mainly a bugfix release that improves stability and performance. A full list of changes is given here: http://docs.astropy.org/en/stable/changelog.html In addition to bug fixes, this release includes the addition of the cosmological parameters for the Planck 2013 results: >>> from astropy.cosmology import Planck13 Tar files and installers for the release are available from here: https://pypi.python.org/pypi/astropy Astropy can be installed with pip: pip install astropy but is also available in MacPorts and Fink. If you are using the Anaconda Python Distribution (which includes Astropy by default), you can already update to 0.2.4 with: conda update astropy Please let us know if you run into any issues with this release! Thomas Robitaille, Erik Tollerud, and Perry Greenfield on behalf of the Astropy Collaboration From mlj.ovelar at gmail.com Tue Jul 30 08:19:32 2013 From: mlj.ovelar at gmail.com (Maria de Juan Ovelar) Date: Tue, 30 Jul 2013 14:19:32 +0200 Subject: [AstroPy] Centering saturated images Message-ID: <8EAC93C4-52E0-483B-8574-6E361E82718F@gmail.com> Dear AstroPy-ers, I am a PhD student working on imaging polarimetry. Sorry if this is a too basic question for the mailing list but I would like to know what is, in your opinion, the best way to center images that have the central ~20 pixels saturated and if there are tools in python that can help wit this specific task. Me and another student were playing a bit with fitting a moffat profile (with saturated pixels masked) but it seems that it is not accurate enough. Any ideas? would a cross-correlation work better? and do the cross-correlation work with saturated pixels masked? Thank you very much! Maria From ianc at mpia-hd.mpg.de Tue Jul 30 08:54:56 2013 From: ianc at mpia-hd.mpg.de (Ian Crossfield) Date: Tue, 30 Jul 2013 14:54:56 +0200 Subject: [AstroPy] Centering saturated images In-Reply-To: <8EAC93C4-52E0-483B-8574-6E361E82718F@gmail.com> References: <8EAC93C4-52E0-483B-8574-6E361E82718F@gmail.com> Message-ID: <51F7B7A0.9090003@mpia-hd.mpg.de> Maria, A few ideas: --One possibility might be to use a "least-asymmetry" centering approach after masking out the saturated pixels (described, at least briefly, in http://arxiv.org/abs/1010.4591). --If your sources are bright enough to show diffraction spikes, these should go through the PSF center and you may be able to calculate a centroid from this. Good luck, -Ian Crossfield On 7/30/13 2:19 PM, Maria de Juan Ovelar wrote: > Dear AstroPy-ers, > > I am a PhD student working on imaging polarimetry. > Sorry if this is a too basic question for the mailing list but I would like to know what is, in your opinion, the best way to center images that have the central ~20 pixels saturated and if there are tools in python that can help wit this specific task. > Me and another student were playing a bit with fitting a moffat profile (with saturated pixels masked) but it seems that it is not accurate enough. > Any ideas? would a cross-correlation work better? and do the cross-correlation work with saturated pixels masked? > > Thank you very much! > Maria > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Ian Crossfield http://www.mpia-hd.mpg.de/homes/ianc/ Max-Planck-Institut f?r Astronomie +49-(0)6221 528-405 Room 308/4 From rowen at uw.edu Tue Jul 30 10:30:34 2013 From: rowen at uw.edu (Russell Owen) Date: Tue, 30 Jul 2013 07:30:34 -0700 Subject: [AstroPy] Centering saturated images In-Reply-To: <51F7B7A0.9090003@mpia-hd.mpg.de> References: <8EAC93C4-52E0-483B-8574-6E361E82718F@gmail.com> <51F7B7A0.9090003@mpia-hd.mpg.de> Message-ID: An implementation of centroiding by finding the point of maximum symmetry is available here: . Be sure to mask out saturated pixels. -- Russell On Jul 30, 2013, at 5:54 AM, Ian Crossfield wrote: > Maria, > > A few ideas: > --One possibility might be to use a "least-asymmetry" centering approach > after masking out the saturated pixels (described, at least briefly, in > http://arxiv.org/abs/1010.4591). > --If your sources are bright enough to show diffraction spikes, these > should go through the PSF center and you may be able to calculate a > centroid from this. > > Good luck, > -Ian Crossfield > > > On 7/30/13 2:19 PM, Maria de Juan Ovelar wrote: >> Dear AstroPy-ers, >> >> I am a PhD student working on imaging polarimetry. >> Sorry if this is a too basic question for the mailing list but I would like to know what is, in your opinion, the best way to center images that have the central ~20 pixels saturated and if there are tools in python that can help wit this specific task. >> Me and another student were playing a bit with fitting a moffat profile (with saturated pixels masked) but it seems that it is not accurate enough. >> Any ideas? would a cross-correlation work better? and do the cross-correlation work with saturated pixels masked? >> >> Thank you very much! >> Maria >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > -- > Ian Crossfield > http://www.mpia-hd.mpg.de/homes/ianc/ > Max-Planck-Institut f?r Astronomie > +49-(0)6221 528-405 > Room 308/4 > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From thomas.robitaille at gmail.com Tue Jul 30 10:55:33 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 30 Jul 2013 16:55:33 +0200 Subject: [AstroPy] ANN: ATpy 0.9.7 release Message-ID: Hi everyone, This is to let you know that ATpy v0.9.7 is now available for download. https://pypi.python.org/pypi/ATpy ATpy is a high-level Python package providing a generic Table class that can contain data and meta-data, and includes column manipulation, row selection, and sorting methods. Most of the functionality from ATpy has now been incorporated into Astropy (http://www.astropy.org), and specifically astropy.table: http://docs.astropy.org/en/stable/table/index.html so this release of ATpy is only provided for backward-compatibility. If you have never used ATpy before, you can therefore ignore this message. The main change in this release is that ATpy now depends on Astropy instead of PyFITS, vo, and asciitable for reading and writing FITS, VO, and ASCII tables. The documentation is now hosted at: http://atpy.readthedocs.org/ In particular, we have written a guide for existing ATpy users who want to migrate to Astropy: http://atpy.readthedocs.org/en/0.9.7/migration.html Since the migration is not as simple as changing an import statement, we will continue to distribute ATpy for the foreseeable future as a legacy package, but for any new code, we encourage you to use astropy.table instead. This will be one of the last releases of ATpy, and we will not develop any new features from now on (but will fix bugs when possible). To update ATpy using pip: pip install atpy --upgrade Please do not hesitate to let us know if you encounter any problems with this release! Cheers, Tom and Eli From yannick.roehlly at oamp.fr Tue Jul 30 15:14:08 2013 From: yannick.roehlly at oamp.fr (Yannick Roehlly) Date: Tue, 30 Jul 2013 21:14:08 +0200 Subject: [AstroPy] ANN: ATpy 0.9.7 release In-Reply-To: References: Message-ID: <20130730211408.61f369d1@oamp.fr> Hi Thomas, I'm really happy to read that the ATpy functionalities are now in astropy. Being able to auto-magically load a table without bothering of its format is a wonderful feature. But I think I can load a FITS table with t = Table.read('test.fits') only with the git astropy version, not the 0.2.4 version. Is this expected? Thanks (to all astropy contributors). Yannick PS: Do some of you go to ADASS this year? -- Research is to see what everybody else has seen, and think what nobody else has thought. From thomas.robitaille at gmail.com Tue Jul 30 17:03:10 2013 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 30 Jul 2013 23:03:10 +0200 Subject: [AstroPy] ANN: ATpy 0.9.7 release In-Reply-To: <20130730211408.61f369d1@oamp.fr> References: <20130730211408.61f369d1@oamp.fr> Message-ID: Hi Yannick, Reading from FITS tables is indeed only supported in the developer version of Astropy for now, and will be supported from 0.3 onwards. Please let us know if you run into any issues using the Astropy Table class instead of ATpy. Cheers, Tom On 30 July 2013 21:14, Yannick Roehlly wrote: > Hi Thomas, > > I'm really happy to read that the ATpy functionalities are now in > astropy. Being able to auto-magically load a table without bothering > of its format is a wonderful feature. > > But I think I can load a FITS table with > > t = Table.read('test.fits') > > only with the git astropy version, not the 0.2.4 version. Is this > expected? > > Thanks (to all astropy contributors). > > Yannick > > PS: Do some of you go to ADASS this year? > > -- > Research is to see what everybody else has seen, and think what nobody > else has thought. > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy