From yg1991 at mail.ustc.edu.cn Tue Jul 1 09:12:36 2014 From: yg1991 at mail.ustc.edu.cn (Guang Yang) Date: Tue, 1 Jul 2014 21:12:36 +0800 (CST) Subject: [AstroPy] Some Feedbacks about Astropy Message-ID: <863181.3954441404220356854.JavaMail.coremail@mailweb> Dear Astropy developers & users, I'm a university student working on astronomy. Recently, I'm switching to python from IDL. Astropy is indeed an awesome tool set. But it lacks some often-used tool for astronomers compared to NASA's Library for IDL: 1. I find no tools to align two images, i.e. to uniform their astrometry, pixel scale, image size and etc. hastrom.pro (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is a good example to perform such a task. 2. Though there's astropy.coordinates.matching.match_coordinates_sky to cross-correlate two catalogs, it doesn't allow user to specify matching radius and matching mode (e.g., one-one match). I've made a function to do so, and hope similar function can be included in astropy (https://github.com/Guang91/Astronomers_Tool_Box/blob/master/my_srcor.py). Thank you, Guang Yang From adam.g.ginsburg at gmail.com Tue Jul 1 10:06:43 2014 From: adam.g.ginsburg at gmail.com (Adam Ginsburg) Date: Tue, 1 Jul 2014 16:06:43 +0200 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: <863181.3954441404220356854.JavaMail.coremail@mailweb> References: <863181.3954441404220356854.JavaMail.coremail@mailweb> Message-ID: > 1. I find no tools to align two images, i.e. to uniform their astrometry, pixel scale, image size and etc. hastrom.pro (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is a good example to perform such a task. I've written a tool to do that: https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py ...I think it does what hastrom does, not hcongrid, which means I should change the name. Otherwise, you can use the montage wrapper: http://www.astropy.org/montage-wrapper/ -- Adam Ginsburg Fellow, European Southern Observatory http://www.adamgginsburg.com/ From adam.g.ginsburg at gmail.com Tue Jul 1 10:07:58 2014 From: adam.g.ginsburg at gmail.com (Adam Ginsburg) Date: Tue, 1 Jul 2014 16:07:58 +0200 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: References: <863181.3954441404220356854.JavaMail.coremail@mailweb> Message-ID: On Tue, Jul 1, 2014 at 4:06 PM, Adam Ginsburg wrote: >> 1. I find no tools to align two images, i.e. to uniform their astrometry, pixel scale, image size and etc. hastrom.pro (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is a good example to perform such a task. > > I've written a tool to do that: > https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py > ...I think it does what hastrom does, not hcongrid, which means I > should change the name. > > Otherwise, you can use the montage wrapper: > http://www.astropy.org/montage-wrapper/ P.S. pyast can do it too, and the corresponding wrapper is here: https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py#L222 -- Adam Ginsburg Fellow, European Southern Observatory http://www.adamgginsburg.com/ From rays at blue-cove.com Tue Jul 1 11:13:25 2014 From: rays at blue-cove.com (RayS) Date: Tue, 01 Jul 2014 08:13:25 -0700 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: References: <863181.3954441404220356854.JavaMail.coremail@mailweb> Message-ID: <201407011513.s61FDSMa025387@blue-cove.com> At 07:07 AM 7/1/2014, you wrote: >On Tue, Jul 1, 2014 at 4:06 PM, Adam Ginsburg > wrote: > >> 1. I find no tools to align two images, i.e. to uniform their > astrometry, pixel scale, image size and etc. BTW, for those interested, I ported H. Xie's IDL registration paper to Python http://rjs.org/astro/1004x/Python/register/shift_idl.py # Hongjie Xie, Nigel Hicks, G. Randy Keller, Haitao Huang, Vladik Kreinovich # # Title of the paper: # An IDL/ENVI implementation of the FFT Based Algorithm for(Automatic Image Registration http://rjs.org/astro/1004x/Python/register/ as an exercise a while back. - Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.quinn at ucd.ie Tue Jul 1 11:18:10 2014 From: john.quinn at ucd.ie (John Quinn) Date: Tue, 1 Jul 2014 16:18:10 +0100 Subject: [AstroPy] Bug in units decompose()? Message-ID: <0E94D9EB-A58A-48C2-8AC2-0E350D511E7F@ucd.ie> Hello, I am currently evaluating iPython Notebook as a replacement for MATHCAD in our teaching laboratories and am particularly interested in using the units and constants packages of astropy. I have encountered an apparent bug using the units decompose function and have reduced it to the following example: > from astropy import units as u > u.J.decompose(bases=[u.J]) which produces the errors given below. Similarly, I cannot decompose a unit consisting of 1 u.N * u.m into u.J, but strangely u.Ry.decompose(bases=[u.J]) works fine. Am I missing something obvious or is this a bug? I am using astropy 0.3.2 with python 3.4.1 on Mac OS X (anaconda). I see the same on the Linux and Windows versions and with Python 2.7.7. Thanks, John --------------------------------------------------------------------------- UnitsError Traceback (most recent call last) in () ----> 1 u.J.decompose(bases=[u.J]) /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in decompose(self, bases) 1837 1838 def decompose(self, bases=set()): -> 1839 return self._represents.decompose(bases=bases) 1840 decompose.__doc__ = UnitBase.decompose.__doc__ 1841 /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in decompose(self, bases) 1999 2000 x = CompositeUnit(self.scale, self.bases, self.powers, decompose=True, -> 2001 decompose_bases=bases) 2002 if len(bases) == 0: 2003 self._decomposed_cache = x /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in __init__(self, scale, bases, powers, decompose, decompose_bases, _error_check) 1897 self._powers = powers 1898 self._decomposed_cache = None -> 1899 self._expand_and_gather(decompose=decompose, bases=decompose_bases) 1900 1901 def __repr__(self): /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in _expand_and_gather(self, decompose, bases) 1959 for b, p in zip(self.bases, self.powers): 1960 if decompose and b not in bases: -> 1961 b = b.decompose(bases=bases) 1962 1963 if isinstance(b, CompositeUnit): /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in decompose(self, bases) 1837 1838 def decompose(self, bases=set()): -> 1839 return self._represents.decompose(bases=bases) 1840 decompose.__doc__ = UnitBase.decompose.__doc__ 1841 /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in decompose(self, bases) 1999 2000 x = CompositeUnit(self.scale, self.bases, self.powers, decompose=True, -> 2001 decompose_bases=bases) 2002 if len(bases) == 0: 2003 self._decomposed_cache = x /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in __init__(self, scale, bases, powers, decompose, decompose_bases, _error_check) 1897 self._powers = powers 1898 self._decomposed_cache = None -> 1899 self._expand_and_gather(decompose=decompose, bases=decompose_bases) 1900 1901 def __repr__(self): /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in _expand_and_gather(self, decompose, bases) 1959 for b, p in zip(self.bases, self.powers): 1960 if decompose and b not in bases: -> 1961 b = b.decompose(bases=bases) 1962 1963 if isinstance(b, CompositeUnit): /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in decompose(self, bases) 1573 raise UnitsError( 1574 "Unit {0} can not be decomposed into the requested " -> 1575 "bases".format(self)) 1576 1577 return self UnitsError: Unit kg can not be decomposed into the requested bases -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefano.covino at brera.inaf.it Tue Jul 1 11:48:23 2014 From: stefano.covino at brera.inaf.it (Stefano Covino) Date: Tue, 1 Jul 2014 17:48:23 +0200 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: <863181.3954441404220356854.JavaMail.coremail@mailweb> References: <863181.3954441404220356854.JavaMail.coremail@mailweb> Message-ID: <4720BBF0-5833-4CB1-99F7-F685F5F65743@brera.inaf.it> I also did something similar to what you are looking for: https://pypi.python.org/pypi/SRPAstro.FITS/1.0.0 Bye, Stefano __________________ Mobilis in mobile > Il giorno 01/lug/2014, alle ore 15:12, "Guang Yang" ha scritto: > > Dear Astropy developers & users, > > I'm a university student working on astronomy. Recently, I'm switching to python from IDL. Astropy is indeed an awesome tool set. But it lacks some often-used tool for astronomers compared to NASA's Library for IDL: > > 1. I find no tools to align two images, i.e. to uniform their astrometry, pixel scale, image size and etc. hastrom.pro (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is a good example to perform such a task. > > 2. Though there's astropy.coordinates.matching.match_coordinates_sky to cross-correlate two catalogs, it doesn't allow user to specify matching radius and matching mode (e.g., one-one match). I've made a function to do so, and hope similar function can be included in astropy (https://github.com/Guang91/Astronomers_Tool_Box/blob/master/my_srcor.py). > > Thank you, > Guang Yang > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From mdroe at stsci.edu Tue Jul 1 12:23:27 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 1 Jul 2014 12:23:27 -0400 Subject: [AstroPy] Bug in units decompose()? In-Reply-To: <0E94D9EB-A58A-48C2-8AC2-0E350D511E7F@ucd.ie> References: <0E94D9EB-A58A-48C2-8AC2-0E350D511E7F@ucd.ie> Message-ID: <53B2E07F.2080305@stsci.edu> The bases passed to |decompose| must be strictly bases of the given unit --- it is not capable of recombining units. If you want to compose units into groupings of other units, use |compose|. Mike On 07/01/2014 11:18 AM, John Quinn wrote: > Hello, > > I am currently evaluating iPython Notebook as a replacement for > MATHCAD in our teaching laboratories > and am particularly interested in using the units and constants > packages of astropy. > > I have encountered an apparent bug using the units decompose function > and have reduced it to the > following example: > > > from astropy import units as u > > u.J.decompose(bases=[u.J]) > > which produces the errors given below. > > Similarly, I cannot decompose a unit consisting of 1 u.N * > u.m into u.J, but strangely u.Ry.decompose(bases=[u.J]) works fine. > > Am I missing something obvious or is this a bug? > > I am using astropy 0.3.2 with python 3.4.1 on Mac OS X (anaconda). I > see the same on the Linux and Windows > versions and with Python 2.7.7. > > Thanks, > > John > > --------------------------------------------------------------------------- > UnitsError Traceback (most recent call last) > in() > ----> 1 u.J.decompose(bases=[u.J]) > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) > 1837 > 1838 def decompose(self, bases=set()): > -> 1839 return self._represents.decompose(bases=bases) > 1840 decompose.__doc__= UnitBase.decompose.__doc__ > 1841 > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) > 1999 > 2000 x = CompositeUnit(self.scale, self.bases, self.powers, decompose=True, > -> 2001 decompose_bases=bases) > 2002 if len(bases) == 0: > 2003 self._decomposed_cache= x > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in__init__(self, scale, bases, powers, decompose, decompose_bases, _error_check) > 1897 self._powers= powers > 1898 self._decomposed_cache= None > -> 1899 self._expand_and_gather(decompose=decompose, bases=decompose_bases) > 1900 > 1901 def __repr__(self): > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in_expand_and_gather(self, decompose, bases) > 1959 for b, pin zip(self.bases, self.powers): > 1960 if decomposeand bnot in bases: > -> 1961 b = b.decompose(bases=bases) > 1962 > 1963 if isinstance(b, CompositeUnit): > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) > 1837 > 1838 def decompose(self, bases=set()): > -> 1839 return self._represents.decompose(bases=bases) > 1840 decompose.__doc__= UnitBase.decompose.__doc__ > 1841 > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) > 1999 > 2000 x = CompositeUnit(self.scale, self.bases, self.powers, decompose=True, > -> 2001 decompose_bases=bases) > 2002 if len(bases) == 0: > 2003 self._decomposed_cache= x > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in__init__(self, scale, bases, powers, decompose, decompose_bases, _error_check) > 1897 self._powers= powers > 1898 self._decomposed_cache= None > -> 1899 self._expand_and_gather(decompose=decompose, bases=decompose_bases) > 1900 > 1901 def __repr__(self): > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in_expand_and_gather(self, decompose, bases) > 1959 for b, pin zip(self.bases, self.powers): > 1960 if decomposeand bnot in bases: > -> 1961 b = b.decompose(bases=bases) > 1962 > 1963 if isinstance(b, CompositeUnit): > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) > 1573 raise UnitsError( > 1574 "Unit {0} can not be decomposed into the requested" > -> 1575 "bases".format(self)) > 1576 > 1577 return self > > UnitsError: Unit kg can not be decomposed into the requested bases > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From embray at stsci.edu Tue Jul 1 13:43:32 2014 From: embray at stsci.edu (Erik Bray) Date: Tue, 1 Jul 2014 13:43:32 -0400 Subject: [AstroPy] Bug in units decompose()? In-Reply-To: <0E94D9EB-A58A-48C2-8AC2-0E350D511E7F@ucd.ie> References: <0E94D9EB-A58A-48C2-8AC2-0E350D511E7F@ucd.ie> Message-ID: <53B2F344.2000001@stsci.edu> If I understand correctly this is because u.J is already defined in terms of kilograms, meters, and seconds (actually Newtons and meters). You could redefine J as a new unit, and then redefine those other units relative to the new J. But I'm not entirely clear exactly what the intent is here. I do agree the error is a little confusing. But not as much if you know that Joule is already a compound unit, and it's trying to recursively decompose the units that comprise it in terms of Joules, hence the confusion. Erik On 07/01/2014 11:18 AM, John Quinn wrote: > Hello, > > I am currently evaluating iPython Notebook as a replacement for MATHCAD in our > teaching laboratories > and am particularly interested in using the units and constants packages of > astropy. > > I have encountered an apparent bug using the units decompose function and have > reduced it to the > following example: > > > from astropy import units as u > > u.J.decompose(bases=[u.J]) > > which produces the errors given below. > > Similarly, I cannot decompose a unit consisting of 1 u.N * u.m into u.J, but > strangely u.Ry.decompose(bases=[u.J]) works fine. > > Am I missing something obvious or is this a bug? > > I am using astropy 0.3.2 with python 3.4.1 on Mac OS X (anaconda). I see the > same on the Linux and Windows > versions and with Python 2.7.7. > > Thanks, > > John > > --------------------------------------------------------------------------- > UnitsError Traceback (most recent call last) > in() > ----> 1 u.J.decompose(bases=[u.J]) > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) > 1837 > 1838 def decompose(self, bases=set()): > -> 1839 return self._represents.decompose(bases=bases) > 1840 decompose.__doc__= UnitBase.decompose.__doc__ > 1841 > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) > 1999 > 2000 x = CompositeUnit(self.scale, self.bases, self.powers, decompose=True, > -> 2001 decompose_bases=bases) > 2002 if len(bases) == 0: > 2003 self._decomposed_cache= x > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in__init__(self, scale, bases, powers, decompose, decompose_bases, _error_check) > 1897 self._powers= powers > 1898 self._decomposed_cache= None > -> 1899 self._expand_and_gather(decompose=decompose, bases=decompose_bases) > 1900 > 1901 def __repr__(self): > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in_expand_and_gather(self, decompose, bases) > 1959 for b, pin zip(self.bases, self.powers): > 1960 if decomposeand bnot in bases: > -> 1961 b = b.decompose(bases=bases) > 1962 > 1963 if isinstance(b, CompositeUnit): > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) > 1837 > 1838 def decompose(self, bases=set()): > -> 1839 return self._represents.decompose(bases=bases) > 1840 decompose.__doc__= UnitBase.decompose.__doc__ > 1841 > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) > 1999 > 2000 x = CompositeUnit(self.scale, self.bases, self.powers, decompose=True, > -> 2001 decompose_bases=bases) > 2002 if len(bases) == 0: > 2003 self._decomposed_cache= x > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in__init__(self, scale, bases, powers, decompose, decompose_bases, _error_check) > 1897 self._powers= powers > 1898 self._decomposed_cache= None > -> 1899 self._expand_and_gather(decompose=decompose, bases=decompose_bases) > 1900 > 1901 def __repr__(self): > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in_expand_and_gather(self, decompose, bases) > 1959 for b, pin zip(self.bases, self.powers): > 1960 if decomposeand bnot in bases: > -> 1961 b = b.decompose(bases=bases) > 1962 > 1963 if isinstance(b, CompositeUnit): > > /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) > 1573 raise UnitsError( > 1574 "Unit {0} can not be decomposed into the requested" > -> 1575 "bases".format(self)) > 1576 > 1577 return self > > UnitsError: Unit kg can not be decomposed into the requested bases > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From john.quinn at ucd.ie Tue Jul 1 16:14:16 2014 From: john.quinn at ucd.ie (John Quinn) Date: Tue, 1 Jul 2014 21:14:16 +0100 Subject: [AstroPy] Bug in units decompose()? In-Reply-To: <53B2F344.2000001@stsci.edu> References: <0E94D9EB-A58A-48C2-8AC2-0E350D511E7F@ucd.ie> <53B2F344.2000001@stsci.edu> Message-ID: <6CDB4DF6-9B57-403B-A9D8-0348EF632ADA@ucd.ie> Thanks for the responses. I think I can use to() to convert to other units and that will do what I want. I was confused after reading the documentation at: http://docs.astropy.org/en/stable/units/decomposing_and_composing.html#reducing-a-unit-to-its-irreducible-parts and found that: > u.J.compose() [Unit("J"), Unit("1e+07 erg"), Unit("4.58743e+17 Ry"), Unit("6.24151e+18 eV")] > u.Ry.decompose(bases=[u.m, u.N]) 2.17987e-18 m N > u.eV.decompose(bases=[u.m, u.N]) 1.60218e-19 m N but: > u.erg.decompose(bases=[u.m, u.N]) gives an error. Similarly, converting to J sometimes works and sometimes doesn't, and I was very surprised that decomposing something in J to J gave an error. Regards, John On 1 Jul 2014, at 18:43, Erik Bray wrote: > If I understand correctly this is because u.J is already defined in terms of > kilograms, meters, and seconds (actually Newtons and meters). You could > redefine J as a new unit, and then redefine those other units relative to the new J. > > But I'm not entirely clear exactly what the intent is here. I do agree the > error is a little confusing. But not as much if you know that Joule is already a > compound unit, and it's trying to recursively decompose the units that comprise > it in terms of Joules, hence the confusion. > > Erik > > On 07/01/2014 11:18 AM, John Quinn wrote: >> Hello, >> >> I am currently evaluating iPython Notebook as a replacement for MATHCAD in our >> teaching laboratories >> and am particularly interested in using the units and constants packages of >> astropy. >> >> I have encountered an apparent bug using the units decompose function and have >> reduced it to the >> following example: >> >>> from astropy import units as u >>> u.J.decompose(bases=[u.J]) >> >> which produces the errors given below. >> >> Similarly, I cannot decompose a unit consisting of 1 u.N * u.m into u.J, but >> strangely u.Ry.decompose(bases=[u.J]) works fine. >> >> Am I missing something obvious or is this a bug? >> >> I am using astropy 0.3.2 with python 3.4.1 on Mac OS X (anaconda). I see the >> same on the Linux and Windows >> versions and with Python 2.7.7. >> >> Thanks, >> >> John >> >> --------------------------------------------------------------------------- >> UnitsError Traceback (most recent call last) >> in() >> ----> 1 u.J.decompose(bases=[u.J]) >> >> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) >> 1837 >> 1838 def decompose(self, bases=set()): >> -> 1839 return self._represents.decompose(bases=bases) >> 1840 decompose.__doc__= UnitBase.decompose.__doc__ >> 1841 >> >> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) >> 1999 >> 2000 x = CompositeUnit(self.scale, self.bases, self.powers, decompose=True, >> -> 2001 decompose_bases=bases) >> 2002 if len(bases) == 0: >> 2003 self._decomposed_cache= x >> >> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in__init__(self, scale, bases, powers, decompose, decompose_bases, _error_check) >> 1897 self._powers= powers >> 1898 self._decomposed_cache= None >> -> 1899 self._expand_and_gather(decompose=decompose, bases=decompose_bases) >> 1900 >> 1901 def __repr__(self): >> >> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in_expand_and_gather(self, decompose, bases) >> 1959 for b, pin zip(self.bases, self.powers): >> 1960 if decomposeand bnot in bases: >> -> 1961 b = b.decompose(bases=bases) >> 1962 >> 1963 if isinstance(b, CompositeUnit): >> >> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) >> 1837 >> 1838 def decompose(self, bases=set()): >> -> 1839 return self._represents.decompose(bases=bases) >> 1840 decompose.__doc__= UnitBase.decompose.__doc__ >> 1841 >> >> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) >> 1999 >> 2000 x = CompositeUnit(self.scale, self.bases, self.powers, decompose=True, >> -> 2001 decompose_bases=bases) >> 2002 if len(bases) == 0: >> 2003 self._decomposed_cache= x >> >> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in__init__(self, scale, bases, powers, decompose, decompose_bases, _error_check) >> 1897 self._powers= powers >> 1898 self._decomposed_cache= None >> -> 1899 self._expand_and_gather(decompose=decompose, bases=decompose_bases) >> 1900 >> 1901 def __repr__(self): >> >> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in_expand_and_gather(self, decompose, bases) >> 1959 for b, pin zip(self.bases, self.powers): >> 1960 if decomposeand bnot in bases: >> -> 1961 b = b.decompose(bases=bases) >> 1962 >> 1963 if isinstance(b, CompositeUnit): >> >> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) >> 1573 raise UnitsError( >> 1574 "Unit {0} can not be decomposed into the requested" >> -> 1575 "bases".format(self)) >> 1576 >> 1577 return self >> >> UnitsError: Unit kg can not be decomposed into the requested bases >> >> >> >> >> _______________________________________________ >> 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 Dr. John Quinn School of Physics Science Center North University College Dublin Belfield, Dublin 4 Ireland T: +353-1-7162278 F: +353-1-2837275 john.quinn at ucd.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From crawford at saao.ac.za Tue Jul 1 16:23:24 2014 From: crawford at saao.ac.za (Steve Crawford) Date: Tue, 1 Jul 2014 22:23:24 +0200 (SAST) Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: <201407011513.s61FDSMa025387@blue-cove.com> References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <201407011513.s61FDSMa025387@blue-cove.com> Message-ID: <461068731.760693.1404246204357.JavaMail.zimbra@saao.ac.za> We are hoping to eventually add this type of functionality to the ccdproc affiliated package. This is still a work in progress, but if you have already done something please feel free to initiate a pull request or add an issue to the tracker. It would be great to have some more contributions to the package so please feel free to contribute! Link for ccdproc: https://github.com/astropy/ccdproc ----- Original Message ----- From: "RayS" To: "Astronomical Python mailing list" Sent: Tuesday, July 1, 2014 11:13:25 AM Subject: Re: [AstroPy] Some Feedbacks about Astropy At 07:07 AM 7/1/2014, you wrote: On Tue, Jul 1, 2014 at 4:06 PM, Adam Ginsburg wrote: >> 1. I find no tools to align two images, i.e. to uniform their astrometry, pixel scale, image size and etc. BTW, for those interested, I ported H. Xie's IDL registration paper to Python http://rjs.org/astro/1004x/Python/register/shift_idl.py # Hongjie Xie,? Nigel Hicks,? G. Randy Keller, Haitao Huang, Vladik Kreinovich # #? Title of the paper: #? An IDL/ENVI implementation of the FFT Based Algorithm for(Automatic Image Registration http://rjs.org/astro/1004x/Python/register/ as an exercise a while back. - Ray !DSPAM:53b2d03313229128195232! _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy !DSPAM:53b2d03313229128195232! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rays at blue-cove.com Tue Jul 1 16:37:55 2014 From: rays at blue-cove.com (RayS) Date: Tue, 01 Jul 2014 13:37:55 -0700 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: <461068731.760693.1404246204357.JavaMail.zimbra@saao.ac.za> References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <201407011513.s61FDSMa025387@blue-cove.com> <461068731.760693.1404246204357.JavaMail.zimbra@saao.ac.za> Message-ID: <201407012037.s61KbwBP029928@blue-cove.com> My concern is that Xie's method has some rotation/translation constraints. As a pure-Python tool it might be interesting vs. one of the large packages like IRAF. But doesn't montage_wrapper.wrappers.mosaic(background_match=True) do registration? - Ray At 01:23 PM 7/1/2014, you wrote: >We are hoping to eventually add this type of functionality to the >ccdproc affiliated package. This is still a work in progress, but >if you have already done something please feel free to initiate a >pull request or add an issue to the tracker. It would be great to >have some more contributions to the package so please feel free to contribute! > >Link for ccdproc: >https://github.com/astropy/ccdproc > > > > >---------- >From: "RayS" >To: "Astronomical Python mailing list" >Sent: Tuesday, July 1, 2014 11:13:25 AM >Subject: Re: [AstroPy] Some Feedbacks about Astropy > >At 07:07 AM 7/1/2014, you wrote: >On Tue, Jul 1, 2014 at 4:06 PM, Adam Ginsburg > wrote: > >> 1. I find no tools to align two images, i.e. to uniform their > astrometry, pixel scale, image size and etc. > > >BTW, for those interested, I ported H. Xie's IDL registration paper to Python >http://rjs.org/astro/1004x/Python/register/shift_idl.py > > ># Hongjie Xie, Nigel Hicks, G. Randy Keller, Haitao >Huang, Vladik Kreinovich ># ># Title of the paper: ># An IDL/ENVI implementation of the FFT Based Algorithm >for(Automatic Image Registration > >http://rjs.org/astro/1004x/Python/register/ >as an exercise a while back. > >- Ray !DSPAM:53b2d03313229128195232! >_______________________________________________ >AstroPy mailing list >AstroPy at scipy.org >http://mail.scipy.org/mailman/listinfo/astropy > > >!DSPAM:53b2d03313229128195232! > >_______________________________________________ >AstroPy mailing list >AstroPy at scipy.org >http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Tue Jul 1 16:41:01 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 1 Jul 2014 16:41:01 -0400 Subject: [AstroPy] Bug in units decompose()? In-Reply-To: <6CDB4DF6-9B57-403B-A9D8-0348EF632ADA@ucd.ie> References: <0E94D9EB-A58A-48C2-8AC2-0E350D511E7F@ucd.ie> <53B2F344.2000001@stsci.edu> <6CDB4DF6-9B57-403B-A9D8-0348EF632ADA@ucd.ie> Message-ID: <53B31CDD.7080709@stsci.edu> On 07/01/2014 04:14 PM, John Quinn wrote: > Thanks for the responses. > > I think I can use to() to convert to other units and that will do > what I want. If you just want to convert a value to another unit, |to| is what you want. |decompose| and |compose| are really more about introspecting the structure of units and finding alternate representations. > > I was confused after reading the documentation at: > http://docs.astropy.org/en/stable/units/decomposing_and_composing.html#reducing-a-unit-to-its-irreducible-parts > and found that: > > u.J.compose() > [Unit("J"), Unit("1e+07 erg"), Unit("4.58743e+17 Ry"), > Unit("6.24151e+18 eV")] > > > u.Ry.decompose(bases=[u.m, u.N]) > 2.17987e-18 m N > > > u.eV.decompose(bases=[u.m, u.N]) > 1.60218e-19 m N > > but: > > > u.erg.decompose(bases=[u.m, u.N]) > gives an error. erg is not defined in terms of N since it comes from the cgs system. It is |cm2 g / s2|. If you want to recompose that back into N, you should use |compose|: |u.erg.compose(units=[u.m, u.N]) [Unit("1e-07 m N")] | > > Similarly, converting to J sometimes works and sometimes doesn't, Can you elaborate on this? If something is nondeterministic I'd consider that a bug. > and I was very surprised that decomposing > something in J to J gave an error. We could probably special case this for decompose just to avoid confusion. I know this |decompose| vs. |compose| difference is confusing for others as well, and your suggestions about how to improve the docs and/or naming of things to make it more obvious are welcome. I think we still want to have both available, and I don't see an argument for changing the behavior (excepting the |X.decompose(bases=[X])| case). |decompose| is asking "how is this unit defined from its lower-level parts?", whereas |compose| is asking "given all of the units you know about, how can this unit be refactored into them?" So |decompose| is useful for introspecting the definition of a unit and |compose| is useful for searching for alternative representations. And it should be obvious that |compose| is a lot more computationally expensive. Neither are really necessary for pure unit conversion, where `to` is your friend. Mike > > Regards, > > John > > > > > > On 1 Jul 2014, at 18:43, Erik Bray > wrote: > >> If I understand correctly this is because u.J is already defined in >> terms of >> kilograms, meters, and seconds (actually Newtons and meters). You could >> redefine J as a new unit, and then redefine those other units >> relative to the new J. >> >> But I'm not entirely clear exactly what the intent is here. I do >> agree the >> error is a little confusing. But not as much if you know that Joule >> is already a >> compound unit, and it's trying to recursively decompose the units >> that comprise >> it in terms of Joules, hence the confusion. >> >> Erik >> >> On 07/01/2014 11:18 AM, John Quinn wrote: >>> Hello, >>> >>> I am currently evaluating iPython Notebook as a replacement for >>> MATHCAD in our >>> teaching laboratories >>> and am particularly interested in using the units and constants >>> packages of >>> astropy. >>> >>> I have encountered an apparent bug using the units decompose >>> function and have >>> reduced it to the >>> following example: >>> >>>> from astropy import units as u >>>> u.J.decompose(bases=[u.J]) >>> >>> which produces the errors given below. >>> >>> Similarly, I cannot decompose a unit consisting of 1 u.N * u.m into >>> u.J, but >>> strangely u.Ry.decompose(bases=[u.J]) works fine. >>> >>> Am I missing something obvious or is this a bug? >>> >>> I am using astropy 0.3.2 with python 3.4.1 on Mac OS X (anaconda). >>> I see the >>> same on the Linux and Windows >>> versions and with Python 2.7.7. >>> >>> Thanks, >>> >>> John >>> >>> --------------------------------------------------------------------------- >>> UnitsError Traceback (most recent >>> call last) >>> in() >>> ----> 1 u.J.decompose(bases=[u.J]) >>> >>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>> indecompose(self, bases) >>> 1837 >>> 1838 def decompose(self, bases=set()): >>> -> 1839 return self._represents.decompose(bases=bases) >>> 1840 decompose.__doc__= UnitBase.decompose.__doc__ >>> 1841 >>> >>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>> indecompose(self, bases) >>> 1999 >>> 2000 x = CompositeUnit(self.scale, self.bases, >>> self.powers, decompose=True, >>> -> 2001 decompose_bases=bases) >>> 2002 if len(bases) == 0: >>> 2003 self._decomposed_cache= x >>> >>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>> in__init__(self, scale, bases, powers, decompose, decompose_bases, >>> _error_check) >>> 1897 self._powers= powers >>> 1898 self._decomposed_cache= None >>> -> 1899 self._expand_and_gather(decompose=decompose, >>> bases=decompose_bases) >>> 1900 >>> 1901 def __repr__(self): >>> >>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>> in_expand_and_gather(self, decompose, bases) >>> 1959 for b, pin zip(self.bases, self.powers): >>> 1960 if decomposeand bnot in bases: >>> -> 1961 b = b.decompose(bases=bases) >>> 1962 >>> 1963 if isinstance(b, CompositeUnit): >>> >>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>> indecompose(self, bases) >>> 1837 >>> 1838 def decompose(self, bases=set()): >>> -> 1839 return self._represents.decompose(bases=bases) >>> 1840 decompose.__doc__= UnitBase.decompose.__doc__ >>> 1841 >>> >>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>> indecompose(self, bases) >>> 1999 >>> 2000 x = CompositeUnit(self.scale, self.bases, >>> self.powers, decompose=True, >>> -> 2001 decompose_bases=bases) >>> 2002 if len(bases) == 0: >>> 2003 self._decomposed_cache= x >>> >>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>> in__init__(self, scale, bases, powers, decompose, decompose_bases, >>> _error_check) >>> 1897 self._powers= powers >>> 1898 self._decomposed_cache= None >>> -> 1899 self._expand_and_gather(decompose=decompose, >>> bases=decompose_bases) >>> 1900 >>> 1901 def __repr__(self): >>> >>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>> in_expand_and_gather(self, decompose, bases) >>> 1959 for b, pin zip(self.bases, self.powers): >>> 1960 if decomposeand bnot in bases: >>> -> 1961 b = b.decompose(bases=bases) >>> 1962 >>> 1963 if isinstance(b, CompositeUnit): >>> >>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>> indecompose(self, bases) >>> 1573 raise UnitsError( >>> 1574 "Unit {0} can not be decomposed into the >>> requested" >>> -> 1575 "bases".format(self)) >>> 1576 >>> 1577 return self >>> >>> UnitsError: Unit kg can not be decomposed into the requested bases >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > Dr. John Quinn > School of Physics > Science Center North > University College Dublin > Belfield, Dublin 4 > Ireland > > T: +353-1-7162278 > F: +353-1-2837275 > john.quinn at ucd.ie > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From slianou at uwo.ca Tue Jul 1 17:14:53 2014 From: slianou at uwo.ca (Sofia Lianou) Date: Wed, 02 Jul 2014 00:14:53 +0300 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: <73e0f6841a6de.53b324c8@uwo.ca> References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <72d0dc641e0a4.53b3244d@uwo.ca> <72d0a66e1b7de.53b3248a@uwo.ca> <73e0f6841a6de.53b324c8@uwo.ca> Message-ID: <72d0b1e91db8a.53b34efd@uwo.ca> Hello, This is something that imagecube is doing, too, and the package is hosted here:http://sophiathl.github.io/imagecube/ Beta release to follow soon, along with proper documentation. Cheers, Sophia, Pauline, and Jeff On 07/01/14, Adam Ginsburg wrote: > > 1. I find no tools to align two images, i.e. to uniform their astrometry, pixel scale, image size and etc. hastrom.pro (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is a good example to perform such a task. > > I've written a tool to do that: > https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py > ...I think it does what hastrom does, not hcongrid, which means I > should change the name. > > Otherwise, you can use the montage wrapper: > http://www.astropy.org/montage-wrapper/ > > > -- > Adam Ginsburg > Fellow, European Southern Observatory > http://www.adamgginsburg.com/ > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yg1991 at mail.ustc.edu.cn Wed Jul 2 01:15:46 2014 From: yg1991 at mail.ustc.edu.cn (Guang Yang) Date: Wed, 2 Jul 2014 13:15:46 +0800 (CST) Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: <72d0b1e91db8a.53b34efd@uwo.ca> References: <72d0b1e91db8a.53b34efd@uwo.ca> <863181.3954441404220356854.JavaMail.coremail@mailweb> <72d0dc641e0a4.53b3244d@uwo.ca> <72d0a66e1b7de.53b3248a@uwo.ca> <73e0f6841a6de.53b324c8@uwo.ca> Message-ID: <25817621.3997271404278146242.JavaMail.coremail@mailweb> Thank all of you for giving those advices. I think I won't bother to switch between python and IDL in my next project. ^^ Best wishes, Guang -----Original email----- From: "Sofia Lianou" Sent Time: Jul 2, 2014 5:14:53 AM To: "Astronomical Python mailing list" , "Adam Ginsburg" Cc: "Pauline Barmby" Subject: Re: [AstroPy] Some Feedbacks about Astropy Hello, This is something that imagecube is doing, too, and the package is hosted here: http://sophiathl.github.io/imagecube/ Beta release to follow soon, along with proper documentation. Cheers, Sophia, Pauline, and Jeff On 07/01/14, Adam Ginsburg wrote: > 1. I find no tools to align two images, i.e. to uniform their astrometry, pixel scale, image size and etc. hastrom.pro (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is a good example to perform such a task. I've written a tool to do that: https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py ...I think it does what hastrom does, not hcongrid, which means I should change the name. Otherwise, you can use the montage wrapper: http://www.astropy.org/montage-wrapper/ -- Adam Ginsburg Fellow, European Southern Observatory http://www.adamgginsburg.com/ _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.quinn at ucd.ie Wed Jul 2 15:28:16 2014 From: john.quinn at ucd.ie (John Quinn) Date: Wed, 2 Jul 2014 20:28:16 +0100 Subject: [AstroPy] Bug in units decompose()? In-Reply-To: <53B31CDD.7080709@stsci.edu> References: <0E94D9EB-A58A-48C2-8AC2-0E350D511E7F@ucd.ie> <53B2F344.2000001@stsci.edu> <6CDB4DF6-9B57-403B-A9D8-0348EF632ADA@ucd.ie> <53B31CDD.7080709@stsci.edu> Message-ID: <2E6F56C4-F779-4232-92A2-DCEF3BD3B4D2@ucd.ie> On 1 Jul 2014, at 21:41, Michael Droettboom wrote: > On 07/01/2014 04:14 PM, John Quinn wrote: > >> Thanks for the responses. >> >> I think I can use to() to convert to other units and that will do what I want. > > If you just want to convert a value to another unit, to is what you want. decompose and compose are really more about introspecting the structure of units and finding alternate representations. > Thanks for clarifying. I think I had started to figure that out as I used the package more. For teaching purposes I will be clear on the different uses of to, compose and decompose. > >> >> I was confused after reading the documentation at: >> http://docs.astropy.org/en/stable/units/decomposing_and_composing.html#reducing-a-unit-to-its-irreducible-parts >> and found that: >> > u.J.compose() >> [Unit("J"), Unit("1e+07 erg"), Unit("4.58743e+17 Ry"), Unit("6.24151e+18 eV")] >> >> > u.Ry.decompose(bases=[u.m, u.N]) >> 2.17987e-18 m N >> >> > u.eV.decompose(bases=[u.m, u.N]) >> 1.60218e-19 m N >> >> but: >> >> > u.erg.decompose(bases=[u.m, u.N]) >> gives an error. > > erg is not defined in terms of N since it comes from the cgs system. It is cm2 g / s2. If you want to recompose that back into N, you should use compose: > > u.erg.compose(units=[u.m, u.N]) > [Unit("1e-07 m N")] OK, but the following is confusing to the uninitiated since u.erg decomposes into SI by default: In [4]: u.erg.decompose() Out[4]: Unit("1e-07 kg m2 / s2") In [5]: u.erg.decompose(bases=[u.kg, u.m, u.s]) Out[5]: Unit("1e-07 kg m2 / s2") In [6]: u.erg.decompose(bases=[u.N,u.m]) --------------------------------------------------------------------------- UnitsError Traceback (most recent call last) : : From your explanation I see why this is - there is a clear difference between decomposing and converting, and I was using decompose to convert. >> >> Similarly, converting to J sometimes works and sometimes doesn't, > > Can you elaborate on this? If something is nondeterministic I?d consider that a bug. > No, my mistake! It is always consistent. Sorry about that. > >> and I was very surprised that decomposing >> something in J to J gave an error. > > We could probably special case this for decompose just to avoid confusion. > > I know this decompose vs. compose difference is confusing for others as well, and your suggestions about how to improve the docs and/or naming of things to make it more obvious are welcome. I think we still want to have both available, and I don?t see an argument for changing the behavior (excepting the X.decompose(bases=[X]) case). decompose is asking ?how is this unit defined from its lower-level parts??, whereas compose is asking ?given all of the units you know about, how can this unit be refactored into them?? So decompose is useful for introspecting the definition of a unit and compose is useful for searching for alternative representations. And it should be obvious that compose is a lot more computationally expensive. Neither are really necessary for pure unit conversion, where `to` is your friend. I have evaluated several python packages for handing units and astropy seems to be excellent and most suit our requirements, once one gets to grips with compose , decompose and to and their intended uses. After I have used the package a bit more and got experience with students using it in the labs I will send any suggestions for clarification of the documentation. From my experience so far I think it would be great if the error messages gave a little more information about why it failed. Thanks for your help, John > Mike > > > >> >> Regards, >> >> John >> >> >> >> >> >> On 1 Jul 2014, at 18:43, Erik Bray wrote: >> >>> If I understand correctly this is because u.J is already defined in terms of >>> kilograms, meters, and seconds (actually Newtons and meters). You could >>> redefine J as a new unit, and then redefine those other units relative to the new J. >>> >>> But I'm not entirely clear exactly what the intent is here. I do agree the >>> error is a little confusing. But not as much if you know that Joule is already a >>> compound unit, and it's trying to recursively decompose the units that comprise >>> it in terms of Joules, hence the confusion. >>> >>> Erik >>> >>> On 07/01/2014 11:18 AM, John Quinn wrote: >>>> Hello, >>>> >>>> I am currently evaluating iPython Notebook as a replacement for MATHCAD in our >>>> teaching laboratories >>>> and am particularly interested in using the units and constants packages of >>>> astropy. >>>> >>>> I have encountered an apparent bug using the units decompose function and have >>>> reduced it to the >>>> following example: >>>> >>>>> from astropy import units as u >>>>> u.J.decompose(bases=[u.J]) >>>> >>>> which produces the errors given below. >>>> >>>> Similarly, I cannot decompose a unit consisting of 1 u.N * u.m into u.J, but >>>> strangely u.Ry.decompose(bases=[u.J]) works fine. >>>> >>>> Am I missing something obvious or is this a bug? >>>> >>>> I am using astropy 0.3.2 with python 3.4.1 on Mac OS X (anaconda). I see the >>>> same on the Linux and Windows >>>> versions and with Python 2.7.7. >>>> >>>> Thanks, >>>> >>>> John >>>> >>>> --------------------------------------------------------------------------- >>>> UnitsError Traceback (most recent call last) >>>> in() >>>> ----> 1 u.J.decompose(bases=[u.J]) >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) >>>> 1837 >>>> 1838 def decompose(self, bases=set()): >>>> -> 1839 return self._represents.decompose(bases=bases) >>>> 1840 decompose.__doc__= UnitBase.decompose.__doc__ >>>> 1841 >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) >>>> 1999 >>>> 2000 x = CompositeUnit(self.scale, self.bases, self.powers, decompose=True, >>>> -> 2001 decompose_bases=bases) >>>> 2002 if len(bases) == 0: >>>> 2003 self._decomposed_cache= x >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in__init__(self, scale, bases, powers, decompose, decompose_bases, _error_check) >>>> 1897 self._powers= powers >>>> 1898 self._decomposed_cache= None >>>> -> 1899 self._expand_and_gather(decompose=decompose, bases=decompose_bases) >>>> 1900 >>>> 1901 def __repr__(self): >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in_expand_and_gather(self, decompose, bases) >>>> 1959 for b, pin zip(self.bases, self.powers): >>>> 1960 if decomposeand bnot in bases: >>>> -> 1961 b = b.decompose(bases=bases) >>>> 1962 >>>> 1963 if isinstance(b, CompositeUnit): >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) >>>> 1837 >>>> 1838 def decompose(self, bases=set()): >>>> -> 1839 return self._represents.decompose(bases=bases) >>>> 1840 decompose.__doc__= UnitBase.decompose.__doc__ >>>> 1841 >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) >>>> 1999 >>>> 2000 x = CompositeUnit(self.scale, self.bases, self.powers, decompose=True, >>>> -> 2001 decompose_bases=bases) >>>> 2002 if len(bases) == 0: >>>> 2003 self._decomposed_cache= x >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in__init__(self, scale, bases, powers, decompose, decompose_bases, _error_check) >>>> 1897 self._powers= powers >>>> 1898 self._decomposed_cache= None >>>> -> 1899 self._expand_and_gather(decompose=decompose, bases=decompose_bases) >>>> 1900 >>>> 1901 def __repr__(self): >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py in_expand_and_gather(self, decompose, bases) >>>> 1959 for b, pin zip(self.bases, self.powers): >>>> 1960 if decomposeand bnot in bases: >>>> -> 1961 b = b.decompose(bases=bases) >>>> 1962 >>>> 1963 if isinstance(b, CompositeUnit): >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py indecompose(self, bases) >>>> 1573 raise UnitsError( >>>> 1574 "Unit {0} can not be decomposed into the requested" >>>> -> 1575 "bases".format(self)) >>>> 1576 >>>> 1577 return self >>>> >>>> UnitsError: Unit kg can not be decomposed into the requested bases >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> Dr. John Quinn >> School of Physics >> Science Center North >> University College Dublin >> Belfield, Dublin 4 >> Ireland >> >> T: +353-1-7162278 >> F: +353-1-2837275 >> john.quinn at ucd.ie >> >> >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > ? > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > > http://www.droettboom.com > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy Dr. John Quinn School of Physics Science Center North University College Dublin Belfield, Dublin 4 Ireland T: +353-1-7162278 F: +353-1-2837275 john.quinn at ucd.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From npkuin at gmail.com Wed Jul 2 18:30:20 2014 From: npkuin at gmail.com (Paul Kuin) Date: Wed, 2 Jul 2014 23:30:20 +0100 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: <25817621.3997271404278146242.JavaMail.coremail@mailweb> References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <72d0dc641e0a4.53b3244d@uwo.ca> <72d0a66e1b7de.53b3248a@uwo.ca> <73e0f6841a6de.53b324c8@uwo.ca> <72d0b1e91db8a.53b34efd@uwo.ca> <25817621.3997271404278146242.JavaMail.coremail@mailweb> Message-ID: Reading all this, I think that part of the success of the IDL Astro library is due to having one head, Wayne Landsman, put it all together. This reads like a conversation on the tower of Babel. Everyone their own method. Someone should take the time to check and compare all the different implementations. Some funding for such work would be very useful and save on duplication. I think this is a task that the IAU could(should?) be involved in. Paul On Wed, Jul 2, 2014 at 6:15 AM, Guang Yang wrote: > Thank all of you for giving those advices. I think I won't bother to > switch between python and IDL in my next project. ^^ > > Best wishes, > Guang > > > -----Original email----- > *From:* "Sofia Lianou" > *Sent Time:* Jul 2, 2014 5:14:53 AM > *To:* "Astronomical Python mailing list" , "Adam > Ginsburg" > *Cc:* "Pauline Barmby" > > *Subject:* Re: [AstroPy] Some Feedbacks about Astropy > > Hello, > > This is something that imagecube is doing, too, and the package is hosted > here: > http://sophiathl.github.io/imagecube/ > > Beta release to follow soon, along with proper documentation. > > Cheers, > Sophia, Pauline, and Jeff > > On 07/01/14, *Adam Ginsburg * wrote: > > > 1. I find no tools to align two images, i.e. to uniform their > astrometry, pixel scale, image size and etc. hastrom.pro ( > http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is a good > example to perform such a task. > > I've written a tool to do that: > https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py > ...I think it does what hastrom does, not hcongrid, which means I > should change the name. > > Otherwise, you can use the montage wrapper: > http://www.astropy.org/montage-wrapper/ > > > -- > Adam Ginsburg > Fellow, European Southern Observatory > http://www.adamgginsburg.com/ > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > > _______________________________________________ > 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) 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 thomas.robitaille at gmail.com Thu Jul 3 02:10:52 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 03 Jul 2014 08:10:52 +0200 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <72d0dc641e0a4.53b3244d@uwo.ca> <72d0a66e1b7de.53b3248a@uwo.ca> <73e0f6841a6de.53b324c8@uwo.ca> <72d0b1e91db8a.53b34efd@uwo.ca> <25817621.3997271404278146242.JavaMail.coremail@mailweb> Message-ID: <53B4F3EC.4080608@gmail.com> Paul Kuin wrote: > Reading all this, I think that part of the success of the IDL Astro > library is due to having one head, Wayne Landsman, put it all together. > This reads like a conversation on the tower of Babel. Everyone their own > method. Someone should take the time to check and compare all the > different implementations. Some funding for such work would be very > useful and save on duplication. I think this is a task that the IAU > could(should?) be involved in. Reducing duplication is precisely the goal of the Astropy project - in fact, we have a rule that 'affiliated' packages should not duplicate functionality from the core, and also avoid duplication amongst one another. See the original vision document: http://docs.astropy.org/en/stable/development/vision.html If you are interested in getting involved, you can join the astropy-dev mailing list. As part of the Astropy project, there have already been a number of successes in merging existing packages to provide a core implementation (for example the cosmology routines). On the more specific topic of re-projection - this is clearly a highly requested feature, and I think it should be targeted as something that should have an implementation in the core astropy package that then gets used by all other packages. As a side note, the fact there was more than one reply to the original question is a testimony to the strength of the development community in Python - people are clearly not just waiting for one person to just write it all. Yes, we need to all make an effort to not duplicate things needlessly, but on the other hand, having two different ways of approaching the same problem is not always bad. Cheers, Tom > Paul > > > On Wed, Jul 2, 2014 at 6:15 AM, Guang Yang > wrote: > > Thank all of you for giving those advices. I think I won't bother to > switch between python and IDL in my next project. ^^ > > Best wishes, > Guang > > > -----Original email----- > *From:* "Sofia Lianou" > > *Sent Time:* Jul 2, 2014 5:14:53 AM > *To:* "Astronomical Python mailing list" >, "Adam Ginsburg" > > > *Cc:* "Pauline Barmby" > > > *Subject:* Re: [AstroPy] Some Feedbacks about Astropy > > Hello, > > This is something that imagecube is doing, too, and the package > is hosted here: > http://sophiathl.github.io/imagecube/ > > Beta release to follow soon, along with proper documentation. > > Cheers, > Sophia, Pauline, and Jeff > > On 07/01/14, *Adam Ginsburg * > wrote: >> > 1. I find no tools to align two images, i.e. to uniform >> their astrometry, pixel scale, image size and etc. >> hastrom.pro >> (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is >> a good example to perform such a task. >> >> I've written a tool to do that: >> https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py >> ...I think it does what hastrom does, not hcongrid, which means I >> should change the name. >> >> Otherwise, you can use the montage wrapper: >> http://www.astropy.org/montage-wrapper/ >> >> >> -- >> Adam Ginsburg >> Fellow, European Southern Observatory >> http://www.adamgginsburg.com/ >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > > _______________________________________________ > 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) > mobile +44(0)7806985366 skype ID: npkuin > Mullard Space Science Laboratory ? University College London ? > Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From adam.g.ginsburg at gmail.com Thu Jul 3 03:18:19 2014 From: adam.g.ginsburg at gmail.com (Adam Ginsburg) Date: Thu, 3 Jul 2014 09:18:19 +0200 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: <53B4F3EC.4080608@gmail.com> References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <72d0dc641e0a4.53b3244d@uwo.ca> <72d0a66e1b7de.53b3248a@uwo.ca> <73e0f6841a6de.53b324c8@uwo.ca> <72d0b1e91db8a.53b34efd@uwo.ca> <25817621.3997271404278146242.JavaMail.coremail@mailweb> <53B4F3EC.4080608@gmail.com> Message-ID: I agree with Tom's points, but I'd also like to clarify that the variety of replies were not all to the same question. The scipy.map_coordinates+astropy.wcs, pyAST, and montage utilities that I, Ray, and Sophie mentioned solve the problem of image regridding and reprojection, which as Tom points out belongs in astropy-core eventually. The montage approach uses a wrapper to an underlying C program called montage that needs to be installed independently. The scipy approach is more purely python, but it requires interpolation and is not flux conserving (montage is). The pyAST approach wraps another underlying C library and implements its own resampling that can be flux conserving depending on certain flags chosen (but Dave Berry, correct me if I've gotten something wrong here): http://dsberry.github.io/starlink/node1.html#Resample http://www.starlink.rl.ac.uk/docs/sun210.htx/node371.html These routines could probably live in something called astropy.reprojection or something similar. The second class of problems addressed is image registration, which I think is being treated in ccdproc, SRPAstro, and the methods that Ray mentioned. I think these are each niche codes with a different role; image registration based on star matching is very different from that based on FFTs and extended emission matching. For a summary of the codes available for extended emission registration, have a look at http://image-registration.readthedocs.org/en/latest/#programs-implementing-these-methods-in-various-languages. I hope this is useful clarification, but please correct me if I misrepresented anyone's code here. On Thu, Jul 3, 2014 at 8:10 AM, Thomas Robitaille wrote: > Paul Kuin wrote: >> Reading all this, I think that part of the success of the IDL Astro >> library is due to having one head, Wayne Landsman, put it all together. >> This reads like a conversation on the tower of Babel. Everyone their own >> method. Someone should take the time to check and compare all the >> different implementations. Some funding for such work would be very >> useful and save on duplication. I think this is a task that the IAU >> could(should?) be involved in. > > Reducing duplication is precisely the goal of the Astropy project - in > fact, we have a rule that 'affiliated' packages should not duplicate > functionality from the core, and also avoid duplication amongst one > another. See the original vision document: > > http://docs.astropy.org/en/stable/development/vision.html > > If you are interested in getting involved, you can join the astropy-dev > mailing list. As part of the Astropy project, there have already been a > number of successes in merging existing packages to provide a core > implementation (for example the cosmology routines). > > On the more specific topic of re-projection - this is clearly a highly > requested feature, and I think it should be targeted as something that > should have an implementation in the core astropy package that then gets > used by all other packages. > > As a side note, the fact there was more than one reply to the original > question is a testimony to the strength of the development community in > Python - people are clearly not just waiting for one person to just > write it all. Yes, we need to all make an effort to not duplicate things > needlessly, but on the other hand, having two different ways of > approaching the same problem is not always bad. > > Cheers, > Tom > >> Paul >> >> >> On Wed, Jul 2, 2014 at 6:15 AM, Guang Yang > > wrote: >> >> Thank all of you for giving those advices. I think I won't bother to >> switch between python and IDL in my next project. ^^ >> >> Best wishes, >> Guang >> >> >> -----Original email----- >> *From:* "Sofia Lianou" > >> *Sent Time:* Jul 2, 2014 5:14:53 AM >> *To:* "Astronomical Python mailing list" > >, "Adam Ginsburg" >> > >> *Cc:* "Pauline Barmby" > >> >> *Subject:* Re: [AstroPy] Some Feedbacks about Astropy >> >> Hello, >> >> This is something that imagecube is doing, too, and the package >> is hosted here: >> http://sophiathl.github.io/imagecube/ >> >> Beta release to follow soon, along with proper documentation. >> >> Cheers, >> Sophia, Pauline, and Jeff >> >> On 07/01/14, *Adam Ginsburg * > > wrote: >>> > 1. I find no tools to align two images, i.e. to uniform >>> their astrometry, pixel scale, image size and etc. >>> hastrom.pro >>> (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is >>> a good example to perform such a task. >>> >>> I've written a tool to do that: >>> https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py >>> ...I think it does what hastrom does, not hcongrid, which means I >>> should change the name. >>> >>> Otherwise, you can use the montage wrapper: >>> http://www.astropy.org/montage-wrapper/ >>> >>> >>> -- >>> Adam Ginsburg >>> Fellow, European Southern Observatory >>> http://www.adamgginsburg.com/ >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >> >> >> >> _______________________________________________ >> 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) >> mobile +44(0)7806985366 skype ID: npkuin >> Mullard Space Science Laboratory ? University College London ? >> Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Adam Ginsburg Fellow, European Southern Observatory http://www.adamgginsburg.com/ From martinberoiz at gmail.com Thu Jul 3 10:47:57 2014 From: martinberoiz at gmail.com (Martin Beroiz) Date: Thu, 3 Jul 2014 09:47:57 -0500 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <72d0dc641e0a4.53b3244d@uwo.ca> <72d0a66e1b7de.53b3248a@uwo.ca> <73e0f6841a6de.53b324c8@uwo.ca> <72d0b1e91db8a.53b34efd@uwo.ca> <25817621.3997271404278146242.JavaMail.coremail@mailweb> <53B4F3EC.4080608@gmail.com> Message-ID: Hello, I also did my own registration code based on an approximate rotation + translation and source correspondence with a RANSAC algorithm. It?s inspired in openCV?s algorithms for image registration and it works with stellar fields like the ones I use. (openCV methods didn?t work out of the box for the images I needed) But I would like to see something like astrometry.net does, identifying pentagons or other polygons in both images. In fact I tried to do something like that myself and then I set that aside for lack of time. Does anyone know if there?s anything like that implemented yet? I would like to see that included in astropy. M. On Jul 3, 2014, at 2:18 AM, Adam Ginsburg wrote: > I agree with Tom's points, but I'd also like to clarify that the > variety of replies were not all to the same question. > > The scipy.map_coordinates+astropy.wcs, pyAST, and montage utilities > that I, Ray, and Sophie mentioned solve the problem of image > regridding and reprojection, which as Tom points out belongs in > astropy-core eventually. > > The montage approach uses a wrapper to an underlying C program called > montage that needs to be installed independently. The scipy approach > is more purely python, but it requires interpolation and is not flux > conserving (montage is). The pyAST approach wraps another underlying > C library and implements its own resampling that can be flux > conserving depending on certain flags chosen (but Dave Berry, correct > me if I've gotten something wrong here): > http://dsberry.github.io/starlink/node1.html#Resample > http://www.starlink.rl.ac.uk/docs/sun210.htx/node371.html > These routines could probably live in something called > astropy.reprojection or something similar. > > > > The second class of problems addressed is image registration, which I > think is being treated in ccdproc, SRPAstro, and the methods that Ray > mentioned. I think these are each niche codes with a different role; > image registration based on star matching is very different from that > based on FFTs and extended emission matching. For a summary of the > codes available for extended emission registration, have a look at > http://image-registration.readthedocs.org/en/latest/#programs-implementing-these-methods-in-various-languages. > > I hope this is useful clarification, but please correct me if I > misrepresented anyone's code here. > > On Thu, Jul 3, 2014 at 8:10 AM, Thomas Robitaille > wrote: >> Paul Kuin wrote: >>> Reading all this, I think that part of the success of the IDL Astro >>> library is due to having one head, Wayne Landsman, put it all together. >>> This reads like a conversation on the tower of Babel. Everyone their own >>> method. Someone should take the time to check and compare all the >>> different implementations. Some funding for such work would be very >>> useful and save on duplication. I think this is a task that the IAU >>> could(should?) be involved in. >> >> Reducing duplication is precisely the goal of the Astropy project - in >> fact, we have a rule that 'affiliated' packages should not duplicate >> functionality from the core, and also avoid duplication amongst one >> another. See the original vision document: >> >> http://docs.astropy.org/en/stable/development/vision.html >> >> If you are interested in getting involved, you can join the astropy-dev >> mailing list. As part of the Astropy project, there have already been a >> number of successes in merging existing packages to provide a core >> implementation (for example the cosmology routines). >> >> On the more specific topic of re-projection - this is clearly a highly >> requested feature, and I think it should be targeted as something that >> should have an implementation in the core astropy package that then gets >> used by all other packages. >> >> As a side note, the fact there was more than one reply to the original >> question is a testimony to the strength of the development community in >> Python - people are clearly not just waiting for one person to just >> write it all. Yes, we need to all make an effort to not duplicate things >> needlessly, but on the other hand, having two different ways of >> approaching the same problem is not always bad. >> >> Cheers, >> Tom >> >>> Paul >>> >>> >>> On Wed, Jul 2, 2014 at 6:15 AM, Guang Yang >> > wrote: >>> >>> Thank all of you for giving those advices. I think I won't bother to >>> switch between python and IDL in my next project. ^^ >>> >>> Best wishes, >>> Guang >>> >>> >>> -----Original email----- >>> *From:* "Sofia Lianou" > >>> *Sent Time:* Jul 2, 2014 5:14:53 AM >>> *To:* "Astronomical Python mailing list" >> >, "Adam Ginsburg" >>> > >>> *Cc:* "Pauline Barmby" > >>> >>> *Subject:* Re: [AstroPy] Some Feedbacks about Astropy >>> >>> Hello, >>> >>> This is something that imagecube is doing, too, and the package >>> is hosted here: >>> http://sophiathl.github.io/imagecube/ >>> >>> Beta release to follow soon, along with proper documentation. >>> >>> Cheers, >>> Sophia, Pauline, and Jeff >>> >>> On 07/01/14, *Adam Ginsburg * >> > wrote: >>>>> 1. I find no tools to align two images, i.e. to uniform >>>> their astrometry, pixel scale, image size and etc. >>>> hastrom.pro >>>> (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is >>>> a good example to perform such a task. >>>> >>>> I've written a tool to do that: >>>> https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py >>>> ...I think it does what hastrom does, not hcongrid, which means I >>>> should change the name. >>>> >>>> Otherwise, you can use the montage wrapper: >>>> http://www.astropy.org/montage-wrapper/ >>>> >>>> >>>> -- >>>> Adam Ginsburg >>>> Fellow, European Southern Observatory >>>> http://www.adamgginsburg.com/ >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/astropy >>> >>> >>> >>> _______________________________________________ >>> 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) >>> mobile +44(0)7806985366 skype ID: npkuin >>> Mullard Space Science Laboratory ? University College London ? >>> Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> http://mail.scipy.org/mailman/listinfo/astropy >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > > -- > Adam Ginsburg > Fellow, European Southern Observatory > http://www.adamgginsburg.com/ > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at mumford.me.uk Thu Jul 3 12:27:01 2014 From: stuart at mumford.me.uk (Stuart Mumford) Date: Thu, 3 Jul 2014 17:27:01 +0100 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <72d0dc641e0a4.53b3244d@uwo.ca> <72d0a66e1b7de.53b3248a@uwo.ca> <73e0f6841a6de.53b324c8@uwo.ca> <72d0b1e91db8a.53b34efd@uwo.ca> <25817621.3997271404278146242.JavaMail.coremail@mailweb> <53B4F3EC.4080608@gmail.com> Message-ID: hello, Just a quick reminder about the feature identification and tracking algorithms (as well as RANSAC) that were implemented in scikit-image last summer. http://scikit-image.org/docs/0.10.x/api/skimage.feature.html So if anyone is going to work on registration they are probably a very helpful source of code and advice. SunPy has a cross correlation registration routine that uses scikit-image's match_template function. Stuart On 3 July 2014 15:47, Martin Beroiz wrote: > Hello, > > I also did my own registration code based on an approximate rotation + > translation and source correspondence with a RANSAC > algorithm. It?s inspired in openCV?s algorithms for image registration and > it works with stellar fields like the ones I use. > (openCV methods didn?t work out of the box for the images I needed) > > But I would like to see something like astrometry.net does, identifying > pentagons or other polygons in both images. > In fact I tried to do something like that myself and then I set that aside > for lack of time. > Does anyone know if there?s anything like that implemented yet? I would > like to see that included in astropy. > > M. > > On Jul 3, 2014, at 2:18 AM, Adam Ginsburg > wrote: > > I agree with Tom's points, but I'd also like to clarify that the > variety of replies were not all to the same question. > > The scipy.map_coordinates+astropy.wcs, pyAST, and montage utilities > that I, Ray, and Sophie mentioned solve the problem of image > regridding and reprojection, which as Tom points out belongs in > astropy-core eventually. > > The montage approach uses a wrapper to an underlying C program called > montage that needs to be installed independently. The scipy approach > is more purely python, but it requires interpolation and is not flux > conserving (montage is). The pyAST approach wraps another underlying > C library and implements its own resampling that can be flux > conserving depending on certain flags chosen (but Dave Berry, correct > me if I've gotten something wrong here): > http://dsberry.github.io/starlink/node1.html#Resample > http://www.starlink.rl.ac.uk/docs/sun210.htx/node371.html > These routines could probably live in something called > astropy.reprojection or something similar. > > > > The second class of problems addressed is image registration, which I > think is being treated in ccdproc, SRPAstro, and the methods that Ray > mentioned. I think these are each niche codes with a different role; > image registration based on star matching is very different from that > based on FFTs and extended emission matching. For a summary of the > codes available for extended emission registration, have a look at > > http://image-registration.readthedocs.org/en/latest/#programs-implementing-these-methods-in-various-languages > . > > I hope this is useful clarification, but please correct me if I > misrepresented anyone's code here. > > On Thu, Jul 3, 2014 at 8:10 AM, Thomas Robitaille > wrote: > > Paul Kuin wrote: > > Reading all this, I think that part of the success of the IDL Astro > library is due to having one head, Wayne Landsman, put it all together. > This reads like a conversation on the tower of Babel. Everyone their own > method. Someone should take the time to check and compare all the > different implementations. Some funding for such work would be very > useful and save on duplication. I think this is a task that the IAU > could(should?) be involved in. > > > Reducing duplication is precisely the goal of the Astropy project - in > fact, we have a rule that 'affiliated' packages should not duplicate > functionality from the core, and also avoid duplication amongst one > another. See the original vision document: > > http://docs.astropy.org/en/stable/development/vision.html > > If you are interested in getting involved, you can join the astropy-dev > mailing list. As part of the Astropy project, there have already been a > number of successes in merging existing packages to provide a core > implementation (for example the cosmology routines). > > On the more specific topic of re-projection - this is clearly a highly > requested feature, and I think it should be targeted as something that > should have an implementation in the core astropy package that then gets > used by all other packages. > > As a side note, the fact there was more than one reply to the original > question is a testimony to the strength of the development community in > Python - people are clearly not just waiting for one person to just > write it all. Yes, we need to all make an effort to not duplicate things > needlessly, but on the other hand, having two different ways of > approaching the same problem is not always bad. > > Cheers, > Tom > > Paul > > > On Wed, Jul 2, 2014 at 6:15 AM, Guang Yang > wrote: > > Thank all of you for giving those advices. I think I won't bother to > switch between python and IDL in my next project. ^^ > > Best wishes, > Guang > > > -----Original email----- > *From:* "Sofia Lianou" > > *Sent Time:* Jul 2, 2014 5:14:53 AM > *To:* "Astronomical Python mailing list" >, "Adam Ginsburg" > > > *Cc:* "Pauline Barmby" > > > *Subject:* Re: [AstroPy] Some Feedbacks about Astropy > > Hello, > > This is something that imagecube is doing, too, and the package > is hosted here: > http://sophiathl.github.io/imagecube/ > > Beta release to follow soon, along with proper documentation. > > Cheers, > Sophia, Pauline, and Jeff > > On 07/01/14, *Adam Ginsburg * > wrote: > > 1. I find no tools to align two images, i.e. to uniform > > their astrometry, pixel scale, image size and etc. > hastrom.pro > (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is > a good example to perform such a task. > > I've written a tool to do that: > > https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py > ...I think it does what hastrom does, not hcongrid, which means I > should change the name. > > Otherwise, you can use the montage wrapper: > http://www.astropy.org/montage-wrapper/ > > > -- > Adam Ginsburg > Fellow, European Southern Observatory > http://www.adamgginsburg.com/ > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > > > _______________________________________________ > 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) > mobile +44(0)7806985366 skype ID: npkuin > Mullard Space Science Laboratory ? University College London ? > Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > > > -- > Adam Ginsburg > Fellow, European Southern Observatory > http://www.adamgginsburg.com/ > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rays at blue-cove.com Thu Jul 3 12:32:13 2014 From: rays at blue-cove.com (RayS) Date: Thu, 03 Jul 2014 09:32:13 -0700 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <72d0dc641e0a4.53b3244d@uwo.ca> <72d0a66e1b7de.53b3248a@uwo.ca> <73e0f6841a6de.53b324c8@uwo.ca> <72d0b1e91db8a.53b34efd@uwo.ca> <25817621.3997271404278146242.JavaMail.coremail@mailweb> <53B4F3EC.4080608@gmail.com> Message-ID: <201407031632.s63GWEgZ016596@blue-cove.com> At 07:47 AM 7/3/2014, you wrote: >But I would like to see something like >astrometry.net does, identifying pentagons or >other polygons in both images. >In fact I tried to do something like that myself and then I set that >aside for lack of time. >Does anyone know if there's anything like that implemented yet? I >would like to see that included in astropy. http://image-registration.readthedocs.org/en/latest/#programs-implementing-these-methods-in-various-languages was just pointed out, and some of the implementations are significantly diffferent, so worth scanning through. Gohlke's is similar to Xie's IDL that I coded in Python, and as far as I know does not preserve luminosity etc. I was more interested in a stacking process that uses sparse matrices and sets the clipped/low values of input images to None. It created a 32 bit depth image that varied the noise spatially, due to the varied number of contributing images per pixel. No tests for luminosity preservation accuracy done... (http://rjs.org/astro/1004x/images/M101-Mt_Laguna-DSS1.jpg) I don't know if any professional packages use such a feature. I also tested Jan Kybic's "Elastic Image Registration using Parametric Deformation Models" http://cmp.felk.cvut.cz/~kybic/research.html#registration which he developed for CAT/MRI etc - Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From npkuin at gmail.com Thu Jul 3 14:30:39 2014 From: npkuin at gmail.com (Paul Kuin) Date: Thu, 3 Jul 2014 19:30:39 +0100 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <72d0dc641e0a4.53b3244d@uwo.ca> <72d0a66e1b7de.53b3248a@uwo.ca> <73e0f6841a6de.53b324c8@uwo.ca> <72d0b1e91db8a.53b34efd@uwo.ca> <25817621.3997271404278146242.JavaMail.coremail@mailweb> <53B4F3EC.4080608@gmail.com> Message-ID: Dear Tom and Adam, Those were convincing replies. I stand corrected. I learned some things from your reply, however, as I need to check (again) flux conservation in the Scipy routine I'm using. I checked a long time ago, but things get 'improved' sometimes the wrong way. I am thinking of getting on the dev list just for the reason of knowing issues like this (though I see coding more as a thing that comes with getting the science done than a thing in itself.) I kind of felt bad for Guang Yang, who offered a piece of code he wrote, and would not like to see him driven into using IDL. Some 25 years ago I thought IDL was great, but with the commercialisation came problems and I think one is better off with open source. Another issue altogether is that it would be good to have the endorsement of the IAU. At the moment the IAU is renewing itself, and I think the union would benefit from having members involved who are both astronomer/astrophysicist and software developer. I think that either of you would benefit the community. Why do this? The IAU needs to go with the times. Astropy is in much the same position for astronomy as FITS was in the early 1990-ies. I think it gives visibility, focus, and legitimises asking for support. At the moment the astronomical software is part of Commission 5 (which is being revamped as everything else in the IAU), and there are several software related things going on in other divisions. Cheers, Paul On Thu, Jul 3, 2014 at 8:18 AM, Adam Ginsburg wrote: > I agree with Tom's points, but I'd also like to clarify that the > variety of replies were not all to the same question. > > The scipy.map_coordinates+astropy.wcs, pyAST, and montage utilities > that I, Ray, and Sophie mentioned solve the problem of image > regridding and reprojection, which as Tom points out belongs in > astropy-core eventually. > > The montage approach uses a wrapper to an underlying C program called > montage that needs to be installed independently. The scipy approach > is more purely python, but it requires interpolation and is not flux > conserving (montage is). The pyAST approach wraps another underlying > C library and implements its own resampling that can be flux > conserving depending on certain flags chosen (but Dave Berry, correct > me if I've gotten something wrong here): > http://dsberry.github.io/starlink/node1.html#Resample > http://www.starlink.rl.ac.uk/docs/sun210.htx/node371.html > These routines could probably live in something called > astropy.reprojection or something similar. > > > > The second class of problems addressed is image registration, which I > think is being treated in ccdproc, SRPAstro, and the methods that Ray > mentioned. I think these are each niche codes with a different role; > image registration based on star matching is very different from that > based on FFTs and extended emission matching. For a summary of the > codes available for extended emission registration, have a look at > > http://image-registration.readthedocs.org/en/latest/#programs-implementing-these-methods-in-various-languages > . > > I hope this is useful clarification, but please correct me if I > misrepresented anyone's code here. > > On Thu, Jul 3, 2014 at 8:10 AM, Thomas Robitaille > wrote: > > Paul Kuin wrote: > >> Reading all this, I think that part of the success of the IDL Astro > >> library is due to having one head, Wayne Landsman, put it all together. > >> This reads like a conversation on the tower of Babel. Everyone their own > >> method. Someone should take the time to check and compare all the > >> different implementations. Some funding for such work would be very > >> useful and save on duplication. I think this is a task that the IAU > >> could(should?) be involved in. > > > > Reducing duplication is precisely the goal of the Astropy project - in > > fact, we have a rule that 'affiliated' packages should not duplicate > > functionality from the core, and also avoid duplication amongst one > > another. See the original vision document: > > > > http://docs.astropy.org/en/stable/development/vision.html > > > > If you are interested in getting involved, you can join the astropy-dev > > mailing list. As part of the Astropy project, there have already been a > > number of successes in merging existing packages to provide a core > > implementation (for example the cosmology routines). > > > > On the more specific topic of re-projection - this is clearly a highly > > requested feature, and I think it should be targeted as something that > > should have an implementation in the core astropy package that then gets > > used by all other packages. > > > > As a side note, the fact there was more than one reply to the original > > question is a testimony to the strength of the development community in > > Python - people are clearly not just waiting for one person to just > > write it all. Yes, we need to all make an effort to not duplicate things > > needlessly, but on the other hand, having two different ways of > > approaching the same problem is not always bad. > > > > Cheers, > > Tom > > > >> Paul > >> > >> > >> On Wed, Jul 2, 2014 at 6:15 AM, Guang Yang >> > wrote: > >> > >> Thank all of you for giving those advices. I think I won't bother to > >> switch between python and IDL in my next project. ^^ > >> > >> Best wishes, > >> Guang > >> > >> > >> -----Original email----- > >> *From:* "Sofia Lianou" > > >> *Sent Time:* Jul 2, 2014 5:14:53 AM > >> *To:* "Astronomical Python mailing list" >> >, "Adam Ginsburg" > >> > > >> *Cc:* "Pauline Barmby" > > >> > >> *Subject:* Re: [AstroPy] Some Feedbacks about Astropy > >> > >> Hello, > >> > >> This is something that imagecube is doing, too, and the package > >> is hosted here: > >> http://sophiathl.github.io/imagecube/ > >> > >> Beta release to follow soon, along with proper documentation. > >> > >> Cheers, > >> Sophia, Pauline, and Jeff > >> > >> On 07/01/14, *Adam Ginsburg * >> > wrote: > >>> > 1. I find no tools to align two images, i.e. to uniform > >>> their astrometry, pixel scale, image size and etc. > >>> hastrom.pro > >>> (http://idlastro.gsfc.nasa.gov/ftp/pro/astrom/hastrom.pro) is > >>> a good example to perform such a task. > >>> > >>> I've written a tool to do that: > >>> > https://github.com/keflavich/FITS_tools/blob/master/FITS_tools/hcongrid.py > >>> ...I think it does what hastrom does, not hcongrid, which > means I > >>> should change the name. > >>> > >>> Otherwise, you can use the montage wrapper: > >>> http://www.astropy.org/montage-wrapper/ > >>> > >>> > >>> -- > >>> Adam Ginsburg > >>> Fellow, European Southern Observatory > >>> http://www.adamgginsburg.com/ > >>> _______________________________________________ > >>> AstroPy mailing list > >>> AstroPy at scipy.org > >>> http://mail.scipy.org/mailman/listinfo/astropy > >> > >> > >> > >> _______________________________________________ > >> 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) > >> mobile +44(0)7806985366 skype ID: npkuin > >> Mullard Space Science Laboratory ? University College London ? > >> Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. > >> > >> _______________________________________________ > >> AstroPy mailing list > >> AstroPy at scipy.org > >> http://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > -- > Adam Ginsburg > Fellow, European Southern Observatory > http://www.adamgginsburg.com/ > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- * * * * * * * * 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) 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 stefano.covino at brera.inaf.it Thu Jul 3 16:47:32 2014 From: stefano.covino at brera.inaf.it (Stefano Covino) Date: Thu, 3 Jul 2014 22:47:32 +0200 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <72d0dc641e0a4.53b3244d@uwo.ca> <72d0a66e1b7de.53b3248a@uwo.ca> <73e0f6841a6de.53b324c8@uwo.ca> <72d0b1e91db8a.53b34efd@uwo.ca> <25817621.3997271404278146242.JavaMail.coremail@mailweb> <53B4F3EC.4080608@gmail.com> Message-ID: > Il giorno 03/lug/2014, alle ore 16:47, Martin Beroiz ha scritto: > > But I would like to see something like astrometry.net does, identifying pentagons or other polygons in both images. > In fact I tried to do something like that myself and then I set that aside for lack of time. > Does anyone know if there?s anything like that implemented yet? I would like to see that included in astropy. Dear Matin, indeed the algorithm in SRPAstro to align two images, or to derive the astrometry of a frame, works matching triangles. However, although it works pretty well, it is far from being optimized. Bye, Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinberoiz at gmail.com Thu Jul 3 18:47:15 2014 From: martinberoiz at gmail.com (Martin Beroiz) Date: Thu, 3 Jul 2014 17:47:15 -0500 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: References: <863181.3954441404220356854.JavaMail.coremail@mailweb> <72d0dc641e0a4.53b3244d@uwo.ca> <72d0a66e1b7de.53b3248a@uwo.ca> <73e0f6841a6de.53b324c8@uwo.ca> <72d0b1e91db8a.53b34efd@uwo.ca> <25817621.3997271404278146242.JavaMail.coremail@mailweb> <53B4F3EC.4080608@gmail.com> Message-ID: <8D5DEF86-3FB1-449F-8ECA-D601DEEFC5F6@gmail.com> Thanks, I will check it out! On Jul 3, 2014, at 3:47 PM, Stefano Covino wrote: > > > Il giorno 03/lug/2014, alle ore 16:47, Martin Beroiz ha scritto: > >> But I would like to see something like astrometry.net does, identifying pentagons or other polygons in both images. >> In fact I tried to do something like that myself and then I set that aside for lack of time. >> Does anyone know if there?s anything like that implemented yet? I would like to see that included in astropy. > > Dear Matin, > > indeed the algorithm in SRPAstro to align two images, or to derive the astrometry of a frame, works matching triangles. However, although it works pretty well, it is far from being optimized. > > Bye, > Stefano > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Tue Jul 1 17:16:31 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Tue, 1 Jul 2014 17:16:31 -0400 Subject: [AstroPy] Bug in units decompose()? In-Reply-To: <53B31CDD.7080709@stsci.edu> References: <0E94D9EB-A58A-48C2-8AC2-0E350D511E7F@ucd.ie> <53B2F344.2000001@stsci.edu> <6CDB4DF6-9B57-403B-A9D8-0348EF632ADA@ucd.ie> <53B31CDD.7080709@stsci.edu> Message-ID: <53B3252F.5060707@stsci.edu> I've filed a pull request for the |X.decompose(bases=[X])| issue here: https://github.com/astropy/astropy/pull/2679 Mike On 07/01/2014 04:41 PM, Michael Droettboom wrote: > On 07/01/2014 04:14 PM, John Quinn wrote: > >> Thanks for the responses. >> >> I think I can use to() to convert to other units and that will do >> what I want. > > If you just want to convert a value to another unit, |to| is what you > want. |decompose| and |compose| are really more about introspecting > the structure of units and finding alternate representations. > >> >> I was confused after reading the documentation at: >> http://docs.astropy.org/en/stable/units/decomposing_and_composing.html#reducing-a-unit-to-its-irreducible-parts >> and found that: >> > u.J.compose() >> [Unit("J"), Unit("1e+07 erg"), Unit("4.58743e+17 Ry"), >> Unit("6.24151e+18 eV")] >> >> > u.Ry.decompose(bases=[u.m, u.N]) >> 2.17987e-18 m N >> >> > u.eV.decompose(bases=[u.m, u.N]) >> 1.60218e-19 m N >> >> but: >> >> > u.erg.decompose(bases=[u.m, u.N]) >> gives an error. > > erg is not defined in terms of N since it comes from the cgs system. > It is |cm2 g / s2|. If you want to recompose that back into N, you > should use |compose|: > > |u.erg.compose(units=[u.m, u.N]) > [Unit("1e-07 m N")] > | >> >> Similarly, converting to J sometimes works and sometimes doesn't, > > Can you elaborate on this? If something is nondeterministic I'd > consider that a bug. > >> and I was very surprised that decomposing >> something in J to J gave an error. > > We could probably special case this for decompose just to avoid confusion. > > I know this |decompose| vs. |compose| difference is confusing for > others as well, and your suggestions about how to improve the docs > and/or naming of things to make it more obvious are welcome. I think > we still want to have both available, and I don't see an argument for > changing the behavior (excepting the |X.decompose(bases=[X])| case). > |decompose| is asking "how is this unit defined from its lower-level > parts?", whereas |compose| is asking "given all of the units you know > about, how can this unit be refactored into them?" So |decompose| is > useful for introspecting the definition of a unit and |compose| is > useful for searching for alternative representations. And it should be > obvious that |compose| is a lot more computationally expensive. > Neither are really necessary for pure unit conversion, where `to` is > your friend. > > Mike > >> >> Regards, >> >> John >> >> >> >> >> >> On 1 Jul 2014, at 18:43, Erik Bray > > wrote: >> >>> If I understand correctly this is because u.J is already defined in >>> terms of >>> kilograms, meters, and seconds (actually Newtons and meters). You >>> could >>> redefine J as a new unit, and then redefine those other units >>> relative to the new J. >>> >>> But I'm not entirely clear exactly what the intent is here. I do >>> agree the >>> error is a little confusing. But not as much if you know that Joule >>> is already a >>> compound unit, and it's trying to recursively decompose the units >>> that comprise >>> it in terms of Joules, hence the confusion. >>> >>> Erik >>> >>> On 07/01/2014 11:18 AM, John Quinn wrote: >>>> Hello, >>>> >>>> I am currently evaluating iPython Notebook as a replacement for >>>> MATHCAD in our >>>> teaching laboratories >>>> and am particularly interested in using the units and constants >>>> packages of >>>> astropy. >>>> >>>> I have encountered an apparent bug using the units decompose >>>> function and have >>>> reduced it to the >>>> following example: >>>> >>>>> from astropy import units as u >>>>> u.J.decompose(bases=[u.J]) >>>> >>>> which produces the errors given below. >>>> >>>> Similarly, I cannot decompose a unit consisting of 1 u.N * u.m into >>>> u.J, but >>>> strangely u.Ry.decompose(bases=[u.J]) works fine. >>>> >>>> Am I missing something obvious or is this a bug? >>>> >>>> I am using astropy 0.3.2 with python 3.4.1 on Mac OS X (anaconda). >>>> I see the >>>> same on the Linux and Windows >>>> versions and with Python 2.7.7. >>>> >>>> Thanks, >>>> >>>> John >>>> >>>> --------------------------------------------------------------------------- >>>> UnitsError Traceback (most recent >>>> call last) >>>> in() >>>> ----> 1 u.J.decompose(bases=[u.J]) >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>>> indecompose(self, bases) >>>> 1837 >>>> 1838 def decompose(self, bases=set()): >>>> -> 1839 return self._represents.decompose(bases=bases) >>>> 1840 decompose.__doc__= UnitBase.decompose.__doc__ >>>> 1841 >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>>> indecompose(self, bases) >>>> 1999 >>>> 2000 x = CompositeUnit(self.scale, self.bases, >>>> self.powers, decompose=True, >>>> -> 2001 decompose_bases=bases) >>>> 2002 if len(bases) == 0: >>>> 2003 self._decomposed_cache= x >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>>> in__init__(self, scale, bases, powers, decompose, decompose_bases, >>>> _error_check) >>>> 1897 self._powers= powers >>>> 1898 self._decomposed_cache= None >>>> -> 1899 self._expand_and_gather(decompose=decompose, >>>> bases=decompose_bases) >>>> 1900 >>>> 1901 def __repr__(self): >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>>> in_expand_and_gather(self, decompose, bases) >>>> 1959 for b, pin zip(self.bases, self.powers): >>>> 1960 if decomposeand bnot in bases: >>>> -> 1961 b = b.decompose(bases=bases) >>>> 1962 >>>> 1963 if isinstance(b, CompositeUnit): >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>>> indecompose(self, bases) >>>> 1837 >>>> 1838 def decompose(self, bases=set()): >>>> -> 1839 return self._represents.decompose(bases=bases) >>>> 1840 decompose.__doc__= UnitBase.decompose.__doc__ >>>> 1841 >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>>> indecompose(self, bases) >>>> 1999 >>>> 2000 x = CompositeUnit(self.scale, self.bases, >>>> self.powers, decompose=True, >>>> -> 2001 decompose_bases=bases) >>>> 2002 if len(bases) == 0: >>>> 2003 self._decomposed_cache= x >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>>> in__init__(self, scale, bases, powers, decompose, decompose_bases, >>>> _error_check) >>>> 1897 self._powers= powers >>>> 1898 self._decomposed_cache= None >>>> -> 1899 self._expand_and_gather(decompose=decompose, >>>> bases=decompose_bases) >>>> 1900 >>>> 1901 def __repr__(self): >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>>> in_expand_and_gather(self, decompose, bases) >>>> 1959 for b, pin zip(self.bases, self.powers): >>>> 1960 if decomposeand bnot in bases: >>>> -> 1961 b = b.decompose(bases=bases) >>>> 1962 >>>> 1963 if isinstance(b, CompositeUnit): >>>> >>>> /Users/quinn/anaconda/envs/py34/lib/python3.4/site-packages/astropy/units/core.py >>>> indecompose(self, bases) >>>> 1573 raise UnitsError( >>>> 1574 "Unit {0} can not be decomposed into the >>>> requested" >>>> -> 1575 "bases".format(self)) >>>> 1576 >>>> 1577 return self >>>> >>>> UnitsError: Unit kg can not be decomposed into the requested bases >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> Dr. John Quinn >> School of Physics >> Science Center North >> University College Dublin >> Belfield, Dublin 4 >> Ireland >> >> T: +353-1-7162278 >> F: +353-1-2837275 >> john.quinn at ucd.ie >> >> >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > > http://www.droettboom.com > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy / -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek at astro.physik.uni-goettingen.de Thu Jul 10 10:03:19 2014 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Thu, 10 Jul 2014 16:03:19 +0200 Subject: [AstroPy] Request for Spectra files (in FITS format) In-Reply-To: References: Message-ID: <8E550010-8188-44C1-82F6-07BD6F9F1865@astro.physik.uni-goettingen.de> Hi Shailesh, >> I am working on the Google summer of code project for reading/writing spectra. To successfully cover all use cases, I need your help to provide me Spectra files in FITS format. At this stage we are most interested files that contain 1-dimensional extracted spectra (either long slit, multi-object or echelle) from optical or infrared spectrographs. But feel free to send any spectra that you would like to able to read easily with Astropy. >> > thanks for your work on this! Is this intended to become part of the specutils package, > or going directly into Astropy ?core?? > I assume you?d be considering model spectra as well; I have one specific case however > in the high-resolution spectra here > http://phoenix.astro.physik.uni-goettingen.de/?page_id=10 > which require the wavelengths to be read from a separate file (I suppose to deal with such > a case would require a new keyword for the FITS reader). sorry for getting back at this after such a long time; I don?t know if you are still working on the project. But I?ve just uploaded some sample files for the above format, and also another set of model spectra in IMAGE_HDU and BINTABLE format, respectively. The img spectrum can be read already, but wavelengths are not recognised; the table format generally can be read as an astropy Table. I have also added another file which is read in by Table.read() but raises several UnitsWarning: 'ANGSTROMS' did not parse as fits unit: At col 0, Unit 'ANGSTROMS' not supported by the FITS standard. Did you mean Angstrom or angstrom? [astropy.units.core] and consequently does not have a wavelength unit. This applies for probably every single spectrum in ftp://ftp.stsci.edu/cdbs/calspec/ so we should perhaps consider if we can tolerate the use of ?ANGSTROMS? or want to educate the folks at STScI on the use of proper FITS headers? Best, Derek From lsinger at caltech.edu Wed Jul 9 16:45:40 2014 From: lsinger at caltech.edu (Leo Singer) Date: Wed, 9 Jul 2014 13:45:40 -0700 Subject: [AstroPy] Astropy in fails to import in Apache mod_wsgi Flask application Message-ID: <8198F31F-96FB-43A7-8E2D-56680A1EAC63@caltech.edu> Hi, I have a Flask application that uses astropy, and I am trying to deploy it in Apache with mod_wsgi. Here's a minimal example app.wsgi file: import astropy from flask import Flask app = Flask(__name__) @app.route("/") def hello(): return "Hello World!" application = app It fails to import astropy because it cannot locate the Astropy config files. Here's the traceback from the Apache log file, error.log: /home/***/***/local/lib/python2.7/site-packages/astropy/config/configuration.py:680: ConfigurationMissingWarning: Configuration defaults will be used due to OSError:Could not find unix home directory to search for astropy config dir warn(ConfigurationMissingWarning(msg)) [client ***.***.***.***:*****] mod_wsgi (pid=*****): Target WSGI script '/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi' cannot be loaded as Python module. [client ***.***.***.***:*****] mod_wsgi (pid=*****): Exception occurred processing WSGI script '/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi'. [client ***.***.***.***:*****] Traceback (most recent call last): [client ***.***.***.***:*****] File "/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi", line 4, in [client ***.***.***.***:*****] import astropy [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/__init__.py", line 268, in [client ***.***.***.***:*****] _initialize_astropy() [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/__init__.py", line 250, in _initialize_astropy [client ***.***.***.***:*****] config.configuration.update_default_config(__package__, config_dir) [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/config/configuration.py", line 814, in update_default_config [client ***.***.***.***:*****] if path.exists(cfgfn): [client ***.***.***.***:*****] File "/home/***/***/lib/python2.7/genericpath.py", line 18, in exists [client ***.***.***.***:*****] os.stat(path) [client ***.***.***.***:*****] TypeError: coercing to Unicode: need string or buffer, NoneType found It's running as a user without a home directory. How do I import astropy if I don't have a home directory? Thanks, Leo From erik.tollerud at gmail.com Fri Jul 11 17:05:07 2014 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Fri, 11 Jul 2014 17:05:07 -0400 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: <863181.3954441404220356854.JavaMail.coremail@mailweb> References: <863181.3954441404220356854.JavaMail.coremail@mailweb> Message-ID: > 2. Though there's astropy.coordinates.matching.match_coordinates_sky to cross-correlate two catalogs, it doesn't allow user to specify matching radius and matching mode (e.g., one-one match). I've made a function to do so, and hope similar function can be included in astropy (https://github.com/Guang91/Astronomers_Tool_Box/blob/master/my_srcor.py). The idea is to use it like this (this is astropy 0.4 syntax - for astropy 0.3 it's similar, but replace SkyCoord with `ICRS` or whatever class makes sense for your coordinates): catalog = SkyCoord(ra_cat*u.deg, dec_cat*u.deg, frame='icrs') coordstomatch = SkyCoord(ra*u.deg, dec*u.deg, frame='icrs') idx, d2d, d3d = coordstomatch.match_to_catalog_sky(catalog) coordinateswithmatches = coordstomatch[d2d < 3*u.arcmin] catalogwithmatches = catalog[idx[d2d < 3*u.arcmin]] As for the "matching mode", the idea is that there are a lot of different "modes" people use, and match_to_catalog_sky (or match_to_catalog_3d) along with the `nthneighbor` argument should be flexible enough to take care of most of them. Can you be more specific about exactly what sort of mode you think is missing? This was not too thoroughly documented before v0.4 (the version about to be release), but there's a lot more there in v0.4. See http://devdocs.astropy.org/coordinates/matchsep.html#matching-catalogs (that's the developer documentation, but this will become http://docs.astropy.org/en/stable/coordinates/matchsep.html#matching-catalogs when 0.4 is released). -- Erik T From erik.tollerud at gmail.com Fri Jul 11 17:10:35 2014 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Fri, 11 Jul 2014 17:10:35 -0400 Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: References: <863181.3954441404220356854.JavaMail.coremail@mailweb> Message-ID: Oh, and there's an issue (https://github.com/astropy/astropy/issues/1846) to add the mode of "everything within x arcmin" - it's pretty straightforward to implement from the existing matching stuff, it just needs someone to take the time to work out the details... (SciPy sprint, perhaps, if anyone has some remaining time?) On Fri, Jul 11, 2014 at 5:05 PM, Erik Tollerud wrote: >> 2. Though there's astropy.coordinates.matching.match_coordinates_sky to cross-correlate two catalogs, it doesn't allow user to specify matching radius and matching mode (e.g., one-one match). I've made a function to do so, and hope similar function can be included in astropy (https://github.com/Guang91/Astronomers_Tool_Box/blob/master/my_srcor.py). > > The idea is to use it like this (this is astropy 0.4 syntax - for > astropy 0.3 it's similar, but replace SkyCoord with `ICRS` or whatever > class makes sense for your coordinates): > > catalog = SkyCoord(ra_cat*u.deg, dec_cat*u.deg, frame='icrs') > coordstomatch = SkyCoord(ra*u.deg, dec*u.deg, frame='icrs') > > idx, d2d, d3d = coordstomatch.match_to_catalog_sky(catalog) > > coordinateswithmatches = coordstomatch[d2d < 3*u.arcmin] > catalogwithmatches = catalog[idx[d2d < 3*u.arcmin]] > > > As for the "matching mode", the idea is that there are a lot of > different "modes" people use, and match_to_catalog_sky (or > match_to_catalog_3d) along with the `nthneighbor` argument should be > flexible enough to take care of most of them. Can you be more > specific about exactly what sort of mode you think is missing? > > > This was not too thoroughly documented before v0.4 (the version about > to be release), but there's a lot more there in v0.4. See > http://devdocs.astropy.org/coordinates/matchsep.html#matching-catalogs > (that's the developer documentation, but this will become > http://docs.astropy.org/en/stable/coordinates/matchsep.html#matching-catalogs > when 0.4 is released). > > > > -- > Erik T -- Erik T From yg1991 at mail.ustc.edu.cn Fri Jul 11 23:28:40 2014 From: yg1991 at mail.ustc.edu.cn (Guang Yang) Date: Sat, 12 Jul 2014 11:28:40 +0800 (CST) Subject: [AstroPy] Some Feedbacks about Astropy In-Reply-To: References: <863181.3954441404220356854.JavaMail.coremail@mailweb> Message-ID: <10502733.118251405135720835.JavaMail.coremail@mailweb> > As for the "matching mode", the idea is that there are a lot of > different "modes" people use, and match_to_catalog_sky (or > match_to_catalog_3d) along with the `nthneighbor` argument should be > flexible enough to take care of most of them. Can you be more > specific about exactly what sort of mode you think is missing? Thanks for your response. In fact, we *often* use one-one match. In the code you give, there might be repetitive elements in 'catalogwithmatches'. For example, for source A in 'catalog' there might be source B & C in 'coordstomatch' that both satisfy the criterion 'd2d < 3*u.arcmin'. In this case, we want to pick up only the nearest one, say if distance A_B < A_C, we only regard A_B as real match. Though only several lines can carry it out, it's so frequently used that I think it should be a part of astropy. best wishes, guang > -----Original email----- > From: "Erik Tollerud" > Sent Time: Jul 12, 2014 5:05:07 AM > To: "Astronomical Python mailing list" > Cc: "Guang Yang" > Subject: Re: [AstroPy] Some Feedbacks about Astropy > > > 2. Though there's astropy.coordinates.matching.match_coordinates_sky to cross-correlate two catalogs, it doesn't allow user to specify matching radius and matching mode (e.g., one-one match). I've made a function to do so, and hope similar function can be included in astropy (https://github.com/Guang91/Astronomers_Tool_Box/blob/master/my_srcor.py). > > The idea is to use it like this (this is astropy 0.4 syntax - for > astropy 0.3 it's similar, but replace SkyCoord with `ICRS` or whatever > class makes sense for your coordinates): > > catalog = SkyCoord(ra_cat*u.deg, dec_cat*u.deg, frame='icrs') > coordstomatch = SkyCoord(ra*u.deg, dec*u.deg, frame='icrs') > > idx, d2d, d3d = coordstomatch.match_to_catalog_sky(catalog) > > coordinateswithmatches = coordstomatch[d2d < 3*u.arcmin] > catalogwithmatches = catalog[idx[d2d < 3*u.arcmin]] > > > As for the "matching mode", the idea is that there are a lot of > different "modes" people use, and match_to_catalog_sky (or > match_to_catalog_3d) along with the `nthneighbor` argument should be > flexible enough to take care of most of them. Can you be more > specific about exactly what sort of mode you think is missing? > > > This was not too thoroughly documented before v0.4 (the version about > to be release), but there's a lot more there in v0.4. See > http://devdocs.astropy.org/coordinates/matchsep.html#matching-catalogs > (that's the developer documentation, but this will become > http://docs.astropy.org/en/stable/coordinates/matchsep.html#matching-catalogs > when 0.4 is released). > > > > -- > Erik T From embray at stsci.edu Mon Jul 14 17:27:13 2014 From: embray at stsci.edu (Erik Bray) Date: Mon, 14 Jul 2014 17:27:13 -0400 Subject: [AstroPy] Astropy in fails to import in Apache mod_wsgi Flask application In-Reply-To: <8198F31F-96FB-43A7-8E2D-56680A1EAC63@caltech.edu> References: <8198F31F-96FB-43A7-8E2D-56680A1EAC63@caltech.edu> Message-ID: <53C44B31.1090209@stsci.edu> On 07/09/2014 04:45 PM, Leo Singer wrote: > Hi, > > I have a Flask application that uses astropy, and I am trying to deploy it in Apache with mod_wsgi. Here's a minimal example app.wsgi file: > > import astropy > > from flask import Flask > app = Flask(__name__) > > @app.route("/") > def hello(): > return "Hello World!" > > application = app > > It fails to import astropy because it cannot locate the Astropy config files. Here's the traceback from the Apache log file, error.log: > > /home/***/***/local/lib/python2.7/site-packages/astropy/config/configuration.py:680: ConfigurationMissingWarning: Configuration defaults will be used due to OSError:Could not find unix home directory to search for astropy config dir > warn(ConfigurationMissingWarning(msg)) > [client ***.***.***.***:*****] mod_wsgi (pid=*****): Target WSGI script '/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi' cannot be loaded as Python module. > [client ***.***.***.***:*****] mod_wsgi (pid=*****): Exception occurred processing WSGI script '/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi'. > [client ***.***.***.***:*****] Traceback (most recent call last): > [client ***.***.***.***:*****] File "/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi", line 4, in > [client ***.***.***.***:*****] import astropy > [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/__init__.py", line 268, in > [client ***.***.***.***:*****] _initialize_astropy() > [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/__init__.py", line 250, in _initialize_astropy > [client ***.***.***.***:*****] config.configuration.update_default_config(__package__, config_dir) > [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/config/configuration.py", line 814, in update_default_config > [client ***.***.***.***:*****] if path.exists(cfgfn): > [client ***.***.***.***:*****] File "/home/***/***/lib/python2.7/genericpath.py", line 18, in exists > [client ***.***.***.***:*****] os.stat(path) > [client ***.***.***.***:*****] TypeError: coercing to Unicode: need string or buffer, NoneType found > > It's running as a user without a home directory. How do I import astropy if I don't have a home directory? Hi Leo, Thanks for the update. This is a known issue (it didn't come up in the context of a web server, though it was quickly realized "oh, this would also be a problem when trying to use Astropy in a web server!"). The issue is fixed in the current v0.4rc2 release candidate and should be fixed in the v0.4 final release as well. If there is a strong need I can release a version of the v0.3.x series that fixes this, but updating to v0.4 should be considered preferable if at all possible. The relevant issue is here: https://github.com/astropy/astropy/pull/2689 Erik (P.S. I think that issues like this--that is, problems that actually result in tracebacks and appear to be bugs in the astropy package itself, are best reported to the astropy issue tracker, rather than this mailing list which is more for general discussion about Astropy + Python in general). From erik.tollerud at gmail.com Wed Jul 16 11:57:29 2014 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 16 Jul 2014 11:57:29 -0400 Subject: [AstroPy] Astropy in fails to import in Apache mod_wsgi Flask application In-Reply-To: <8198F31F-96FB-43A7-8E2D-56680A1EAC63@caltech.edu> References: <8198F31F-96FB-43A7-8E2D-56680A1EAC63@caltech.edu> Message-ID: Is this with the astropy version from master, or one of the releases? I ask because there's a fair amount of activity on the configuration stuff with the implementation of APE3 (https://github.com/astropy/astropy-APEs/blob/master/APE3.rst)... Regardless, I *think* you can get around this by setting the XDG_CONFIG_HOME and XDG_CACHE_HOME environment variables, and adding 'astropy' directories to them. That should get around the code that tries to find home. But this should work (that's why it's "ConfigurationMissingWarning" and not "ConfigurationMissingError"), so if you're on master and it's still not working, can you report it as an issue? On Wed, Jul 9, 2014 at 4:45 PM, Leo Singer wrote: > Hi, > > I have a Flask application that uses astropy, and I am trying to deploy it in Apache with mod_wsgi. Here's a minimal example app.wsgi file: > > import astropy > > from flask import Flask > app = Flask(__name__) > > @app.route("/") > def hello(): > return "Hello World!" > > application = app > > It fails to import astropy because it cannot locate the Astropy config files. Here's the traceback from the Apache log file, error.log: > > /home/***/***/local/lib/python2.7/site-packages/astropy/config/configuration.py:680: ConfigurationMissingWarning: Configuration defaults will be used due to OSError:Could not find unix home directory to search for astropy config dir > warn(ConfigurationMissingWarning(msg)) > [client ***.***.***.***:*****] mod_wsgi (pid=*****): Target WSGI script '/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi' cannot be loaded as Python module. > [client ***.***.***.***:*****] mod_wsgi (pid=*****): Exception occurred processing WSGI script '/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi'. > [client ***.***.***.***:*****] Traceback (most recent call last): > [client ***.***.***.***:*****] File "/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi", line 4, in > [client ***.***.***.***:*****] import astropy > [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/__init__.py", line 268, in > [client ***.***.***.***:*****] _initialize_astropy() > [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/__init__.py", line 250, in _initialize_astropy > [client ***.***.***.***:*****] config.configuration.update_default_config(__package__, config_dir) > [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/config/configuration.py", line 814, in update_default_config > [client ***.***.***.***:*****] if path.exists(cfgfn): > [client ***.***.***.***:*****] File "/home/***/***/lib/python2.7/genericpath.py", line 18, in exists > [client ***.***.***.***:*****] os.stat(path) > [client ***.***.***.***:*****] TypeError: coercing to Unicode: need string or buffer, NoneType found > > It's running as a user without a home directory. How do I import astropy if I don't have a home directory? > > Thanks, > Leo > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Erik T From lsinger at caltech.edu Wed Jul 16 18:40:43 2014 From: lsinger at caltech.edu (Leo Singer) Date: Wed, 16 Jul 2014 15:40:43 -0700 Subject: [AstroPy] Astropy in fails to import in Apache mod_wsgi Flask application In-Reply-To: References: <8198F31F-96FB-43A7-8E2D-56680A1EAC63@caltech.edu> Message-ID: <3AB03F99-72D1-40D5-80EE-5A15D2A87923@caltech.edu> Hi Erik, Thank you for the reply. I got it to work, but unfortunately I don't have a clear idea how. I did have to eventually set WSGIApplicationGroup %{GLOBAL} as described in: https://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API in order to prevent the application from hanging when I imported Numpy. This is the config section that worked: ServerName example.edu # Send diagnostic messages to default Apache log files ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined # Run WSGI workers as user 'theuser' and group 'thegroup' WSGIDaemonProcess theapp user=theuser group=thegroup threads=5 display-name=%{GROUP} WSGIScriptAlias / /path/to/script.wsgi WSGIProcessGroup theapp WSGIApplicationGroup %{GLOBAL} # Within this host, only permit access to # /path/to Require all granted Looks pretty opaque, doesn't it? No wonder there are so many pure-Python deployment options for WSGI apps. Best, Leo On Jul 16, 2014, at 8:57 AM, Erik Tollerud wrote: > Is this with the astropy version from master, or one of the releases? > I ask because there's a fair amount of activity on the configuration > stuff with the implementation of APE3 > (https://github.com/astropy/astropy-APEs/blob/master/APE3.rst)... > > Regardless, I *think* you can get around this by setting the > XDG_CONFIG_HOME and XDG_CACHE_HOME environment variables, and adding > 'astropy' directories to them. That should get around the code that > tries to find home. > > But this should work (that's why it's "ConfigurationMissingWarning" > and not "ConfigurationMissingError"), so if you're on master and it's > still not working, can you report it as an issue? > > > On Wed, Jul 9, 2014 at 4:45 PM, Leo Singer wrote: >> Hi, >> >> I have a Flask application that uses astropy, and I am trying to deploy it in Apache with mod_wsgi. Here's a minimal example app.wsgi file: >> >> import astropy >> >> from flask import Flask >> app = Flask(__name__) >> >> @app.route("/") >> def hello(): >> return "Hello World!" >> >> application = app >> >> It fails to import astropy because it cannot locate the Astropy config files. Here's the traceback from the Apache log file, error.log: >> >> /home/***/***/local/lib/python2.7/site-packages/astropy/config/configuration.py:680: ConfigurationMissingWarning: Configuration defaults will be used due to OSError:Could not find unix home directory to search for astropy config dir >> warn(ConfigurationMissingWarning(msg)) >> [client ***.***.***.***:*****] mod_wsgi (pid=*****): Target WSGI script '/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi' cannot be loaded as Python module. >> [client ***.***.***.***:*****] mod_wsgi (pid=*****): Exception occurred processing WSGI script '/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi'. >> [client ***.***.***.***:*****] Traceback (most recent call last): >> [client ***.***.***.***:*****] File "/home/***/***/var/ptf-instance/wsgi/ptftoo.wsgi", line 4, in >> [client ***.***.***.***:*****] import astropy >> [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/__init__.py", line 268, in >> [client ***.***.***.***:*****] _initialize_astropy() >> [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/__init__.py", line 250, in _initialize_astropy >> [client ***.***.***.***:*****] config.configuration.update_default_config(__package__, config_dir) >> [client ***.***.***.***:*****] File "/home/***/***/local/lib/python2.7/site-packages/astropy/config/configuration.py", line 814, in update_default_config >> [client ***.***.***.***:*****] if path.exists(cfgfn): >> [client ***.***.***.***:*****] File "/home/***/***/lib/python2.7/genericpath.py", line 18, in exists >> [client ***.***.***.***:*****] os.stat(path) >> [client ***.***.***.***:*****] TypeError: coercing to Unicode: need string or buffer, NoneType found >> >> It's running as a user without a home directory. How do I import astropy if I don't have a home directory? >> >> Thanks, >> Leo >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > > > > -- > Erik T From erik.tollerud at gmail.com Thu Jul 17 09:36:11 2014 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Thu, 17 Jul 2014 09:36:11 -0400 Subject: [AstroPy] ANN: Astropy v0.4 released Message-ID: Hello, We are very happy to announce the third major public release (v0.4) of the astropy package, a core Python package for Astronomy: http://www.astropy.org Astropy is a community-driven package intended to contain much of the core functionality and common tools needed for performing astronomy and astrophysics with Python. New and improved major functionality in this release includes: * A new astropy.vo.samp sub-package adapted from the previously standalone SAMPy package * A re-designed astropy.coordinates sub-package for celestial coordinates * A new ?fitsheader? command-line tool that can be used to quickly inspect FITS headers * A new HTML table reader/writer * Improved performance for Quantity objects * A re-designed configuration framework In addition, hundreds of smaller improvements and fixes have been made. An overview of the changes is provided at: http://docs.astropy.org/en/latest/whatsnew/0.4.html Instructions for installing Astropy are provided at the http://www.astropy.org website, and extensive documentation can be found at: http://docs.astropy.org In particular, if you use Anaconda, you can update to v0.4 with: conda update astropy Please report any issues, or request new features via our GitHub repository: https://github.com/astropy/astropy/issues Over 80 developers have contributed code to Astropy so far, and you can find out more about the team behind Astropy here: http://www.astropy.org/team.html If you use Astropy directly - or as a dependency to another package - for your work, please remember to include the following acknowledgment at the end of papers: "This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration, 2013)." where ?(Astropy Collaboration, 2013)? is the Astropy paper which was published last year: http://adsabs.harvard.edu/abs/2013A%26A...558A..33A Please feel free to forward this announcement to anyone you think might be interested in this release. We hope that you enjoy using Astropy as much as we enjoyed developing it! Thomas Robitaille, Erik Tollerud, and Perry Greenfield on behalf of The Astropy Collaboration From emmanuel.caux at irap.omp.eu Thu Jul 17 12:01:51 2014 From: emmanuel.caux at irap.omp.eu (Emmanuel Caux) Date: Thu, 17 Jul 2014 18:01:51 +0200 Subject: [AstroPy] ANN: Astropy v0.4 released In-Reply-To: References: Message-ID: <5633A8AF-2D08-4034-95FD-7467A8D219C5@irap.omp.eu> Hi Erik, Many thanks for that, just a question, I install software on my Mac with Fink and I have currently installed : [Emmanuels-MacBook-Pro:~] caux% fink list astropy Information about 10660 packages read in 1 seconds. i astropy-py27 0.3-2 Python library for Astronomy astropy-py32 0.3-2 Python library for Astronomy astropy-py33 0.3-2 Python library for Astronomy But if I run fink update-all or fink update astropy-py27, I have this answer : [Emmanuels-MacBook-Pro:~] caux% fink update astropy-py27 Information about 10660 packages read in 1 seconds. No packages to install. Does that mean I hane to remove my install of atsropy 0.3 and install the new astropy 0.4 ? Many thanks, Cheers, !! PLEASE NOTE MY NEW EMAIL ADDRESS !! -------------------------------------------------------------- Emmanuel Caux, emmanuel.caux at irap.omp.eu DR2 CNRS - Departement MICMAC Institut de Recherche en Astrophysique et Plan?tologie (IRAP formerly CESR) BP 44346, 31028 Toulouse Cedex 4, France Phone : (+33) 561 556 689 Fax : (+33) 561 556 651 -------------------------------------------------------------- On Jul 17, 2014, at 3:36 PM, Erik Tollerud wrote: > Hello, > > We are very happy to announce the third major public release (v0.4) of > the astropy package, a core Python package for Astronomy: > > http://www.astropy.org > > > Astropy is a community-driven package intended to contain much of the > core functionality and common tools needed for performing astronomy > and astrophysics with Python. > > New and improved major functionality in this release includes: > > * A new astropy.vo.samp sub-package adapted from the previously > standalone SAMPy package > * A re-designed astropy.coordinates sub-package for celestial coordinates > * A new ?fitsheader? command-line tool that can be used to quickly > inspect FITS headers > * A new HTML table reader/writer > * Improved performance for Quantity objects > * A re-designed configuration framework > > In addition, hundreds of smaller improvements and fixes have been > made. An overview of the changes is provided at: > > http://docs.astropy.org/en/latest/whatsnew/0.4.html > > > Instructions for installing Astropy are provided at the > http://www.astropy.org website, and extensive documentation can be > found at: > > http://docs.astropy.org > > In particular, if you use Anaconda, you can update to v0.4 with: > > conda update astropy > > > Please report any issues, or request new features via our GitHub repository: > > https://github.com/astropy/astropy/issues > > > Over 80 developers have contributed code to Astropy so far, and you > can find out more about the team behind Astropy here: > > http://www.astropy.org/team.html > > > If you use Astropy directly - or as a dependency to another package - > for your work, please remember to include the following acknowledgment > at the end of papers: > > "This research made use of Astropy, a community-developed core Python > package for Astronomy (Astropy Collaboration, 2013)." > > where ?(Astropy Collaboration, 2013)? is the Astropy paper which was > published last year: > > http://adsabs.harvard.edu/abs/2013A%26A...558A..33A > > > Please feel free to forward this announcement to anyone you think > might be interested in this release. > > > We hope that you enjoy using Astropy as much as we enjoyed developing it! > > > Thomas Robitaille, Erik Tollerud, and Perry Greenfield > on behalf of The Astropy Collaboration > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From embray at stsci.edu Thu Jul 17 15:17:23 2014 From: embray at stsci.edu (Erik Bray) Date: Thu, 17 Jul 2014 15:17:23 -0400 Subject: [AstroPy] [ANN] PyFITS v3.3.0 released Message-ID: <53C82143.1030200@stsci.edu> It is my pleasure to announce the release of PyFITS version 3.3.0. PyFITS is a Python package for reading FITS format images and tables and manipulating their associated data and headers. The new version can be download from PyPI at: https://pypi.python.org/pypi/pyfits/3.3 The latest documentation can be found at: https://pythonhosted.org/pyfits/ This is a relatively minor release in terms of new features, and was released today mostly to keep the PyFITS release in sync with today's release of Astropy v0.4. However, there are some important notices that accompany this release: * The v3.3.x release series for PyFITS will be the *last* to support Python 2.5, 3.1, and 3.2. PyFITS v3.4 will only support Python 2.6, Python 2.7, and Python >= 3.3, in keeping with the Astropy project and much of the rest of the Python community. * PyFITS v3.3.x releases will be the last to support several APIs that have been deprecated since v3.1. Some of the most common include Header.ascard and Card.key. Also, deletion of non-existent header keywords (e.g. del header['NONEXIST']) will raise a KeyError (just like a Python dict would) rather than pass silently. Changes such as these are in order to reduce the burden of maintaining old code, while giving users enough time to adjust their use of that code as necessary. For a full list of API changes see the changelog: https://pythonhosted.org/pyfits/appendix/changelog.html#api-changes * As is the case in Astropy, warnings for use of deprecated APIs are enabled by default. This is mostly for the sake of developers using PyFITS. For user-facing software that uses PyFITS internally it may be desirable to disable these warnings. To that end a shortcut that can be called after importing pyfits is provided: pyfits.ignore_deprecation_warnings() * Finally, the v3.3.x release series will be the last to include binary .exe installers for Windows distributions. PyFITS v3.4 and above will only provide wheel [1] distributions for Python--these are considered the new community standard for binary distributions of Python projects. You can contact me at with any questions or comments. Thank you to everyone who submitted bug reports and fixes. Erik Bray [1] http://wheel.readthedocs.org/en/latest/ From ga.braganca at gmail.com Thu Jul 17 15:34:22 2014 From: ga.braganca at gmail.com (=?UTF-8?Q?Gustavo_Bragan=C3=A7a?=) Date: Thu, 17 Jul 2014 12:34:22 -0700 (PDT) Subject: [AstroPy] ANN: Astropy v0.4 released In-Reply-To: References: Message-ID: <8e6db3dd-12a8-4d28-961c-6b4ad823cef2@googlegroups.com> Hi, That is very good news. Congratulations to all. I just want to make a note that I get a 404 when I try to access http://www.astropy.org/team.html. I guess it should lead to the bottom of this page (http://www.astropy.org/about.html#acknowledge) Should I open a issue? Cheers, Gustavo Em quinta-feira, 17 de julho de 2014 15h36min33s UTC+2, Erik Tollerud escreveu: > > Hello, > > We are very happy to announce the third major public release (v0.4) of > the astropy package, a core Python package for Astronomy: > > http://www.astropy.org > > > Astropy is a community-driven package intended to contain much of the > core functionality and common tools needed for performing astronomy > and astrophysics with Python. > > New and improved major functionality in this release includes: > > * A new astropy.vo.samp sub-package adapted from the previously > standalone SAMPy package > * A re-designed astropy.coordinates sub-package for celestial coordinates > * A new ?fitsheader? command-line tool that can be used to quickly > inspect FITS headers > * A new HTML table reader/writer > * Improved performance for Quantity objects > * A re-designed configuration framework > > In addition, hundreds of smaller improvements and fixes have been > made. An overview of the changes is provided at: > > http://docs.astropy.org/en/latest/whatsnew/0.4.html > > > Instructions for installing Astropy are provided at the > http://www.astropy.org website, and extensive documentation can be > found at: > > http://docs.astropy.org > > In particular, if you use Anaconda, you can update to v0.4 with: > > conda update astropy > > > Please report any issues, or request new features via our GitHub > repository: > > https://github.com/astropy/astropy/issues > > > Over 80 developers have contributed code to Astropy so far, and you > can find out more about the team behind Astropy here: > > http://www.astropy.org/team.html > > > If you use Astropy directly - or as a dependency to another package - > for your work, please remember to include the following acknowledgment > at the end of papers: > > "This research made use of Astropy, a community-developed core Python > package for Astronomy (Astropy Collaboration, 2013)." > > where ?(Astropy Collaboration, 2013)? is the Astropy paper which was > published last year: > > http://adsabs.harvard.edu/abs/2013A%26A...558A..33A > > > Please feel free to forward this announcement to anyone you think > might be interested in this release. > > > We hope that you enjoy using Astropy as much as we enjoyed developing it! > > > Thomas Robitaille, Erik Tollerud, and Perry Greenfield > on behalf of The Astropy Collaboration > -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek at astro.physik.uni-goettingen.de Thu Jul 17 14:16:17 2014 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Thu, 17 Jul 2014 20:16:17 +0200 Subject: [AstroPy] ANN: Astropy v0.4 released In-Reply-To: <5633A8AF-2D08-4034-95FD-7467A8D219C5@irap.omp.eu> References: <5633A8AF-2D08-4034-95FD-7467A8D219C5@irap.omp.eu> Message-ID: On 17 Jul 2014, at 06:01 pm, Emmanuel Caux wrote: > Many thanks for that, just a question, I install software on my Mac with Fink and I have currently installed : > > [Emmanuels-MacBook-Pro:~] caux% fink list astropy > Information about 10660 packages read in 1 seconds. > i astropy-py27 0.3-2 Python library for Astronomy > astropy-py32 0.3-2 Python library for Astronomy > astropy-py33 0.3-2 Python library for Astronomy > > But if I run fink update-all or fink update astropy-py27, I have this answer : > > [Emmanuels-MacBook-Pro:~] caux% fink update astropy-py27 > Information about 10660 packages read in 1 seconds. > No packages to install. > > Does that mean I hane to remove my install of atsropy 0.3 and install the new astropy 0.4 ? > Umm, maintainers are certainly doing their best, but I think miracles are only performed on prior request ;-) Even if their spare time (because that?s what it is) had allowed to get the update into fink in the 2 ? hours after it has been announced, it?s extremely unlikely that even the Fink mirrors had been synchronised this quicky! I had a look at the new release and actually ran into a problem right away building it on OS X 10.9: File "/scratch.noindex/fink.build/astropy-py34-0.4-1/astropy-0.4/ah_bootstrap.py", line 435, in _check_submodule_using_git stderr = stderr.decode(stdio_encoding) TypeError: decode() argument 1 must be str, not None This is because locale.getdefaultlocale() returns (None, None) if LC_CTYPE is not set, which happens to be the case in my default environment because Terminal for some reason only presets it to the useless value ?UTF-8?. But the Fink build environment is independent from the user?s settings anyway and should be. So I could resolve this by explicitly setting LC_CTYPE in the build script, but maybe this is a matter to think about upstream if the build could/should be supported without this setting (or if set to something like ?C?!). Then I came upon another problem when trying to build the py32 and py33 versions: #!/bin/bash -ev export LC_CTYPE=en_US.ISO8859-1 /sw/bin/python3.3 setup.py build --use-system-cfitsio --use-system-expat Traceback (most recent call last): File "setup.py", line 8, in import ah_bootstrap File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 716, in _main() File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 713, in _main use_astropy_helpers(**kwargs) File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 245, in use_astropy_helpers upgrade = _do_upgrade(dist, index_url) File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 341, in _do_upgrade package_index = PackageIndex(index_url=index_url) File "/sw/lib/python3.3/site-packages/setuptools/package_index.py", line 269, in __init__ Environment.__init__(self,*args,**kw) File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 799, in __init__ self.scan(search_path) File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 829, in scan self.add(dist) File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 849, in add dists.sort(key=operator.attrgetter('hashcmp'), reverse=True) TypeError: unorderable types: str() < NoneType() Strangely this succeeds when building it myself, so I suspect it must have to do with some other environment variable that by default is not set for the Fink package build user, but I?ve no idea where to look at right now. So I?ve uploaded an updated info file just for the 2.7 and 3.4 versions to https://sourceforge.net/p/fink/package-submissions/4396/ (this is the new .info file at the bottom - or should I better open a new ticket for this?) If you feel like becoming an early adopter and want to give this a try, you only need to install the file into your local fink tree and fink update astropy-py27 should get you ready for testing. But please report any problems first to me and not only to Sebastien! Cheers, Derek From thomas.robitaille at gmail.com Fri Jul 18 05:42:36 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Fri, 18 Jul 2014 11:42:36 +0200 Subject: [AstroPy] ANN: Astropy v0.4 released In-Reply-To: References: <5633A8AF-2D08-4034-95FD-7467A8D219C5@irap.omp.eu> Message-ID: <53C8EC0C.4000205@gmail.com> Hi Derek, Derek Homeier wrote: > On 17 Jul 2014, at 06:01 pm, Emmanuel Caux wrote: > >> Many thanks for that, just a question, I install software on my Mac with Fink and I have currently installed : >> >> [Emmanuels-MacBook-Pro:~] caux% fink list astropy >> Information about 10660 packages read in 1 seconds. >> i astropy-py27 0.3-2 Python library for Astronomy >> astropy-py32 0.3-2 Python library for Astronomy >> astropy-py33 0.3-2 Python library for Astronomy >> >> But if I run fink update-all or fink update astropy-py27, I have this answer : >> >> [Emmanuels-MacBook-Pro:~] caux% fink update astropy-py27 >> Information about 10660 packages read in 1 seconds. >> No packages to install. >> >> Does that mean I hane to remove my install of atsropy 0.3 and install the new astropy 0.4 ? >> > Umm, maintainers are certainly doing their best, but I think miracles are only performed on prior request ;-) > Even if their spare time (because that?s what it is) had allowed to get the update into fink in the 2 ? hours > after it has been announced, it?s extremely unlikely that even the Fink mirrors had been synchronised this > quicky! > I had a look at the new release and actually ran into a problem right away building it on OS X 10.9: > File "/scratch.noindex/fink.build/astropy-py34-0.4-1/astropy-0.4/ah_bootstrap.py", line 435, in _check_submodule_using_git > stderr = stderr.decode(stdio_encoding) > TypeError: decode() argument 1 must be str, not None We've got a known issue for the issue of incorrectly set environment variables (such as in the MacOS X terminal): http://docs.astropy.org/en/stable/known_issues.html#utf-8-locale-error-on-macos-x I've now opened a pull request to add other errors such as the one above which are due to the same issue: https://github.com/astropy/astropy/pull/2760 Erik B. has also been working on a workaround that will try and get around issues of misconfigured locale variables. In the mean time, it makes sense to set these correctly as shown in the 'known issue' above, since this is an error that can occur with other packages, not just astropy. I hope this helps. Cheers, Tom > > This is because locale.getdefaultlocale() returns (None, None) if LC_CTYPE is not set, which happens to > be the case in my default environment because Terminal for some reason only presets it to the useless > value ?UTF-8?. But the Fink build environment is independent from the user?s settings anyway and should be. > So I could resolve this by explicitly setting LC_CTYPE in the build script, but maybe this is a matter to think > about upstream if the build could/should be supported without this setting (or if set to something like ?C?!). > > Then I came upon another problem when trying to build the py32 and py33 versions: > > #!/bin/bash -ev > export LC_CTYPE=en_US.ISO8859-1 > /sw/bin/python3.3 setup.py build --use-system-cfitsio --use-system-expat > Traceback (most recent call last): > File "setup.py", line 8, in > import ah_bootstrap > File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 716, in > _main() > File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 713, in _main > use_astropy_helpers(**kwargs) > File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 245, in use_astropy_helpers > upgrade = _do_upgrade(dist, index_url) > File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 341, in _do_upgrade > package_index = PackageIndex(index_url=index_url) > File "/sw/lib/python3.3/site-packages/setuptools/package_index.py", line 269, in __init__ > Environment.__init__(self,*args,**kw) > File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 799, in __init__ > self.scan(search_path) > File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 829, in scan > self.add(dist) > File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 849, in add > dists.sort(key=operator.attrgetter('hashcmp'), reverse=True) > TypeError: unorderable types: str() < NoneType() > > Strangely this succeeds when building it myself, so I suspect it must have to do with some other environment > variable that by default is not set for the Fink package build user, but I?ve no idea where to look at right now. > So I?ve uploaded an updated info file just for the 2.7 and 3.4 versions to > https://sourceforge.net/p/fink/package-submissions/4396/ > > (this is the new .info file at the bottom - or should I better open a new ticket for this?) > > If you feel like becoming an early adopter and want to give this a try, you only need to install the file into your > local fink tree and fink update astropy-py27 should get you ready for testing. > But please report any problems first to me and not only to Sebastien! > > Cheers, > Derek > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From derek at astro.physik.uni-goettingen.de Fri Jul 18 09:33:59 2014 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Fri, 18 Jul 2014 15:33:59 +0200 Subject: [AstroPy] ANN: Astropy v0.4 released In-Reply-To: <53C8EC0C.4000205@gmail.com> References: <5633A8AF-2D08-4034-95FD-7467A8D219C5@irap.omp.eu> <53C8EC0C.4000205@gmail.com> Message-ID: <3F57B110-5239-4654-90DA-618B7C208C77@astro.physik.uni-goettingen.de> Hi Thomas, >> I had a look at the new release and actually ran into a problem right away building it on OS X 10.9: >> File "/scratch.noindex/fink.build/astropy-py34-0.4-1/astropy-0.4/ah_bootstrap.py", line 435, in _check_submodule_using_git >> stderr = stderr.decode(stdio_encoding) >> TypeError: decode() argument 1 must be str, not None > > We've got a known issue for the issue of incorrectly set environment > variables (such as in the MacOS X terminal): > > > http://docs.astropy.org/en/stable/known_issues.html#utf-8-locale-error-on-macos-x > > I've now opened a pull request to add other errors such as the one above > which are due to the same issue: > > https://github.com/astropy/astropy/pull/2760 > > Erik B. has also been working on a workaround that will try and get > around issues of misconfigured locale variables. In the mean time, it > makes sense to set these correctly as shown in the 'known issue' above, > since this is an error that can occur with other packages, not just astropy. > thanks indeed, confirms more or less my suspicions. However in the case of the Fink build it was not the mangled LC_CTYPE from Terminal, but having no locale settings at all, i.e. locale.getdefaultlocale() returning (None, None) rather than ValueError. Forwarded this to the Fink developers? list, but I think LC_* and LANG being all unset should be something the setup ought to be able to handle, so this might remain just a temporary fix for astropy. I could track the Python3.2/Python3.3 issues >> >> File "setup.py", line 8, in >> import ah_bootstrap >> File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 716, in >> _main() >> File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 713, in _main >> use_astropy_helpers(**kwargs) >> File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 245, in use_astropy_helpers >> upgrade = _do_upgrade(dist, index_url) >> File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 341, in _do_upgrade >> package_index = PackageIndex(index_url=index_url) >> File "/sw/lib/python3.3/site-packages/setuptools/package_index.py", line 269, in __init__ >> Environment.__init__(self,*args,**kw) >> File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 799, in __init__ >> self.scan(search_path) >> File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 829, in scan >> self.add(dist) >> File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 849, in add >> dists.sort(key=operator.attrgetter('hashcmp'), reverse=True) >> TypeError: unorderable types: str() < NoneType() down to a seemingly broken PackageIndex in their their setuptools.package_index, which always raises the above error whether you pass it a valid URL or nothing at all, but it?s apparently a bit non-deterministic if the _do_upgrade is called - or it generally is when building from the tar ball, but not from the git repo. I could solve this by adding auto_upgrade = False to setup.cfg. Can you think of any objections against this solution (generally I think we don?t want any automatic downloads etc. within a package build)? Cheers, Derek From avarlotta at cfa.harvard.edu Fri Jul 18 12:02:15 2014 From: avarlotta at cfa.harvard.edu (Angelo Varlotta) Date: Fri, 18 Jul 2014 12:02:15 -0400 Subject: [AstroPy] ANN: Astropy v0.4 released In-Reply-To: References: Message-ID: <53C94507.90300@cfa.harvard.edu> Hello, >From the User Documentation page I've noticed that the pdf version of the docs just produces this 1-page output: https://media.readthedocs.org/pdf/astropy/stable/astropy.pdf The other docs (html and epub) seem to be fine. Cheers, Angelo Erik Tollerud wrote: > Hello, > > We are very happy to announce the third major public release (v0.4) of > the astropy package, a core Python package for Astronomy: > > http://www.astropy.org > > Astropy is a community-driven package intended to contain much of the > core functionality and common tools needed for performing astronomy > and astrophysics with Python. > > New and improved major functionality in this release includes: > > * A new astropy.vo.samp sub-package adapted from the previously > standalone SAMPy package > * A re-designed astropy.coordinates sub-package for celestial coordinates > * A new ?fitsheader? command-line tool that can be used to quickly > inspect FITS headers > * A new HTML table reader/writer > * Improved performance for Quantity objects > * A re-designed configuration framework > > In addition, hundreds of smaller improvements and fixes have been > made. An overview of the changes is provided at: > > http://docs.astropy.org/en/latest/whatsnew/0.4.html > > > Instructions for installing Astropy are provided at the > http://www.astropy.org website, and extensive documentation can be > found at: > > http://docs.astropy.org > > In particular, if you use Anaconda, you can update to v0.4 with: > > conda update astropy > > > Please report any issues, or request new features via our GitHub repository: > > https://github.com/astropy/astropy/issues > > > Over 80 developers have contributed code to Astropy so far, and you > can find out more about the team behind Astropy here: > > http://www.astropy.org/team.html > > > If you use Astropy directly - or as a dependency to another package - > for your work, please remember to include the following acknowledgment > at the end of papers: > > "This research made use of Astropy, a community-developed core Python > package for Astronomy (Astropy Collaboration, 2013)." > > where ?(Astropy Collaboration, 2013)? is the Astropy paper which was > published last year: > > http://adsabs.harvard.edu/abs/2013A%26A...558A..33A > > > Please feel free to forward this announcement to anyone you think > might be interested in this release. > > > We hope that you enjoy using Astropy as much as we enjoyed developing it! > > > Thomas Robitaille, Erik Tollerud, and Perry Greenfield > on behalf of The Astropy Collaboration > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Fri Jul 18 12:23:23 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Fri, 18 Jul 2014 12:23:23 -0400 Subject: [AstroPy] ANN: Astropy v0.4 released In-Reply-To: <53C94507.90300@cfa.harvard.edu> References: <53C94507.90300@cfa.harvard.edu> Message-ID: <53C949FB.8090602@stsci.edu> Indeed. I'm looking into the cause. Cheers, Mike On 07/18/2014 12:02 PM, Angelo Varlotta wrote: > Hello, > From the User Documentation page I've noticed that the pdf version of > the docs just produces this 1-page output: > > https://media.readthedocs.org/pdf/astropy/stable/astropy.pdf > > The other docs (html and epub) seem to be fine. > > Cheers, > Angelo > > Erik Tollerud wrote: >> Hello, >> >> We are very happy to announce the third major public release (v0.4) of >> the astropy package, a core Python package for Astronomy: >> >> http://www.astropy.org >> >> Astropy is a community-driven package intended to contain much of the >> core functionality and common tools needed for performing astronomy >> and astrophysics with Python. >> >> New and improved major functionality in this release includes: >> >> * A new astropy.vo.samp sub-package adapted from the previously >> standalone SAMPy package >> * A re-designed astropy.coordinates sub-package for celestial coordinates >> * A new 'fitsheader' command-line tool that can be used to quickly >> inspect FITS headers >> * A new HTML table reader/writer >> * Improved performance for Quantity objects >> * A re-designed configuration framework >> >> In addition, hundreds of smaller improvements and fixes have been >> made. An overview of the changes is provided at: >> >> http://docs.astropy.org/en/latest/whatsnew/0.4.html >> >> >> Instructions for installing Astropy are provided at the >> http://www.astropy.org website, and extensive documentation can be >> found at: >> >> http://docs.astropy.org >> >> In particular, if you use Anaconda, you can update to v0.4 with: >> >> conda update astropy >> >> >> Please report any issues, or request new features via our GitHub repository: >> >> https://github.com/astropy/astropy/issues >> >> >> Over 80 developers have contributed code to Astropy so far, and you >> can find out more about the team behind Astropy here: >> >> http://www.astropy.org/team.html >> >> >> If you use Astropy directly - or as a dependency to another package - >> for your work, please remember to include the following acknowledgment >> at the end of papers: >> >> "This research made use of Astropy, a community-developed core Python >> package for Astronomy (Astropy Collaboration, 2013)." >> >> where "(Astropy Collaboration, 2013)" is the Astropy paper which was >> published last year: >> >> http://adsabs.harvard.edu/abs/2013A%26A...558A..33A >> >> >> Please feel free to forward this announcement to anyone you think >> might be interested in this release. >> >> >> We hope that you enjoy using Astropy as much as we enjoyed developing it! >> >> >> Thomas Robitaille, Erik Tollerud, and Perry Greenfield >> on behalf of The Astropy Collaboration >> _______________________________________________ >> 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 -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Fri Jul 18 12:37:19 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Fri, 18 Jul 2014 12:37:19 -0400 Subject: [AstroPy] ANN: Astropy v0.4 released In-Reply-To: <53C949FB.8090602@stsci.edu> References: <53C94507.90300@cfa.harvard.edu> <53C949FB.8090602@stsci.edu> Message-ID: <53C94D3F.7080700@stsci.edu> I've created a pull request with a fix here: https://github.com/astropy/astropy/pull/2764 Mike On 07/18/2014 12:23 PM, Michael Droettboom wrote: > Indeed. I'm looking into the cause. > > Cheers, > Mike > > On 07/18/2014 12:02 PM, Angelo Varlotta wrote: >> Hello, >> From the User Documentation page I've noticed that the pdf version of >> the docs just produces this 1-page output: >> >> https://media.readthedocs.org/pdf/astropy/stable/astropy.pdf >> >> The other docs (html and epub) seem to be fine. >> >> Cheers, >> Angelo >> >> Erik Tollerud wrote: >>> Hello, >>> >>> We are very happy to announce the third major public release (v0.4) of >>> the astropy package, a core Python package for Astronomy: >>> >>> http://www.astropy.org >>> >>> Astropy is a community-driven package intended to contain much of the >>> core functionality and common tools needed for performing astronomy >>> and astrophysics with Python. >>> >>> New and improved major functionality in this release includes: >>> >>> * A new astropy.vo.samp sub-package adapted from the previously >>> standalone SAMPy package >>> * A re-designed astropy.coordinates sub-package for celestial coordinates >>> * A new 'fitsheader' command-line tool that can be used to quickly >>> inspect FITS headers >>> * A new HTML table reader/writer >>> * Improved performance for Quantity objects >>> * A re-designed configuration framework >>> >>> In addition, hundreds of smaller improvements and fixes have been >>> made. An overview of the changes is provided at: >>> >>> http://docs.astropy.org/en/latest/whatsnew/0.4.html >>> >>> >>> Instructions for installing Astropy are provided at the >>> http://www.astropy.org website, and extensive documentation can be >>> found at: >>> >>> http://docs.astropy.org >>> >>> In particular, if you use Anaconda, you can update to v0.4 with: >>> >>> conda update astropy >>> >>> >>> Please report any issues, or request new features via our GitHub repository: >>> >>> https://github.com/astropy/astropy/issues >>> >>> >>> Over 80 developers have contributed code to Astropy so far, and you >>> can find out more about the team behind Astropy here: >>> >>> http://www.astropy.org/team.html >>> >>> >>> If you use Astropy directly - or as a dependency to another package - >>> for your work, please remember to include the following acknowledgment >>> at the end of papers: >>> >>> "This research made use of Astropy, a community-developed core Python >>> package for Astronomy (Astropy Collaboration, 2013)." >>> >>> where "(Astropy Collaboration, 2013)" is the Astropy paper which was >>> published last year: >>> >>> http://adsabs.harvard.edu/abs/2013A%26A...558A..33A >>> >>> >>> Please feel free to forward this announcement to anyone you think >>> might be interested in this release. >>> >>> >>> We hope that you enjoy using Astropy as much as we enjoyed developing it! >>> >>> >>> Thomas Robitaille, Erik Tollerud, and Perry Greenfield >>> on behalf of The Astropy Collaboration >>> _______________________________________________ >>> 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 > > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > > http://www.droettboom.com > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From embray at stsci.edu Fri Jul 18 17:42:17 2014 From: embray at stsci.edu (Erik Bray) Date: Fri, 18 Jul 2014 17:42:17 -0400 Subject: [AstroPy] ANN: Astropy v0.4 released In-Reply-To: <3F57B110-5239-4654-90DA-618B7C208C77@astro.physik.uni-goettingen.de> References: <5633A8AF-2D08-4034-95FD-7467A8D219C5@irap.omp.eu> <53C8EC0C.4000205@gmail.com> <3F57B110-5239-4654-90DA-618B7C208C77@astro.physik.uni-goettingen.de> Message-ID: <53C994B9.8070209@stsci.edu> On 07/18/2014 09:33 AM, Derek Homeier wrote: > Hi Thomas, > >>> I had a look at the new release and actually ran into a problem right away building it on OS X 10.9: >>> File "/scratch.noindex/fink.build/astropy-py34-0.4-1/astropy-0.4/ah_bootstrap.py", line 435, in _check_submodule_using_git >>> stderr = stderr.decode(stdio_encoding) >>> TypeError: decode() argument 1 must be str, not None >> >> We've got a known issue for the issue of incorrectly set environment >> variables (such as in the MacOS X terminal): >> >> >> http://docs.astropy.org/en/stable/known_issues.html#utf-8-locale-error-on-macos-x >> >> I've now opened a pull request to add other errors such as the one above >> which are due to the same issue: >> >> https://github.com/astropy/astropy/pull/2760 >> >> Erik B. has also been working on a workaround that will try and get >> around issues of misconfigured locale variables. In the mean time, it >> makes sense to set these correctly as shown in the 'known issue' above, >> since this is an error that can occur with other packages, not just astropy. >> > thanks indeed, confirms more or less my suspicions. > However in the case of the Fink build it was not the mangled LC_CTYPE from Terminal, but having no locale > settings at all, i.e. locale.getdefaultlocale() returning (None, None) rather than ValueError. > Forwarded this to the Fink developers? list, but I think LC_* and LANG being all unset should be something > the setup ought to be able to handle, so this might remain just a temporary fix for astropy. > > I could track the Python3.2/Python3.3 issues >>> >>> File "setup.py", line 8, in >>> import ah_bootstrap >>> File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 716, in >>> _main() >>> File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 713, in _main >>> use_astropy_helpers(**kwargs) >>> File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 245, in use_astropy_helpers >>> upgrade = _do_upgrade(dist, index_url) >>> File "/scratch.noindex/fink.build/astropy-py33-0.4-1/astropy-0.4/ah_bootstrap.py", line 341, in _do_upgrade >>> package_index = PackageIndex(index_url=index_url) >>> File "/sw/lib/python3.3/site-packages/setuptools/package_index.py", line 269, in __init__ >>> Environment.__init__(self,*args,**kw) >>> File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 799, in __init__ >>> self.scan(search_path) >>> File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 829, in scan >>> self.add(dist) >>> File "/sw/lib/python3.3/site-packages/pkg_resources.py", line 849, in add >>> dists.sort(key=operator.attrgetter('hashcmp'), reverse=True) >>> TypeError: unorderable types: str() < NoneType() > > down to a seemingly broken PackageIndex in their their setuptools.package_index, which always raises the above > error whether you pass it a valid URL or nothing at all, but it?s apparently a bit non-deterministic if the _do_upgrade > is called - or it generally is when building from the tar ball, but not from the git repo. > I could solve this by adding > auto_upgrade = False > to setup.cfg. > Can you think of any objections against this solution (generally I think we don?t want any automatic downloads etc. > within a package build)? Run: ./setup.py --offline to disable the auto-upgrade. In any case it only runs when installing from a tarball, *not* for source checkouts. It's really only there for users making their own pip install. The locale issue will be fixed in the next release. Erik From york at stsci.edu Mon Jul 21 15:35:03 2014 From: york at stsci.edu (Brian York) Date: Mon, 21 Jul 2014 19:35:03 +0000 Subject: [AstroPy] Astropy WCS question Message-ID: Greetings, My apologies if this has already been asked, but I did not have terribly good luck in searching the list archives. I'm currently working on some image simulation, and think that astropy.wcs might be useful to me, but I'm not sufficiently knowledgeable about WCS systems (or, for that matter, about astropy) to be sure. I have a list of sources, each with an RA, DEC, and intensity (in counts/s), and I have a FITS header representing my output image, with WCS and SIP coefficients. I know that wcs_world2pix would give me pixel co-ordinates in the absence of distortion, but I'm wondering if there's some combination of calls that can convert from (RA,DEC) to (X,Y) with the distortion information that I have available? Thanks, -Brian York From stsci.perry at gmail.com Mon Jul 21 16:03:48 2014 From: stsci.perry at gmail.com (Perry Greenfield) Date: Mon, 21 Jul 2014 16:03:48 -0400 Subject: [AstroPy] Astropy WCS question In-Reply-To: References: Message-ID: <0ED85D2D-75E2-4BE0-BD6F-8B4EC2EDCE7F@gmail.com> I think the answer depends on distortion model you are using, but all_pix2world is probably what you want if your distortion model is one that they mention. Perry On Jul 21, 2014, at 3:35 PM, Brian York wrote: > Greetings, > > My apologies if this has already been asked, but I did not have terribly > good luck in searching the list archives. I'm currently working on some > image simulation, and think that astropy.wcs might be useful to me, but > I'm not sufficiently knowledgeable about WCS systems (or, for that matter, > about astropy) to be sure. > > I have a list of sources, each with an RA, DEC, and intensity (in > counts/s), and I have a FITS header representing my output image, with WCS > and SIP coefficients. I know that wcs_world2pix would give me pixel > co-ordinates in the absence of distortion, but I'm wondering if there's > some combination of calls that can convert from (RA,DEC) to (X,Y) with the > distortion information that I have available? > > Thanks, > -Brian York > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From stsci.perry at gmail.com Mon Jul 21 16:05:25 2014 From: stsci.perry at gmail.com (Perry Greenfield) Date: Mon, 21 Jul 2014 16:05:25 -0400 Subject: [AstroPy] Astropy WCS question In-Reply-To: <0ED85D2D-75E2-4BE0-BD6F-8B4EC2EDCE7F@gmail.com> References: <0ED85D2D-75E2-4BE0-BD6F-8B4EC2EDCE7F@gmail.com> Message-ID: <7AECCF16-0A77-4F80-BD0E-3E8C6B29235F@gmail.com> Actually, I meant all_world2pix? On Jul 21, 2014, at 4:03 PM, Perry Greenfield wrote: > I think the answer depends on distortion model you are using, but all_pix2world is probably what you want if your distortion model is one that they mention. > > Perry > > > On Jul 21, 2014, at 3:35 PM, Brian York wrote: > >> Greetings, >> >> My apologies if this has already been asked, but I did not have terribly >> good luck in searching the list archives. I'm currently working on some >> image simulation, and think that astropy.wcs might be useful to me, but >> I'm not sufficiently knowledgeable about WCS systems (or, for that matter, >> about astropy) to be sure. >> >> I have a list of sources, each with an RA, DEC, and intensity (in >> counts/s), and I have a FITS header representing my output image, with WCS >> and SIP coefficients. I know that wcs_world2pix would give me pixel >> co-ordinates in the absence of distortion, but I'm wondering if there's >> some combination of calls that can convert from (RA,DEC) to (X,Y) with the >> distortion information that I have available? >> >> Thanks, >> -Brian York >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy > From york at stsci.edu Mon Jul 21 16:17:25 2014 From: york at stsci.edu (Brian York) Date: Mon, 21 Jul 2014 20:17:25 +0000 Subject: [AstroPy] Astropy WCS question In-Reply-To: <7AECCF16-0A77-4F80-BD0E-3E8C6B29235F@gmail.com> Message-ID: Thank you. I hadn't realized that the function existed. I will note that the documentation at mentions all_pix2world, wcs_world2pix, and wcs_pix2world but does not mention that all_world2pix exists. -Brian On 2014/07/21 16:05 , "Perry Greenfield" wrote: >Actually, I meant all_world2pix? > >On Jul 21, 2014, at 4:03 PM, Perry Greenfield wrote: > >> I think the answer depends on distortion model you are using, but >>all_pix2world is probably what you want if your distortion model is one >>that they mention. >> >> Perry >> >> >> On Jul 21, 2014, at 3:35 PM, Brian York wrote: >> >>> Greetings, >>> >>> My apologies if this has already been asked, but I did not have >>>terribly >>> good luck in searching the list archives. I'm currently working on some >>> image simulation, and think that astropy.wcs might be useful to me, but >>> I'm not sufficiently knowledgeable about WCS systems (or, for that >>>matter, >>> about astropy) to be sure. >>> >>> I have a list of sources, each with an RA, DEC, and intensity (in >>> counts/s), and I have a FITS header representing my output image, with >>>WCS >>> and SIP coefficients. I know that wcs_world2pix would give me pixel >>> co-ordinates in the absence of distortion, but I'm wondering if there's >>> some combination of calls that can convert from (RA,DEC) to (X,Y) with >>>the >>> distortion information that I have available? >>> >>> Thanks, >>> -Brian York >>> >>> >>> _______________________________________________ >>> 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 mdroe at stsci.edu Mon Jul 21 18:06:58 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Mon, 21 Jul 2014 18:06:58 -0400 Subject: [AstroPy] Astropy WCS question In-Reply-To: References: Message-ID: <53CD8F02.5080401@stsci.edu> Brian, Would you mind looking at the following pull request to confirm it addresses the lack of documentation for you? https://github.com/astropy/astropy/issues/2777 Mike On 07/21/2014 04:17 PM, Brian York wrote: > Thank you. I hadn't realized that the function existed. I will note that > the documentation at > > > > mentions all_pix2world, wcs_world2pix, and wcs_pix2world but does not > mention that all_world2pix exists. > > -Brian > > On 2014/07/21 16:05 , "Perry Greenfield" wrote: > >> Actually, I meant all_world2pix? >> >> On Jul 21, 2014, at 4:03 PM, Perry Greenfield wrote: >> >>> I think the answer depends on distortion model you are using, but >>> all_pix2world is probably what you want if your distortion model is one >>> that they mention. >>> >>> Perry >>> >>> >>> On Jul 21, 2014, at 3:35 PM, Brian York wrote: >>> >>>> Greetings, >>>> >>>> My apologies if this has already been asked, but I did not have >>>> terribly >>>> good luck in searching the list archives. I'm currently working on some >>>> image simulation, and think that astropy.wcs might be useful to me, but >>>> I'm not sufficiently knowledgeable about WCS systems (or, for that >>>> matter, >>>> about astropy) to be sure. >>>> >>>> I have a list of sources, each with an RA, DEC, and intensity (in >>>> counts/s), and I have a FITS header representing my output image, with >>>> WCS >>>> and SIP coefficients. I know that wcs_world2pix would give me pixel >>>> co-ordinates in the absence of distortion, but I'm wondering if there's >>>> some combination of calls that can convert from (RA,DEC) to (X,Y) with >>>> the >>>> distortion information that I have available? >>>> >>>> Thanks, >>>> -Brian York >>>> >>>> >>>> _______________________________________________ >>>> 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 -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com From york at stsci.edu Mon Jul 21 18:47:34 2014 From: york at stsci.edu (Brian York) Date: Mon, 21 Jul 2014 22:47:34 +0000 Subject: [AstroPy] Astropy WCS question In-Reply-To: <53CD8F02.5080401@stsci.edu> Message-ID: It looks good to me. Thank you. On 2014/07/21 18:06 , "Michael Droettboom" wrote: >Brian, > >Would you mind looking at the following pull request to confirm it >addresses the lack of documentation for you? > >https://github.com/astropy/astropy/issues/2777 > >Mike > >On 07/21/2014 04:17 PM, Brian York wrote: >> Thank you. I hadn't realized that the function existed. I will note that >> the documentation at >> >> >> >> mentions all_pix2world, wcs_world2pix, and wcs_pix2world but does not >> mention that all_world2pix exists. >> >> -Brian >> >> On 2014/07/21 16:05 , "Perry Greenfield" wrote: >> >>> Actually, I meant all_world2pix? >>> >>> On Jul 21, 2014, at 4:03 PM, Perry Greenfield wrote: >>> >>>> I think the answer depends on distortion model you are using, but >>>> all_pix2world is probably what you want if your distortion model is >>>>one >>>> that they mention. >>>> >>>> Perry >>>> >>>> >>>> On Jul 21, 2014, at 3:35 PM, Brian York wrote: >>>> >>>>> Greetings, >>>>> >>>>> My apologies if this has already been asked, but I did not have >>>>> terribly >>>>> good luck in searching the list archives. I'm currently working on >>>>>some >>>>> image simulation, and think that astropy.wcs might be useful to me, >>>>>but >>>>> I'm not sufficiently knowledgeable about WCS systems (or, for that >>>>> matter, >>>>> about astropy) to be sure. >>>>> >>>>> I have a list of sources, each with an RA, DEC, and intensity (in >>>>> counts/s), and I have a FITS header representing my output image, >>>>>with >>>>> WCS >>>>> and SIP coefficients. I know that wcs_world2pix would give me pixel >>>>> co-ordinates in the absence of distortion, but I'm wondering if >>>>>there's >>>>> some combination of calls that can convert from (RA,DEC) to (X,Y) >>>>>with >>>>> the >>>>> distortion information that I have available? >>>>> >>>>> Thanks, >>>>> -Brian York >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > >-- >Michael Droettboom >Science Software Branch >Space Telescope Science Institute > >http://www.droettboom.com > >_______________________________________________ >AstroPy mailing list >AstroPy at scipy.org >http://mail.scipy.org/mailman/listinfo/astropy > From yg1991 at mail.ustc.edu.cn Tue Jul 22 14:14:16 2014 From: yg1991 at mail.ustc.edu.cn (Guang Yang) Date: Wed, 23 Jul 2014 02:14:16 +0800 (CST) Subject: [AstroPy] Need Help about Astropy.table.Table.write Message-ID: <7203702.775961406052856075.JavaMail.coremail@mailweb> Hi All, I've found Astropy.table.Table.write is unable to write tables with arbitrary units. For example, after using sextractor to generate a fits table, from astropy.table import Table cat = Table.read('sextractor_output.fits', format='fits') cat.write('new.fits', format='fits') Then, the error comes: Unit u'ct' is not part of the FITS standard. And I've found no parameter to avoid the unit problem. Also, when the file 'new.fits' already exists, there seems to be no keyword to overwrite the file. Thanks, Guang Yang From peter at newton.cx Wed Jul 23 16:26:48 2014 From: peter at newton.cx (Peter Williams) Date: Wed, 23 Jul 2014 16:26:48 -0400 Subject: [AstroPy] Dependencies on large data files Message-ID: <1406147208.2947.35.camel@iota.localdomain> Hi all, (Apologies in advance if this topic has already been brought up -- I haven't checked the archives/issues very thoroughly.) One of the features I'd like to see in Astropy would be computation of BJDs -- this is the kind of subtle calculation that many people could use, and you really don't want people hand-rolling their own solutions. The thing is, do to BJD calculations correctly, you need a solar system ephemeris. The compiled version of the standard JPL ephemeris weighs in at 14 MB and is not something that you want to have hanging out in the Git repository. Has any thought been given to having astropy depend on large data files such as an ephemeris table? One could imagine similar dependencies on leap second tables, earth orientation parameters, etc. These kinds of files can be large and it's often desirable to be able to update them out-of-band with regard to the software itself. Is there a model for how to deal with such resources? Cheers, Peter PS. I have code to compile the JPL ephemerides and perform a low-precision BJD calculation, based on the NOVAS library: https://github.com/pkgw/precastro/ This library also uses NOVAS to provide various astrometric routines that I think might also make valuable additions to AstroPy. Is there interest in that kind of functionality? From tim.jenness at gmail.com Wed Jul 23 16:34:25 2014 From: tim.jenness at gmail.com (Tim Jenness) Date: Wed, 23 Jul 2014 13:34:25 -0700 Subject: [AstroPy] Dependencies on large data files In-Reply-To: <1406147208.2947.35.camel@iota.localdomain> References: <1406147208.2947.35.camel@iota.localdomain> Message-ID: On Wed, Jul 23, 2014 at 1:26 PM, Peter Williams wrote: > Hi all, > > (Apologies in advance if this topic has already been brought up -- I > haven't checked the archives/issues very thoroughly.) > > One of the features I'd like to see in Astropy would be computation of > BJDs -- this is the kind of subtle calculation that many people could > use, and you really don't want people hand-rolling their own solutions. > > The thing is, do to BJD calculations correctly, you need a solar system > ephemeris. The compiled version of the standard JPL ephemeris weighs in > at 14 MB and is not something that you want to have hanging out in the > Git repository. > > Suggesting there should be a command people type to dynamically pull the ephemeris from the server and compile it? How accurate do you need to be for usual BJD calculations? Do you need to know the planets to within 0.1 arcsec? There are routines around that can do a reasonable job of estimating the positions of the planets without requiring the full JPL ephemeris. We could even have a scheme where astropy defaulted to something like SLALIB precision if the JPL version wasn't around (Pat Wallace was also telling me about an intermediate level calculation between SLALIB and JPL but I haven't got the link handy). > This library also uses NOVAS to provide various astrometric routines > that I think might also make valuable additions to AstroPy. Is there > interest in that kind of functionality? > ERFA is in astropy already so there are some astrometry routines that exist without having python visibility at the moment. Which routines do you have? -- Tim Jenness -------------- next part -------------- An HTML attachment was scrubbed... URL: From sransom at nrao.edu Wed Jul 23 17:34:25 2014 From: sransom at nrao.edu (Scott Ransom) Date: Wed, 23 Jul 2014 17:34:25 -0400 Subject: [AstroPy] Dependencies on large data files In-Reply-To: <1406147208.2947.35.camel@iota.localdomain> References: <1406147208.2947.35.camel@iota.localdomain> Message-ID: <53D02A61.7020200@nrao.edu> On 07/23/2014 04:26 PM, Peter Williams wrote: > Hi all, > > (Apologies in advance if this topic has already been brought up -- I > haven't checked the archives/issues very thoroughly.) > > One of the features I'd like to see in Astropy would be computation of > BJDs -- this is the kind of subtle calculation that many people could > use, and you really don't want people hand-rolling their own solutions. > > The thing is, do to BJD calculations correctly, you need a solar system > ephemeris. The compiled version of the standard JPL ephemeris weighs in > at 14 MB and is not something that you want to have hanging out in the > Git repository. > > Has any thought been given to having astropy depend on large data files > such as an ephemeris table? One could imagine similar dependencies on > leap second tables, earth orientation parameters, etc. These kinds of > files can be large and it's often desirable to be able to update them > out-of-band with regard to the software itself. Is there a model for how > to deal with such resources? > > Cheers, > > Peter > > PS. I have code to compile the JPL ephemerides and perform a > low-precision BJD calculation, based on the NOVAS library: > > https://github.com/pkgw/precastro/ > > This library also uses NOVAS to provide various astrometric routines > that I think might also make valuable additions to AstroPy. Is there > interest in that kind of functionality? > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy Note that leap seconds and earth orientation params are automatically updated with astropy now. As for barycenter calculations, we are implementing this to very-high precision using the JPL ephemerides for the new high-precision pulsar timing package PINT. For that package we are pulling the JPL ephemeris files and then using SPICE for most of the ephemeris table work. We use the astropy Time objects (which are sweet) for all the time calculations. The software is in its early stages of development (and hasn't been updated recently because of other time commitments), but barycentering is already in there to few nano-sec precision, including all the relativistic effects in our Solar System as well. https://github.com/nanograv/PINT Scott -- Scott M. Ransom Address: NRAO Phone: (434) 296-0320 520 Edgemont Rd. email: sransom at nrao.edu Charlottesville, VA 22903 USA GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 From thomas.robitaille at gmail.com Wed Jul 23 18:21:49 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 24 Jul 2014 00:21:49 +0200 Subject: [AstroPy] Dependencies on large data files In-Reply-To: <1406147208.2947.35.camel@iota.localdomain> References: <1406147208.2947.35.camel@iota.localdomain> Message-ID: <53D0357D.8020704@gmail.com> Hi Peter, Peter Williams wrote: > Hi all, > > (Apologies in advance if this topic has already been brought up -- I > haven't checked the archives/issues very thoroughly.) > > One of the features I'd like to see in Astropy would be computation of > BJDs -- this is the kind of subtle calculation that many people could > use, and you really don't want people hand-rolling their own solutions. > > The thing is, do to BJD calculations correctly, you need a solar system > ephemeris. The compiled version of the standard JPL ephemeris weighs in > at 14 MB and is not something that you want to have hanging out in the > Git repository. > > Has any thought been given to having astropy depend on large data files > such as an ephemeris table? One could imagine similar dependencies on > leap second tables, earth orientation parameters, etc. These kinds of > files can be large and it's often desirable to be able to update them > out-of-band with regard to the software itself. Is there a model for how > to deal with such resources? To answer this original question about large data files, we have indeed put some thought into this and the ``get_pkg_data`` and related routines in ``astropy.utils.data`` do have the ability to fetch data from a data.astropy.org server automatically. We haven't really used it until now because we haven't had the need, but this sounds like a good application. Cheers, Tom > > Cheers, > > Peter > > PS. I have code to compile the JPL ephemerides and perform a > low-precision BJD calculation, based on the NOVAS library: > > https://github.com/pkgw/precastro/ > > This library also uses NOVAS to provide various astrometric routines > that I think might also make valuable additions to AstroPy. Is there > interest in that kind of functionality? > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From peter at newton.cx Thu Jul 24 09:35:36 2014 From: peter at newton.cx (Peter Williams) Date: Thu, 24 Jul 2014 09:35:36 -0400 Subject: [AstroPy] Dependencies on large data files In-Reply-To: <53D0357D.8020704@gmail.com> References: <1406147208.2947.35.camel@iota.localdomain> <53D0357D.8020704@gmail.com> Message-ID: <1406208936.2729.33.camel@iota.localdomain> Bundling my replies ... On Wed, 2014-07-23 at 17:34 -0400, Scott Ransom wrote: > As for barycenter calculations, we are implementing this to very-high > precision using the JPL ephemerides for the new high-precision pulsar > timing package PINT. For that package we are pulling the JPL ephemeris > files and then using SPICE for most of the ephemeris table work. We use > the astropy Time objects (which are sweet) for all the time calculations. > > The software is in its early stages of development (and hasn't been > updated recently because of other time commitments), but barycentering > is already in there to few nano-sec precision, including all the > relativistic effects in our Solar System as well. > > https://github.com/nanograv/PINT That's great to hear! I know you guys are the pros at this kind of thing. On Wed, 2014-07-23 at 13:34 -0700, Tim Jenness wrote: > ERFA is in astropy already so there are some astrometry routines that > exist without having python visibility at the moment. > > Which routines do you have? I've mainly used the NOVAS routines that do things like calculate horizon coordinates and astrometric positions accounting for proper motion, aberration, etc. A lot of these calculations are basic spherical trig for most uses, but NOVAS does them right to VLBI-level precision. I personally don't need anything that accurate (so I'm probably doing a bunch of stuff wrong...), but it seems good to build on a foundation that *can* achieve that level of precision. If I recall correctly, SOFA/ERFA doesn't include the high-level routines to do these kinds of calculations. And as far as I can tell, AstroPy doesn't currently provide tools for things like calculating horizon coordinates, rise/set times, astrometry, etc ... correct? On Thu, 2014-07-24 at 00:21 +0200, Thomas Robitaille wrote: > To answer this original question about large data files, we have indeed > put some thought into this and the ``get_pkg_data`` and related routines > in ``astropy.utils.data`` do have the ability to fetch data from a > data.astropy.org server automatically. We haven't really used it until > now because we haven't had the need, but this sounds like a good > application. Thanks for the pointer -- I had some dim memory that there was infrastructure for this kind of thing. Overall, I think it'd be great for AstroPy to include infrastructure for BJDs and high-quality positional astronomy routines. But there's a question of how "high-quality" one can get before the APIs and dependencies become too cumbersome for a general-use package. So, for the experts in the room: what level of precision do you think can be achieved in a general-use library like AstroPy? Is that something where the JPL ephemeris will be a useful piece of infrastructure, or are analytic calculations going to be good enough? Cheers, Peter From octavi at live.unc.edu Thu Jul 24 19:47:11 2014 From: octavi at live.unc.edu (Octavi Fors) Date: Thu, 24 Jul 2014 19:47:11 -0400 Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion Message-ID: Dear all, I've been struggling with this for two weeks ago, but no luck so far. I'm getting the astrometry plate solution of images from a 40?x40? FoV camera-lens CCD with Astrometry.net 0.49, TAN--SIP projection, and *5th* order SIP distortion polynomials. If I overplot with ds9 the Tycho2 stars in the field in J2000 coordinates (Analysis->Catalogs->Optical->Tycho2 menu), the green circles match the positions of all the stars in the FoV. *However*, after running SExtractor 2.19.5 over the plate solved image, while the pixel coordinates (XWIN_IMAGE,YWIN_IMAGE) *do* match the stars, the precessed celestial (ALPHAWIN_J2000,DELTAWIN_J2000) ones *do not* (they show offsets of several arcmins). I've asked SExtractor developers if such software does support TAN--SIP WCS convertion. Still waiting, but my guess is it does not. So a TAN--SIP->TAN-PV projection converter is what I'm looking for. Caltech PTF team (see SPIE paper ) made these SIP<->PV converters to 4th order (not to 5th order, which is what I need). For license issues, they can only release the binaries here , but not the source code (which would allow me to extend the conversion formulas to 5th order). Is there anybody in astropy community who is planning to implement a method in WCS class for converting from SIP to PV projection? I would be more than happy to provide testing images. Thanks in advance, Octavi. -- Octavi Fors Postdoctoral Research Associate Department of Physics and Astronomy The University of North Carolina at Chapel Hill CB #3255, #157 Phillips Hall Chapel Hill, NC 27599 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.jenness at gmail.com Thu Jul 24 20:04:02 2014 From: tim.jenness at gmail.com (Tim Jenness) Date: Thu, 24 Jul 2014 17:04:02 -0700 Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion In-Reply-To: References: Message-ID: On Thu, Jul 24, 2014 at 4:47 PM, Octavi Fors wrote: > Dear all, > > I've been struggling with this for two weeks ago, but no luck so far. > > I'm getting the astrometry plate solution of images from a 40?x40? FoV > camera-lens CCD with Astrometry.net 0.49, TAN--SIP projection, and *5th* > order SIP distortion polynomials. > > If I overplot with ds9 the Tycho2 stars in the field in J2000 coordinates > (Analysis->Catalogs->Optical->Tycho2 menu), the green circles match the > positions of all the stars in the FoV. > > DS9 uses the AST astrometry library which in python is called pyast. http://dsberry.github.io/starlink/pyast.html -- Tim Jenness -------------- next part -------------- An HTML attachment was scrubbed... URL: From yg1991 at mail.ustc.edu.cn Thu Jul 24 22:33:46 2014 From: yg1991 at mail.ustc.edu.cn (Guang Yang) Date: Fri, 25 Jul 2014 10:33:46 +0800 (CST) Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion In-Reply-To: References: Message-ID: <23898009.928231406255626697.JavaMail.coremail@mailweb> Hi Octavi, The astrometry.net group has some related codes. ( http://astrometry.net/doc/readme.html#fits-utilities ) You may try wcs-resample in them, But I'm not sure it works for your case. Are you trying to correct astrometry of an image so that it matches well with another? If so, we can discuss this, since that's what I did last year. Thanks, Guang -----Original email----- From: "Octavi Fors" Sent Time: Jul 25, 2014 7:47:11 AM To: astropy at scipy.org Cc: Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion Dear all, I've been struggling with this for two weeks ago, but no luck so far. I'm getting the astrometry plate solution of images from a 40?x40? FoV camera-lens CCD with Astrometry.net 0.49, TAN--SIP projection, and *5th* order SIP distortion polynomials. If I overplot with ds9 the Tycho2 stars in the field in J2000 coordinates (Analysis->Catalogs->Optical->Tycho2 menu), the green circles match the positions of all the stars in the FoV. *However*, after running SExtractor 2.19.5 over the plate solved image, while the pixel coordinates (XWIN_IMAGE,YWIN_IMAGE) *do* match the stars, the precessed celestial (ALPHAWIN_J2000,DELTAWIN_J2000) ones *do not* (they show offsets of several arcmins). I've asked SExtractor developers if such software does support TAN--SIP WCS convertion. Still waiting, but my guess is it does not. So a TAN--SIP->TAN-PV projection converter is what I'm looking for. Caltech PTF team (see SPIE paper) made these SIP<->PV converters to 4th order (not to 5th order, which is what I need). For license issues, they can only release the binaries here , but not the source code (which would allow me to extend the conversion formulas to 5th order). Is there anybody in astropy community who is planning to implement a method in WCS class for converting from SIP to PV projection? I would be more than happy to provide testing images. Thanks in advance, Octavi. -- Octavi Fors Postdoctoral Research Associate Department of Physics and Astronomy The University of North Carolina at Chapel Hill CB #3255, #157 Phillips Hall Chapel Hill, NC 27599 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Fri Jul 25 06:59:21 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Fri, 25 Jul 2014 12:59:21 +0200 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <7203702.775961406052856075.JavaMail.coremail@mailweb> References: <7203702.775961406052856075.JavaMail.coremail@mailweb> Message-ID: <53D23889.6050807@gmail.com> Hi Guang, To overwrite a file, you can use: cat.write('new.fits', format='fits', overwrite=True) For the unit, the issue is that ``ct`` is not a valid unit according to the FITS standard. The 'correct' unit for FITS is ``count``. We may be overly strict at the moment in that Table.write will simply crash if a unit is not standard-compliant, when we could simply emit a warning and still write it out, so I will open an issue for that. So in the mean time, the solution is to do: cat['name'].unit = 'count' where 'name' is the name of the problematic column. Do this before writing it out to FITS. Cheers, Tom Guang Yang wrote: > Hi All, > > I've found Astropy.table.Table.write is unable to write tables with arbitrary units. > For example, after using sextractor to generate a fits table, > > from astropy.table import Table > cat = Table.read('sextractor_output.fits', format='fits') > cat.write('new.fits', format='fits') > > Then, the error comes: Unit u'ct' is not part of the FITS standard. And I've found no parameter to avoid the unit problem. > > Also, when the file 'new.fits' already exists, there seems to be no keyword to overwrite the file. > > Thanks, > Guang Yang > > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From yg1991 at mail.ustc.edu.cn Fri Jul 25 08:07:48 2014 From: yg1991 at mail.ustc.edu.cn (Guang Yang) Date: Fri, 25 Jul 2014 20:07:48 +0800 (CST) Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <53D23889.6050807@gmail.com> References: <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> Message-ID: <22638082.966731406290068860.JavaMail.coremail@mailweb> Hi Tom, Great, it works. Hope in the future there will be keywords that can overriede the fits standard constraints. Thank you very much, Guang > -----Original email----- > From: "Thomas Robitaille" > Sent Time: Jul 25, 2014 6:59:21 PM > To: "Astronomical Python mailing list" > Cc: > Subject: Re: [AstroPy] Need Help about Astropy.table.Table.write > > Hi Guang, > > To overwrite a file, you can use: > > cat.write('new.fits', format='fits', overwrite=True) > > For the unit, the issue is that ``ct`` is not a valid unit according to > the FITS standard. The 'correct' unit for FITS is ``count``. We may be > overly strict at the moment in that Table.write will simply crash if a > unit is not standard-compliant, when we could simply emit a warning and > still write it out, so I will open an issue for that. > > So in the mean time, the solution is to do: > > cat['name'].unit = 'count' > > where 'name' is the name of the problematic column. Do this before > writing it out to FITS. > > Cheers, > Tom > > Guang Yang wrote: > > Hi All, > > > > I've found Astropy.table.Table.write is unable to write tables with arbitrary units. > > For example, after using sextractor to generate a fits table, > > > > from astropy.table import Table > > cat = Table.read('sextractor_output.fits', format='fits') > > cat.write('new.fits', format='fits') > > > > Then, the error comes: Unit u'ct' is not part of the FITS standard. And I've found no parameter to avoid the unit problem. > > > > Also, when the file 'new.fits' already exists, there seems to be no keyword to overwrite the file. > > > > Thanks, > > Guang Yang > > > > > > > > > > > > _______________________________________________ > > 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 teuben at astro.umd.edu Fri Jul 25 08:19:43 2014 From: teuben at astro.umd.edu (Peter Teuben) Date: Fri, 25 Jul 2014 08:19:43 -0400 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <22638082.966731406290068860.JavaMail.coremail@mailweb> References: <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> Message-ID: <53D24B5F.7010804@astro.umd.edu> Guang, in your case I think you were done a service, so make 'ct' become "count", since the (FITS) community has decided this to be a better more descriptive word. Most non-english speakers might even have difficulties with "ct" so your desire to there be a future that can override the fits standard has to be take with caution, especially if the column has a meaning we already agreed upon. Perhaps the code can emit a warning and refer to the FITS resource where all the units are defined, or even spit out the ones the code knows about .... heaven forbid? peter On 07/25/2014 08:07 AM, Guang Yang wrote: > Hi Tom, > > Great, it works. Hope in the future there will be keywords that can overriede the fits standard constraints. > > Thank you very much, > Guang > > >> -----Original email----- >> From: "Thomas Robitaille" >> Sent Time: Jul 25, 2014 6:59:21 PM >> To: "Astronomical Python mailing list" >> Cc: >> Subject: Re: [AstroPy] Need Help about Astropy.table.Table.write >> >> Hi Guang, >> >> To overwrite a file, you can use: >> >> cat.write('new.fits', format='fits', overwrite=True) >> >> For the unit, the issue is that ``ct`` is not a valid unit according to >> the FITS standard. The 'correct' unit for FITS is ``count``. We may be >> overly strict at the moment in that Table.write will simply crash if a >> unit is not standard-compliant, when we could simply emit a warning and >> still write it out, so I will open an issue for that. >> >> So in the mean time, the solution is to do: >> >> cat['name'].unit = 'count' >> >> where 'name' is the name of the problematic column. Do this before >> writing it out to FITS. >> >> Cheers, >> Tom >> >> Guang Yang wrote: >>> Hi All, >>> >>> I've found Astropy.table.Table.write is unable to write tables with arbitrary units. >>> For example, after using sextractor to generate a fits table, >>> >>> from astropy.table import Table >>> cat = Table.read('sextractor_output.fits', format='fits') >>> cat.write('new.fits', format='fits') >>> >>> Then, the error comes: Unit u'ct' is not part of the FITS standard. And I've found no parameter to avoid the unit problem. >>> >>> Also, when the file 'new.fits' already exists, there seems to be no keyword to overwrite the file. >>> >>> Thanks, >>> Guang Yang >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 yg1991 at mail.ustc.edu.cn Fri Jul 25 08:28:31 2014 From: yg1991 at mail.ustc.edu.cn (Guang Yang) Date: Fri, 25 Jul 2014 20:28:31 +0800 (CST) Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <53D24B5F.7010804@astro.umd.edu> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> Message-ID: <1466815.967341406291311814.JavaMail.coremail@mailweb> Hi Peter, Emitting a warning is great, just like when reading some non-standard wcs in fits header. Thanks, Guang > -----Original email----- > From: "Peter Teuben" > Sent Time: Jul 25, 2014 8:19:43 PM > To: "Astronomical Python mailing list" > Cc: > Subject: Re: [AstroPy] Need Help about Astropy.table.Table.write > > Guang, > in your case I think you were done a service, so make 'ct' become > "count", since the (FITS) community has decided this to be a better more > descriptive word. Most non-english speakers might even have difficulties > with "ct" so your desire to there be a future that can override the fits > standard has to be take with caution, especially if the column has a > meaning we already agreed upon. > > Perhaps the code can emit a warning and refer to the FITS resource where > all the units are defined, or even spit out the ones the code knows > about .... heaven forbid? > > peter > > On 07/25/2014 08:07 AM, Guang Yang wrote: > > Hi Tom, > > > > Great, it works. Hope in the future there will be keywords that can overriede the fits standard constraints. > > > > Thank you very much, > > Guang > > > > > >> -----Original email----- > >> From: "Thomas Robitaille" > >> Sent Time: Jul 25, 2014 6:59:21 PM > >> To: "Astronomical Python mailing list" > >> Cc: > >> Subject: Re: [AstroPy] Need Help about Astropy.table.Table.write > >> > >> Hi Guang, > >> > >> To overwrite a file, you can use: > >> > >> cat.write('new.fits', format='fits', overwrite=True) > >> > >> For the unit, the issue is that ``ct`` is not a valid unit according to > >> the FITS standard. The 'correct' unit for FITS is ``count``. We may be > >> overly strict at the moment in that Table.write will simply crash if a > >> unit is not standard-compliant, when we could simply emit a warning and > >> still write it out, so I will open an issue for that. > >> > >> So in the mean time, the solution is to do: > >> > >> cat['name'].unit = 'count' > >> > >> where 'name' is the name of the problematic column. Do this before > >> writing it out to FITS. > >> > >> Cheers, > >> Tom > >> > >> Guang Yang wrote: > >>> Hi All, > >>> > >>> I've found Astropy.table.Table.write is unable to write tables with arbitrary units. > >>> For example, after using sextractor to generate a fits table, > >>> > >>> from astropy.table import Table > >>> cat = Table.read('sextractor_output.fits', format='fits') > >>> cat.write('new.fits', format='fits') > >>> > >>> Then, the error comes: Unit u'ct' is not part of the FITS standard. And I've found no parameter to avoid the unit problem. > >>> > >>> Also, when the file 'new.fits' already exists, there seems to be no keyword to overwrite the file. > >>> > >>> Thanks, > >>> Guang Yang > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 peter at newton.cx Fri Jul 25 09:00:10 2014 From: peter at newton.cx (Peter Williams) Date: Fri, 25 Jul 2014 09:00:10 -0400 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <1466815.967341406291311814.JavaMail.coremail@mailweb> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> Message-ID: <1406293210.2874.4.camel@iota.localdomain> I'm with Peter T on this. I don't think the standard is well-designed on this front, but it's still the standard! You want to deal with other people's broken data sets as best you can, but you don't want to add to the problem by creating more broken data sets. If there's a resource out there that gives a clear summary of allowed FITS units, the AstroPy error message should point people to it. Peter On Fri, 2014-07-25 at 20:28 +0800, Guang Yang wrote: > Hi Peter, > > Emitting a warning is great, just like when reading some non-standard wcs in fits header. > > Thanks, > Guang > > > > -----Original email----- > > From: "Peter Teuben" > > Sent Time: Jul 25, 2014 8:19:43 PM > > To: "Astronomical Python mailing list" > > Cc: > > Subject: Re: [AstroPy] Need Help about Astropy.table.Table.write > > > > Guang, > > in your case I think you were done a service, so make 'ct' become > > "count", since the (FITS) community has decided this to be a better more > > descriptive word. Most non-english speakers might even have difficulties > > with "ct" so your desire to there be a future that can override the fits > > standard has to be take with caution, especially if the column has a > > meaning we already agreed upon. > > > > Perhaps the code can emit a warning and refer to the FITS resource where > > all the units are defined, or even spit out the ones the code knows > > about .... heaven forbid? > > > > peter > > > > On 07/25/2014 08:07 AM, Guang Yang wrote: > > > Hi Tom, > > > > > > Great, it works. Hope in the future there will be keywords that can overriede the fits standard constraints. > > > > > > Thank you very much, > > > Guang > > > > > > > > >> -----Original email----- > > >> From: "Thomas Robitaille" > > >> Sent Time: Jul 25, 2014 6:59:21 PM > > >> To: "Astronomical Python mailing list" > > >> Cc: > > >> Subject: Re: [AstroPy] Need Help about Astropy.table.Table.write > > >> > > >> Hi Guang, > > >> > > >> To overwrite a file, you can use: > > >> > > >> cat.write('new.fits', format='fits', overwrite=True) > > >> > > >> For the unit, the issue is that ``ct`` is not a valid unit according to > > >> the FITS standard. The 'correct' unit for FITS is ``count``. We may be > > >> overly strict at the moment in that Table.write will simply crash if a > > >> unit is not standard-compliant, when we could simply emit a warning and > > >> still write it out, so I will open an issue for that. > > >> > > >> So in the mean time, the solution is to do: > > >> > > >> cat['name'].unit = 'count' > > >> > > >> where 'name' is the name of the problematic column. Do this before > > >> writing it out to FITS. > > >> > > >> Cheers, > > >> Tom > > >> > > >> Guang Yang wrote: > > >>> Hi All, > > >>> > > >>> I've found Astropy.table.Table.write is unable to write tables with arbitrary units. > > >>> For example, after using sextractor to generate a fits table, > > >>> > > >>> from astropy.table import Table > > >>> cat = Table.read('sextractor_output.fits', format='fits') > > >>> cat.write('new.fits', format='fits') > > >>> > > >>> Then, the error comes: Unit u'ct' is not part of the FITS standard. And I've found no parameter to avoid the unit problem. > > >>> > > >>> Also, when the file 'new.fits' already exists, there seems to be no keyword to overwrite the file. > > >>> > > >>> Thanks, > > >>> Guang Yang > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> AstroPy mailing list > > >>> AstroPy at scipy.org > > >>> http://mail.scipy.org/mailman/listinfo/astropy > > >> _______________________________________________ > > >> AstroPy mailing list > > >> AstroPy at scipy.org > > >> http://mail.scipy.org/mailman/listinfo/astropy > > > _______________________________________________ > > > AstroPy mailing list > > > AstroPy at scipy.org > > > http://mail.scipy.org/mailman/listinfo/astropy > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > From derek at astro.physik.uni-goettingen.de Fri Jul 25 09:10:50 2014 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Fri, 25 Jul 2014 15:10:50 +0200 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <1406293210.2874.4.camel@iota.localdomain> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> Message-ID: On 25 Jul 2014, at 03:00 pm, Peter Williams wrote: > If there's a resource out there that gives a clear summary of allowed > FITS units, the AstroPy error message should point people to it. On reading it even gives suggestions for the correct keyword; I have not looked up where exactly this is issued, but it should be straightforward to add other common misnomers there (and extend the suggestion to the write call). But there seem to be different levels of what deviations from the standard are tolerated? The following is silently written back to a new FITS file (with the units unchanged, astropy 0.4): vega = apt.Table.read('ftp://ftp.stsci.edu/cdbs/calspec/alpha_lyr_stis_007.fits') WARNING: UnitsWarning: 'ANGSTROMS' did not parse as fits unit: At col 0, Unit 'ANGSTROMS' not supported by the FITS standard. Did you mean Angstrom or angstrom? [astropy.units.core] WARNING: UnitsWarning: 'FLAM' did not parse as fits unit: At col 0, Unit 'FLAM' not supported by the FITS standard. Did you mean flm? [astropy.units.core] WARNING: UnitsWarning: 'NONE' did not parse as fits unit: At col 0, Unit 'NONE' not supported by the FITS standard. [astropy.units.core] WARNING: UnitsWarning: 'SEC' did not parse as fits unit: At col 0, Unit 'SEC' not supported by the FITS standard. Did you mean EC? [astropy.units.core] Cheers, Derek From shupe at ipac.caltech.edu Fri Jul 25 09:40:10 2014 From: shupe at ipac.caltech.edu (David Shupe) Date: Fri, 25 Jul 2014 06:40:10 -0700 Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion In-Reply-To: References: Message-ID: <30D23774-371B-44CF-87EA-12C3065F5604@ipac.caltech.edu> Hi Octavi, For the PV-to-SIP and SIP-to-PV codes we?ve developed (4th order), I?m close to completing the Caltech process for releasing the source code. It is my intent to extend this to higher orders and to implement it in Astropy in some way. I?m just completing my very first pull request for Astropy on a simpler issue, so now that I?ve learned the workflow I really do want to make this contribution next. I need to ask for some help from the WCS experts for advice on where this would go. Regards, David On Jul 24, 2014, at 4:47 PM, Octavi Fors wrote: > So a TAN--SIP->TAN-PV projection converter is what I'm looking for. > > Caltech PTF team (see SPIE paper) made these SIP<->PV converters to 4th order (not to 5th order, which is what I need). For license issues, they can only release the binaries here , but not the source code (which would allow me to extend the conversion formulas to 5th order). > > Is there anybody in astropy community who is planning to implement a method in WCS class for converting from SIP to PV projection? > I would be more than happy to provide testing images. David Shupe, Ph.D. NASA Herschel Science Center, IPAC, Caltech MC 100-22 | 1200 E. California Blvd, Pasadena, CA 91125 USA email: shupe at ipac.caltech.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From octavi at live.unc.edu Fri Jul 25 09:43:49 2014 From: octavi at live.unc.edu (Octavi Fors) Date: Fri, 25 Jul 2014 09:43:49 -0400 Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion In-Reply-To: <23898009.928231406255626697.JavaMail.coremail@mailweb> References: <23898009.928231406255626697.JavaMail.coremail@mailweb> Message-ID: Hi Guang, I understand that wcs-resample requires a second (target) image file with the WCS you want to apply to the input image, which has different WCS projection. In my case, I only have one image with TAN--SIP projection (which SExtractor doesn't seem to understand), and my aim is to get an output image with the TAN PV_i_j projection (which is of one the projections SExtractor understands). Thanks, Octavi. On Thu, Jul 24, 2014 at 10:33 PM, Guang Yang wrote: > Hi Octavi, > > The astrometry.net group has some related codes. ( > http://astrometry.net/doc/readme.html#fits-utilities ) You may try > wcs-resample in them, But I'm not sure it works for your case. > > Are you trying to correct astrometry of an image so that it matches well > with another? If so, we can discuss this, since that's what I did last year. > > Thanks, > Guang > > > -----Original email----- > *From:* "Octavi Fors" > *Sent Time:* Jul 25, 2014 7:47:11 AM > *To:* astropy at scipy.org > *Cc:* > *Subject:* [AstroPy] TAN--SIP -> TAN PV WCS projection conversion > > > Dear all, > > I've been struggling with this for two weeks ago, but no luck so far. > > I'm getting the astrometry plate solution of images from a 40?x40? FoV > camera-lens CCD with Astrometry.net 0.49, TAN--SIP projection, and *5th* > order SIP distortion polynomials. > > If I overplot with ds9 the Tycho2 stars in the field in J2000 coordinates > (Analysis->Catalogs->Optical->Tycho2 menu), the green circles match the > positions of all the stars in the FoV. > > *However*, after running SExtractor 2.19.5 over the plate solved image, > while the pixel coordinates (XWIN_IMAGE,YWIN_IMAGE) *do* match the stars, > the precessed celestial (ALPHAWIN_J2000,DELTAWIN_J2000) ones *do not* (they > show offsets of several arcmins). > > I've asked SExtractor developers if such software does support TAN--SIP > WCS convertion. Still waiting, but my guess is it does not. > > So a TAN--SIP->TAN-PV projection converter is what I'm looking for. > > Caltech PTF team (see SPIE paper > ) > made these SIP<->PV converters to 4th order (not to 5th order, which is > what I need). For license issues, they can only release the binaries here > , but not the source > code (which would allow me to extend the conversion formulas to 5th order). > > Is there anybody in astropy community who is planning to implement a > method in WCS class for converting from SIP to PV projection? > I would be more than happy to provide testing images. > > Thanks in advance, > > Octavi. > > -- > Octavi Fors > Postdoctoral Research Associate > Department of Physics and Astronomy > The University of North Carolina at Chapel Hill > CB #3255, #157 Phillips Hall > Chapel Hill, NC 27599 > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- Octavi Fors Postdoctoral Research Associate Department of Physics and Astronomy The University of North Carolina at Chapel Hill CB #3255, #157 Phillips Hall Chapel Hill, NC 27599 Office: (919) 962-3606 Fax: (919) 962-0480 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yg1991 at mail.ustc.edu.cn Fri Jul 25 10:18:39 2014 From: yg1991 at mail.ustc.edu.cn (Guang Yang) Date: Fri, 25 Jul 2014 22:18:39 +0800 (CST) Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion In-Reply-To: References: <23898009.928231406255626697.JavaMail.coremail@mailweb> Message-ID: <27272369.972181406297919493.JavaMail.coremail@mailweb> Hi Octavi, So, if my understanding is right, you want sextractor to detect the sources and transfrom their (x, y) to (ra, dec). Well, I think it's unnecessary to rely on sextractor to do the transformation. I mean, you can output the source position directly in (x, y) and transform the (x, y) to (ra, dec) via other tools, like, wcs-xy2rd in astrometry.net tools. Does that make sense? Thanks, Guang -----Original email----- From: "Octavi Fors" Sent Time: Jul 25, 2014 9:43:49 PM To: "Astronomical Python mailing list" Cc: Subject: Re: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion Hi Guang, I understand that wcs-resample requires a second (target) image file with the WCS you want to apply to the input image, which has different WCS projection. In my case, I only have one image with TAN--SIP projection (which SExtractor doesn't seem to understand), and my aim is to get an output image with the TAN PV_i_j projection (which is of one the projections SExtractor understands). Thanks, Octavi. On Thu, Jul 24, 2014 at 10:33 PM, Guang Yang wrote: Hi Octavi, The astrometry.net group has some related codes. ( http://astrometry.net/doc/readme.html#fits-utilities ) You may try wcs-resample in them, But I'm not sure it works for your case. Are you trying to correct astrometry of an image so that it matches well with another? If so, we can discuss this, since that's what I did last year. Thanks, Guang -----Original email----- From: "Octavi Fors" Sent Time: Jul 25, 2014 7:47:11 AM To:astropy at scipy.org Cc: Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion Dear all, I've been struggling with this for two weeks ago, but no luck so far. I'm getting the astrometry plate solution of images from a 40?x40? FoV camera-lens CCD with Astrometry.net 0.49, TAN--SIP projection, and *5th* order SIP distortion polynomials. If I overplot with ds9 the Tycho2 stars in the field in J2000 coordinates (Analysis->Catalogs->Optical->Tycho2 menu), the green circles match the positions of all the stars in the FoV. *However*, after running SExtractor 2.19.5 over the plate solved image, while the pixel coordinates (XWIN_IMAGE,YWIN_IMAGE) *do* match the stars, the precessed celestial (ALPHAWIN_J2000,DELTAWIN_J2000) ones *do not* (they show offsets of several arcmins). I've asked SExtractor developers if such software does support TAN--SIP WCS convertion. Still waiting, but my guess is it does not. So a TAN--SIP->TAN-PV projection converter is what I'm looking for. Caltech PTF team (see SPIE paper) made these SIP<->PV converters to 4th order (not to 5th order, which is what I need). For license issues, they can only release the binaries here , but not the source code (which would allow me to extend the conversion formulas to 5th order). Is there anybody in astropy community who is planning to implement a method in WCS class for converting from SIP to PV projection? I would be more than happy to provide testing images. Thanks in advance, Octavi. -- Octavi Fors Postdoctoral Research Associate Department of Physics and Astronomy The University of North Carolina at Chapel Hill CB #3255, #157 Phillips Hall Chapel Hill, NC 27599 _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -- Octavi Fors Postdoctoral Research Associate Department of Physics and Astronomy The University of North Carolina at Chapel Hill CB #3255, #157 Phillips Hall Chapel Hill, NC 27599 Office: (919) 962-3606 Fax: (919) 962-0480 -------------- next part -------------- An HTML attachment was scrubbed... URL: From octavi at live.unc.edu Fri Jul 25 13:07:21 2014 From: octavi at live.unc.edu (Octavi Fors) Date: Fri, 25 Jul 2014 13:07:21 -0400 Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion In-Reply-To: <30D23774-371B-44CF-87EA-12C3065F5604@ipac.caltech.edu> References: <30D23774-371B-44CF-87EA-12C3065F5604@ipac.caltech.edu> Message-ID: Thanks David for your effort in releasing the Caltech PTF converters source code. It is my intent to extend this to higher orders and to implement it in > Astropy in some way. I?m just completing my very first pull request for > Astropy on a simpler issue, so now that I?ve learned the workflow I really > do want to make this contribution next. I need to ask for some help from > the WCS experts for advice on where this would go. > that's sounds like an awesome plan! I encourage the WCS experts to help you on this. Unfortunately I'm not a WCS expert, but I can contribute in providing wide-field images and testing code. Thanks so much again, Octavi. On Fri, Jul 25, 2014 at 9:40 AM, David Shupe wrote: > Hi Octavi, > > For the PV-to-SIP and SIP-to-PV codes we?ve developed (4th order), I?m > close to completing the Caltech process for releasing the source code. > > It is my intent to extend this to higher orders and to implement it in > Astropy in some way. I?m just completing my very first pull request for > Astropy on a simpler issue, so now that I?ve learned the workflow I really > do want to make this contribution next. I need to ask for some help from > the WCS experts for advice on where this would go. > > Regards, > David > > On Jul 24, 2014, at 4:47 PM, Octavi Fors wrote: > > So a TAN--SIP->TAN-PV projection converter is what I'm looking for. > > Caltech PTF team (see SPIE paper > ) > made these SIP<->PV converters to 4th order (not to 5th order, which is > what I need). For license issues, they can only release the binaries here > , but not the source > code (which would allow me to extend the conversion formulas to 5th order). > > Is there anybody in astropy community who is planning to implement a > method in WCS class for converting from SIP to PV projection? > I would be more than happy to provide testing images. > > > > > David Shupe, Ph.D. > NASA Herschel Science Center, IPAC, Caltech > MC 100-22 | 1200 E. California Blvd, Pasadena, CA 91125 USA > email: shupe at ipac.caltech.edu > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- Octavi Fors Postdoctoral Research Associate Department of Physics and Astronomy The University of North Carolina at Chapel Hill CB #3255, #157 Phillips Hall Chapel Hill, NC 27599 Office: (919) 962-3606 Fax: (919) 962-0480 -------------- next part -------------- An HTML attachment was scrubbed... URL: From octavi at live.unc.edu Fri Jul 25 14:19:21 2014 From: octavi at live.unc.edu (Octavi Fors) Date: Fri, 25 Jul 2014 14:19:21 -0400 Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion In-Reply-To: <27272369.972181406297919493.JavaMail.coremail@mailweb> References: <23898009.928231406255626697.JavaMail.coremail@mailweb> <27272369.972181406297919493.JavaMail.coremail@mailweb> Message-ID: Hi Guang, I don't want to work-around this on the SExtractor catalog level (via wcs-xy2rd in astrometry.net, xy2sky in WCSTools, or w.all_pix2world(x,y,1) in astropy, which I actually have working) since the astrometrically solved images must be shared with other users. These, as most of us, use SExtractor as photometry extractor engine. So, in my opinion, it is quite inefficient that they have to use the same catalog-based work-around solution instead of straight-forward using an already projection converted image (as David Shupe did in PTF). Hope it helps, Octavi. On Fri, Jul 25, 2014 at 10:18 AM, Guang Yang wrote: > Hi Octavi, > > So, if my understanding is right, you want sextractor to detect the > sources and transfrom their (x, y) to (ra, dec). Well, I think it's > unnecessary to rely on sextractor to do the transformation. I mean, you can > output the source position directly in (x, y) and transform the (x, y) to > (ra, dec) via other tools, like, wcs-xy2rd in astrometry.net tools. Does > that make sense? > > Thanks, > Guang > > > -----Original email----- > *From:* "Octavi Fors" > *Sent Time:* Jul 25, 2014 9:43:49 PM > *To:* "Astronomical Python mailing list" > *Cc:* > *Subject:* Re: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion > > > Hi Guang, > > I understand that wcs-resample requires a second (target) image file with > the WCS you want to apply to the input image, which has different WCS > projection. > > In my case, I only have one image with TAN--SIP projection (which > SExtractor doesn't seem to understand), and my aim is to get an output > image with the TAN PV_i_j projection (which is of one the projections > SExtractor understands). > > Thanks, > > Octavi. > > > > On Thu, Jul 24, 2014 at 10:33 PM, Guang Yang > wrote: > >> Hi Octavi, >> >> The astrometry.net group has some related codes. ( >> http://astrometry.net/doc/readme.html#fits-utilities ) You may try >> wcs-resample in them, But I'm not sure it works for your case. >> >> Are you trying to correct astrometry of an image so that it matches well >> with another? If so, we can discuss this, since that's what I did last year. >> >> Thanks, >> Guang >> >> >> -----Original email----- >> *From:* "Octavi Fors" >> *Sent Time:* Jul 25, 2014 7:47:11 AM >> *To:* astropy at scipy.org >> *Cc:* >> *Subject:* [AstroPy] TAN--SIP -> TAN PV WCS projection conversion >> >> >> Dear all, >> >> I've been struggling with this for two weeks ago, but no luck so far. >> >> I'm getting the astrometry plate solution of images from a 40?x40? FoV >> camera-lens CCD with Astrometry.net 0.49, TAN--SIP projection, and *5th* >> order SIP distortion polynomials. >> >> If I overplot with ds9 the Tycho2 stars in the field in J2000 coordinates >> (Analysis->Catalogs->Optical->Tycho2 menu), the green circles match the >> positions of all the stars in the FoV. >> >> *However*, after running SExtractor 2.19.5 over the plate solved image, >> while the pixel coordinates (XWIN_IMAGE,YWIN_IMAGE) *do* match the stars, >> the precessed celestial (ALPHAWIN_J2000,DELTAWIN_J2000) ones *do not* (they >> show offsets of several arcmins). >> >> I've asked SExtractor developers if such software does support TAN--SIP >> WCS convertion. Still waiting, but my guess is it does not. >> >> So a TAN--SIP->TAN-PV projection converter is what I'm looking for. >> >> Caltech PTF team (see SPIE paper >> ) >> made these SIP<->PV converters to 4th order (not to 5th order, which is >> what I need). For license issues, they can only release the binaries here >> , but not the source >> code (which would allow me to extend the conversion formulas to 5th order). >> >> Is there anybody in astropy community who is planning to implement a >> method in WCS class for converting from SIP to PV projection? >> I would be more than happy to provide testing images. >> >> Thanks in advance, >> >> Octavi. >> >> -- >> Octavi Fors >> Postdoctoral Research Associate >> Department of Physics and Astronomy >> The University of North Carolina at Chapel Hill >> CB #3255, #157 Phillips Hall >> Chapel Hill, NC 27599 >> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> >> > > > -- > Octavi Fors > Postdoctoral Research Associate > Department of Physics and Astronomy > The University of North Carolina at Chapel Hill > CB #3255, #157 Phillips Hall > Chapel Hill, NC 27599 > Office: (919) 962-3606 > Fax: (919) 962-0480 > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -- Octavi Fors Postdoctoral Research Associate Department of Physics and Astronomy The University of North Carolina at Chapel Hill CB #3255, #157 Phillips Hall Chapel Hill, NC 27599 Office: (919) 962-3606 Fax: (919) 962-0480 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yg1991 at mail.ustc.edu.cn Fri Jul 25 14:25:55 2014 From: yg1991 at mail.ustc.edu.cn (Guang Yang) Date: Sat, 26 Jul 2014 02:25:55 +0800 (CST) Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion In-Reply-To: References: <23898009.928231406255626697.JavaMail.coremail@mailweb> <27272369.972181406297919493.JavaMail.coremail@mailweb> Message-ID: <32429160.977691406312755150.JavaMail.coremail@mailweb> Hi Octavi, Got it, but sorry that I don't know any tool can achieve this. Good luck, Guang -----Original email----- From: "Octavi Fors" Sent Time: Jul 26, 2014 2:19:21 AM To: "Astronomical Python mailing list" Cc: Subject: Re: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion Hi Guang, I don't want to work-around this on the SExtractor catalog level (via wcs-xy2rd in astrometry.net, xy2sky in WCSTools, or w.all_pix2world(x,y,1) in astropy, which I actually have working) since the astrometrically solved images must be shared with other users. These, as most of us, use SExtractor as photometry extractor engine. So, in my opinion, it is quite inefficient that they have to use the same catalog-based work-around solution instead of straight-forward using an already projection converted image (as David Shupe did in PTF). Hope it helps, Octavi. On Fri, Jul 25, 2014 at 10:18 AM, Guang Yang wrote: Hi Octavi, So, if my understanding is right, you want sextractor to detect the sources and transfrom their (x, y) to (ra, dec). Well, I think it's unnecessary to rely on sextractor to do the transformation. I mean, you can output the source position directly in (x, y) and transform the (x, y) to (ra, dec) via other tools, like, wcs-xy2rd in astrometry.net tools. Does that make sense? Thanks, Guang -----Original email----- From: "Octavi Fors" Sent Time: Jul 25, 2014 9:43:49 PM To: "Astronomical Python mailing list" Cc: Subject: Re: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion Hi Guang, I understand that wcs-resample requires a second (target) image file with the WCS you want to apply to the input image, which has different WCS projection. In my case, I only have one image with TAN--SIP projection (which SExtractor doesn't seem to understand), and my aim is to get an output image with the TAN PV_i_j projection (which is of one the projections SExtractor understands). Thanks, Octavi. On Thu, Jul 24, 2014 at 10:33 PM, Guang Yang wrote: Hi Octavi, The astrometry.net group has some related codes. ( http://astrometry.net/doc/readme.html#fits-utilities ) You may try wcs-resample in them, But I'm not sure it works for your case. Are you trying to correct astrometry of an image so that it matches well with another? If so, we can discuss this, since that's what I did last year. Thanks, Guang -----Original email----- From: "Octavi Fors" Sent Time: Jul 25, 2014 7:47:11 AM To:astropy at scipy.org Cc: Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion Dear all, I've been struggling with this for two weeks ago, but no luck so far. I'm getting the astrometry plate solution of images from a 40?x40? FoV camera-lens CCD with Astrometry.net 0.49, TAN--SIP projection, and *5th* order SIP distortion polynomials. If I overplot with ds9 the Tycho2 stars in the field in J2000 coordinates (Analysis->Catalogs->Optical->Tycho2 menu), the green circles match the positions of all the stars in the FoV. *However*, after running SExtractor 2.19.5 over the plate solved image, while the pixel coordinates (XWIN_IMAGE,YWIN_IMAGE) *do* match the stars, the precessed celestial (ALPHAWIN_J2000,DELTAWIN_J2000) ones *do not* (they show offsets of several arcmins). I've asked SExtractor developers if such software does support TAN--SIP WCS convertion. Still waiting, but my guess is it does not. So a TAN--SIP->TAN-PV projection converter is what I'm looking for. Caltech PTF team (see SPIE paper) made these SIP<->PV converters to 4th order (not to 5th order, which is what I need). For license issues, they can only release the binaries here , but not the source code (which would allow me to extend the conversion formulas to 5th order). Is there anybody in astropy community who is planning to implement a method in WCS class for converting from SIP to PV projection? I would be more than happy to provide testing images. Thanks in advance, Octavi. -- Octavi Fors Postdoctoral Research Associate Department of Physics and Astronomy The University of North Carolina at Chapel Hill CB #3255, #157 Phillips Hall Chapel Hill, NC 27599 _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -- Octavi Fors Postdoctoral Research Associate Department of Physics and Astronomy The University of North Carolina at Chapel Hill CB #3255, #157 Phillips Hall Chapel Hill, NC 27599 Office: (919) 962-3606 Fax: (919) 962-0480 _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -- Octavi Fors Postdoctoral Research Associate Department of Physics and Astronomy The University of North Carolina at Chapel Hill CB #3255, #157 Phillips Hall Chapel Hill, NC 27599 Office: (919) 962-3606 Fax: (919) 962-0480 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsci.perry at gmail.com Fri Jul 25 14:31:22 2014 From: stsci.perry at gmail.com (Perry Greenfield) Date: Fri, 25 Jul 2014 14:31:22 -0400 Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion In-Reply-To: References: <23898009.928231406255626697.JavaMail.coremail@mailweb> <27272369.972181406297919493.JavaMail.coremail@mailweb> Message-ID: <5F673006-C7D2-44A8-BFF9-BBD19811C5CF@gmail.com> So you are saying you want an equivalent WCS (equivalent in the sense the x,y-->ra,dec mapping is the same, but the underlying representation is different as FITS keywords go)? But not to actually resample the image? Perry On Jul 25, 2014, at 2:19 PM, Octavi Fors wrote: > Hi Guang, > > I don't want to work-around this on the SExtractor catalog level (via wcs-xy2rd in astrometry.net, xy2sky in WCSTools, or w.all_pix2world(x,y,1) in astropy, which I actually have working) since the astrometrically solved images must be shared with other users. These, as most of us, use SExtractor as photometry extractor engine. > So, in my opinion, it is quite inefficient that they have to use the same catalog-based work-around solution instead of straight-forward using an already projection converted image (as David Shupe did in PTF). > > Hope it helps, > > Octavi. > > > > On Fri, Jul 25, 2014 at 10:18 AM, Guang Yang wrote: > Hi Octavi, > > So, if my understanding is right, you want sextractor to detect the sources and transfrom their (x, y) to (ra, dec). Well, I think it's unnecessary to rely on sextractor to do the transformation. I mean, you can output the source position directly in (x, y) and transform the (x, y) to (ra, dec) via other tools, like, wcs-xy2rd in astrometry.net tools. Does that make sense? > > Thanks, > Guang > > > -----Original email----- > From: "Octavi Fors" > Sent Time: Jul 25, 2014 9:43:49 PM > To: "Astronomical Python mailing list" > Cc: > Subject: Re: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion > > > Hi Guang, > > I understand that wcs-resample requires a second (target) image file with the WCS you want to apply to the input image, which has different WCS projection. > > In my case, I only have one image with TAN--SIP projection (which SExtractor doesn't seem to understand), and my aim is to get an output image with the TAN PV_i_j projection (which is of one the projections SExtractor understands). > > Thanks, > > Octavi. > > > > On Thu, Jul 24, 2014 at 10:33 PM, Guang Yang wrote: > Hi Octavi, > > The astrometry.net group has some related codes. ( http://astrometry.net/doc/readme.html#fits-utilities ) You may try wcs-resample in them, But I'm not sure it works for your case. > > Are you trying to correct astrometry of an image so that it matches well with another? If so, we can discuss this, since that's what I did last year. > > Thanks, > Guang > > > -----Original email----- > From: "Octavi Fors" > Sent Time: Jul 25, 2014 7:47:11 AM > To: astropy at scipy.org > Cc: > Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion > > > Dear all, > > I've been struggling with this for two weeks ago, but no luck so far. > > I'm getting the astrometry plate solution of images from a 40?x40? FoV camera-lens CCD with Astrometry.net 0.49, TAN--SIP projection, and *5th* order SIP distortion polynomials. > > If I overplot with ds9 the Tycho2 stars in the field in J2000 coordinates (Analysis->Catalogs->Optical->Tycho2 menu), the green circles match the positions of all the stars in the FoV. > > *However*, after running SExtractor 2.19.5 over the plate solved image, while the pixel coordinates (XWIN_IMAGE,YWIN_IMAGE) *do* match the stars, the precessed celestial (ALPHAWIN_J2000,DELTAWIN_J2000) ones *do not* (they show offsets of several arcmins). > > I've asked SExtractor developers if such software does support TAN--SIP WCS convertion. Still waiting, but my guess is it does not. > > So a TAN--SIP->TAN-PV projection converter is what I'm looking for. > > Caltech PTF team (see SPIE paper) made these SIP<->PV converters to 4th order (not to 5th order, which is what I need). For license issues, they can only release the binaries here , but not the source code (which would allow me to extend the conversion formulas to 5th order). > > Is there anybody in astropy community who is planning to implement a method in WCS class for converting from SIP to PV projection? > I would be more than happy to provide testing images. > > Thanks in advance, > > Octavi. > > -- > Octavi Fors > Postdoctoral Research Associate > Department of Physics and Astronomy > The University of North Carolina at Chapel Hill > CB #3255, #157 Phillips Hall > Chapel Hill, NC 27599 > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > > > -- > Octavi Fors > Postdoctoral Research Associate > Department of Physics and Astronomy > The University of North Carolina at Chapel Hill > CB #3255, #157 Phillips Hall > Chapel Hill, NC 27599 > Office: (919) 962-3606 > Fax: (919) 962-0480 > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > > > -- > Octavi Fors > Postdoctoral Research Associate > Department of Physics and Astronomy > The University of North Carolina at Chapel Hill > CB #3255, #157 Phillips Hall > Chapel Hill, NC 27599 > Office: (919) 962-3606 > Fax: (919) 962-0480 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From octavi at live.unc.edu Fri Jul 25 15:38:32 2014 From: octavi at live.unc.edu (Octavi Fors) Date: Fri, 25 Jul 2014 15:38:32 -0400 Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion In-Reply-To: <5F673006-C7D2-44A8-BFF9-BBD19811C5CF@gmail.com> References: <23898009.928231406255626697.JavaMail.coremail@mailweb> <27272369.972181406297919493.JavaMail.coremail@mailweb> <5F673006-C7D2-44A8-BFF9-BBD19811C5CF@gmail.com> Message-ID: Hi Peter, yes, I want to have a second set of images with a different WCS geometric distorsion (TAN PV instead TAN--SIP). But not to actually resample the image? > no, we don't need and actually should not resample the image. I found this paragraph in David Shupe's SPIE paper that exactly matches the same reasons we prefer not to resample: "First, it is critical to preserve the individual images without remapping onto a sky grid, to best provide the ability to detect and measure transient events. Second, for PTF, and any ground-based observatory, the distortion solution changes from one exposure to the next owing to atmospheric refraction. These challenges make it necessary not only for the PTF pipelines to efficiently compute the astrometry and the distortion solution, but also for the resulting data products to be compatible with as many tools as possible." Cheers, Octavi. On Fri, Jul 25, 2014 at 2:31 PM, Perry Greenfield wrote: > So you are saying you want an equivalent WCS (equivalent in the sense the > x,y-->ra,dec mapping is the same, but the underlying representation is > different as FITS keywords go)? But not to actually resample the image? > > Perry > > On Jul 25, 2014, at 2:19 PM, Octavi Fors wrote: > > > Hi Guang, > > > > I don't want to work-around this on the SExtractor catalog level (via > wcs-xy2rd in astrometry.net, xy2sky in WCSTools, or > w.all_pix2world(x,y,1) in astropy, which I actually have working) since the > astrometrically solved images must be shared with other users. These, as > most of us, use SExtractor as photometry extractor engine. > > So, in my opinion, it is quite inefficient that they have to use the > same catalog-based work-around solution instead of straight-forward using > an already projection converted image (as David Shupe did in PTF). > > > > Hope it helps, > > > > Octavi. > > > > > > > > On Fri, Jul 25, 2014 at 10:18 AM, Guang Yang > wrote: > > Hi Octavi, > > > > So, if my understanding is right, you want sextractor to detect the > sources and transfrom their (x, y) to (ra, dec). Well, I think it's > unnecessary to rely on sextractor to do the transformation. I mean, you can > output the source position directly in (x, y) and transform the (x, y) to > (ra, dec) via other tools, like, wcs-xy2rd in astrometry.net tools. Does > that make sense? > > > > Thanks, > > Guang > > > > > > -----Original email----- > > From: "Octavi Fors" > > Sent Time: Jul 25, 2014 9:43:49 PM > > To: "Astronomical Python mailing list" > > Cc: > > Subject: Re: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion > > > > > > Hi Guang, > > > > I understand that wcs-resample requires a second (target) image file > with the WCS you want to apply to the input image, which has different WCS > projection. > > > > In my case, I only have one image with TAN--SIP projection (which > SExtractor doesn't seem to understand), and my aim is to get an output > image with the TAN PV_i_j projection (which is of one the projections > SExtractor understands). > > > > Thanks, > > > > Octavi. > > > > > > > > On Thu, Jul 24, 2014 at 10:33 PM, Guang Yang > wrote: > > Hi Octavi, > > > > The astrometry.net group has some related codes. ( > http://astrometry.net/doc/readme.html#fits-utilities ) You may try > wcs-resample in them, But I'm not sure it works for your case. > > > > Are you trying to correct astrometry of an image so that it matches well > with another? If so, we can discuss this, since that's what I did last year. > > > > Thanks, > > Guang > > > > > > -----Original email----- > > From: "Octavi Fors" > > Sent Time: Jul 25, 2014 7:47:11 AM > > To: astropy at scipy.org > > Cc: > > Subject: [AstroPy] TAN--SIP -> TAN PV WCS projection conversion > > > > > > Dear all, > > > > I've been struggling with this for two weeks ago, but no luck so far. > > > > I'm getting the astrometry plate solution of images from a 40?x40? FoV > camera-lens CCD with Astrometry.net 0.49, TAN--SIP projection, and *5th* > order SIP distortion polynomials. > > > > If I overplot with ds9 the Tycho2 stars in the field in J2000 > coordinates (Analysis->Catalogs->Optical->Tycho2 menu), the green circles > match the positions of all the stars in the FoV. > > > > *However*, after running SExtractor 2.19.5 over the plate solved image, > while the pixel coordinates (XWIN_IMAGE,YWIN_IMAGE) *do* match the stars, > the precessed celestial (ALPHAWIN_J2000,DELTAWIN_J2000) ones *do not* (they > show offsets of several arcmins). > > > > I've asked SExtractor developers if such software does support TAN--SIP > WCS convertion. Still waiting, but my guess is it does not. > > > > So a TAN--SIP->TAN-PV projection converter is what I'm looking for. > > > > Caltech PTF team (see SPIE paper) made these SIP<->PV converters to 4th > order (not to 5th order, which is what I need). For license issues, they > can only release the binaries here , but not the source code (which would > allow me to extend the conversion formulas to 5th order). > > > > Is there anybody in astropy community who is planning to implement a > method in WCS class for converting from SIP to PV projection? > > I would be more than happy to provide testing images. > > > > Thanks in advance, > > > > Octavi. > > > > -- > > Octavi Fors > > Postdoctoral Research Associate > > Department of Physics and Astronomy > > The University of North Carolina at Chapel Hill > > CB #3255, #157 Phillips Hall > > Chapel Hill, NC 27599 > > > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > > > > > -- > > Octavi Fors > > Postdoctoral Research Associate > > Department of Physics and Astronomy > > The University of North Carolina at Chapel Hill > > CB #3255, #157 Phillips Hall > > Chapel Hill, NC 27599 > > Office: (919) 962-3606 > > Fax: (919) 962-0480 > > > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > http://mail.scipy.org/mailman/listinfo/astropy > > > > > > > > > > -- > > Octavi Fors > > Postdoctoral Research Associate > > Department of Physics and Astronomy > > The University of North Carolina at Chapel Hill > > CB #3255, #157 Phillips Hall > > Chapel Hill, NC 27599 > > Office: (919) 962-3606 > > Fax: (919) 962-0480 > > _______________________________________________ > > 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 > -- Octavi Fors Postdoctoral Research Associate Department of Physics and Astronomy The University of North Carolina at Chapel Hill CB #3255, #157 Phillips Hall Chapel Hill, NC 27599 Office: (919) 962-3606 Fax: (919) 962-0480 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pweilbacher at aip.de Sat Jul 26 02:28:05 2014 From: pweilbacher at aip.de (Peter Weilbacher) Date: Sat, 26 Jul 2014 08:28:05 +0200 (CEST) Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <53D23889.6050807@gmail.com> References: <7203702.775961406052856075.JavaMail.coremail@mailweb> <53D23889.6050807@gmail.com> Message-ID: On Fri, 25 Jul 2014, Thomas Robitaille wrote: > For the unit, the issue is that ``ct`` is not a valid unit according to > the FITS standard. The 'correct' unit for FITS is ``count``. Both are listed in Table 4 ("Additional allowed units") of the FITS Standard paper. So why do you think one is more valid than the other? Otherwise I totally agree that any self-invented unit (or even wrong capitalization) is bad for users (or parsers). Cheers, Peter. -- Dr. Peter Weilbacher http://www.aip.de/People/PWeilbacher Phone +49 331 74 99-667 encryption key ID 7D6B4AA0 ------------------------------------------------------------------------ Leibniz-Institut f?r Astrophysik Potsdam (AIP) An der Sternwarte 16, D-14482 Potsdam Vorstand: Prof. Dr. Matthias Steinmetz, Dr. Ulrich M?ller Stiftung b?rgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026 From indiajoe at gmail.com Mon Jul 28 03:06:09 2014 From: indiajoe at gmail.com (Joe Philip Ninan) Date: Mon, 28 Jul 2014 12:36:09 +0530 Subject: [AstroPy] Adding new database in astropy.vo conesearch Message-ID: Hi, Is there any documentation available on how to add a database into astropy's vo conesearch client which is not already there is the conesearch_good/warn/exception/error? If i understand correctly, one needs to build a JSON database with the required access VO url. PS: WISE catalog is the missing catalog which we are trying to add. -cheers joe -- /--------------------------------------------------------------- "GNU/Linux: because a PC is a terrible thing to waste" - GNU Generation ************************************************ Joe Philip Ninan Research Scholar /________________\ DAA, | Vadakeparambil | TIFR, | Pullad P.O. | Mumbai-05, India. | Kerala, India | Ph: +917738438212 | PIN:689548 | ------------------------------\_______________/-------------- My GnuPG Public Key: https://sites.google.com/site/jpninan/index-html/aboutmehtml/JPN_public.key?attredirects=0&d=1 From mdroe at stsci.edu Mon Jul 28 10:28:14 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Mon, 28 Jul 2014 10:28:14 -0400 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: References: <7203702.775961406052856075.JavaMail.coremail@mailweb> <53D23889.6050807@gmail.com> Message-ID: <53D65DFE.7020606@stsci.edu> Indeed, you are correct about the standard. I think missing ``ct`` is just an oversight. I've added this to http://github.com/astropy/astropy/pull/2798. Would you mind confirming that that PR addresses your original issue? Cheers, Mike On 07/26/2014 02:28 AM, Peter Weilbacher wrote: > On Fri, 25 Jul 2014, Thomas Robitaille wrote: > >> For the unit, the issue is that ``ct`` is not a valid unit according to >> the FITS standard. The 'correct' unit for FITS is ``count``. > Both are listed in Table 4 ("Additional allowed units") of the FITS > Standard paper. So why do you think one is more valid than the other? > > Otherwise I totally agree that any self-invented unit (or even wrong > capitalization) is bad for users (or parsers). > > Cheers, > Peter. -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com From embray at stsci.edu Mon Jul 28 10:59:45 2014 From: embray at stsci.edu (Erik Bray) Date: Mon, 28 Jul 2014 10:59:45 -0400 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> Message-ID: <53D66561.3090808@stsci.edu> On 07/25/2014 09:10 AM, Derek Homeier wrote: > On 25 Jul 2014, at 03:00 pm, Peter Williams wrote: > >> If there's a resource out there that gives a clear summary of allowed >> FITS units, the AstroPy error message should point people to it. > > On reading it even gives suggestions for the correct keyword; I have not looked up where > exactly this is issued, but it should be straightforward to add other common misnomers there > (and extend the suggestion to the write call). > But there seem to be different levels of what deviations from the standard are tolerated? > The following is silently written back to a new FITS file (with the units unchanged, astropy 0.4): > > vega = apt.Table.read('ftp://ftp.stsci.edu/cdbs/calspec/alpha_lyr_stis_007.fits') > WARNING: UnitsWarning: 'ANGSTROMS' did not parse as fits unit: At col 0, Unit 'ANGSTROMS' not supported by the FITS standard. Did you mean Angstrom or angstrom? [astropy.units.core] > WARNING: UnitsWarning: 'FLAM' did not parse as fits unit: At col 0, Unit 'FLAM' not supported by the FITS standard. Did you mean flm? [astropy.units.core] > WARNING: UnitsWarning: 'NONE' did not parse as fits unit: At col 0, Unit 'NONE' not supported by the FITS standard. [astropy.units.core] > WARNING: UnitsWarning: 'SEC' did not parse as fits unit: At col 0, Unit 'SEC' not supported by the FITS standard. Did you mean EC? [astropy.units.core] Units, like most things in FITS, are broken. This is due to a couple things: Lack of software that supports units in the first place, and the fact that people edit FITS files by hand without software that forces them to choose from a standard list of unit strings, and without running the resulting file through any manner of validation software. The best we can do then is inform the user when invalid unit strings are found and suggest *possible* alternatives. The matching for alternatives is a fairly general heuristic and not based on any real world "common" misspellings. So it's just a guess. Furthermore due to its brokenness FITS has developed all manner of local conventions that simply must be adhered to at the very least for existing files. So with the possible exception of fundamentally broken files (that don't even adhere to the correct binary format) the preference should almost always be to write back out what was already in there. Erik From p3y1i4n at gmail.com Mon Jul 28 16:29:44 2014 From: p3y1i4n at gmail.com (Pey Lian Lim) Date: Mon, 28 Jul 2014 16:29:44 -0400 Subject: [AstroPy] Adding new database in astropy.vo conesearch Message-ID: Hi Joe, To use your own service for Cone Search (just for your own use, not for general astropy installation): http://docs.astropy.org/en/stable/vo/conesearch/client.html#database-manipulation You might also find the example in the third last message of this thread helpful: https://github.com/astropy/astropy/issues/1206 However, if you want your WISE catalog to be part of the STScI nightly validation that is used by astropy by default, it needs to be added to astropy.vo via a pull request. It also needs to be already registered with STScI VAO registry (http://vao.stsci.edu/). For this, it is easiest to contact STScI Help Desk at help[at]stsci.edu. Sincerely, Pey-Lian From indiajoe at gmail.com Tue Jul 29 07:35:58 2014 From: indiajoe at gmail.com (Joe Philip Ninan) Date: Tue, 29 Jul 2014 17:05:58 +0530 Subject: [AstroPy] Adding new database in astropy.vo conesearch In-Reply-To: References: Message-ID: Hi Pey Lian, Thanks a lot for the links. We shall try the example in github thread. -cheers joe On 29 July 2014 01:59, Pey Lian Lim wrote: > Hi Joe, > > To use your own service for Cone Search (just for your own use, not > for general astropy installation): > > http://docs.astropy.org/en/stable/vo/conesearch/client.html#database-manipulation > > You might also find the example in the third last message of this > thread helpful: > https://github.com/astropy/astropy/issues/1206 > > However, if you want your WISE catalog to be part of the STScI nightly > validation that is used by astropy by default, it needs to be added to > astropy.vo via a pull request. It also needs to be already registered > with STScI VAO registry (http://vao.stsci.edu/). For this, it is > easiest to contact STScI Help Desk at help[at]stsci.edu. > > Sincerely, > Pey-Lian > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- /--------------------------------------------------------------- "GNU/Linux: because a PC is a terrible thing to waste" - GNU Generation ************************************************ Joe Philip Ninan Research Scholar /________________\ DAA, | Vadakeparambil | TIFR, | Pullad P.O. | Mumbai-05, India. | Kerala, India | Ph: +917738438212 | PIN:689548 | ------------------------------\_______________/-------------- My GnuPG Public Key: https://sites.google.com/site/jpninan/index-html/aboutmehtml/JPN_public.key?attredirects=0&d=1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From crawford at saao.ac.za Tue Jul 29 10:29:04 2014 From: crawford at saao.ac.za (Steve Crawford) Date: Tue, 29 Jul 2014 16:29:04 +0200 (SAST) Subject: [AstroPy] ccdproc v0.2.0 released In-Reply-To: <1965511158.1291068.1406643179082.JavaMail.zimbra@saao.ac.za> Message-ID: <408523954.1292416.1406644144539.JavaMail.zimbra@saao.ac.za> Dear Colleagues, We are pleased to announce the release of the ccdproc package. All of the major features in the original API have been included into the packaging including basic reductions, combining, and transforming a CCDData object. The package is ready for testing and we are at a point to get feedback from different interested users on what it is useful, what needs to be changed, and what else is needed. Please post any comments or issues at https://github.com/astropy/ccdproc. For right now, the package can be downloaded in one of several ways including: pip: pip install ccdproc Downloading of the current tarball: https://pypi.python.org/packages/source/c/ccdproc/ccdproc-0.2.tar.gz Directly from the source: git clone https://github.com/astropy/ccdproc.git Ccdproc does require v0.4 of astropy, so please have installed the most recent version of astropy. Documentation describing the package is available here: http://ccdproc.readthedocs.org/en/latest/ In addition, an ipython notebook example for reducing a set of data is availalble here: http://ccdproc.readthedocs.org/en/latest/ccdproc/reduction_examples.html Please feel free to pass this message onto any colleagues who may be interested. We are still in the process of updating documentation and adding additional functionality, but any feedback or contributions would be greatly appreciated! Cheers Steve and Matt From pweilbacher at aip.de Tue Jul 29 13:17:02 2014 From: pweilbacher at aip.de (Peter Weilbacher) Date: Tue, 29 Jul 2014 19:17:02 +0200 (CEST) Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <53D66561.3090808@stsci.edu> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> <53D66561.3090808@stsci.edu> Message-ID: On Mon, 28 Jul 2014, Erik Bray wrote: > On 07/25/2014 09:10 AM, Derek Homeier wrote: > > On 25 Jul 2014, at 03:00 pm, Peter Williams wrote: > > > >> If there's a resource out there that gives a clear summary of allowed > >> FITS units, the AstroPy error message should point people to it. > > > > On reading it even gives suggestions for the correct keyword; I have not looked up where > > exactly this is issued, but it should be straightforward to add other common misnomers there > > (and extend the suggestion to the write call). > > But there seem to be different levels of what deviations from the standard are tolerated? > > The following is silently written back to a new FITS file (with the units unchanged, astropy 0.4): > > > > vega = apt.Table.read('ftp://ftp.stsci.edu/cdbs/calspec/alpha_lyr_stis_007.fits') > > WARNING: UnitsWarning: 'ANGSTROMS' did not parse as fits unit: At col 0, Unit 'ANGSTROMS' not supported by the FITS standard. Did you mean Angstrom or angstrom? [astropy.units.core] This suggestion is not completely right, is it? The FITS standard says "Note that, per IAU convention, case is significant throughout." and the table of allowed units only has the version "Angstrom". And as the other Peter already suggested, this already lengthy error message could be changed to read ... not supported by the FITS standard (see 2010A&A...524A..42P tables 3 to 5). > Units, like most things in FITS, are broken. Please stop that bashing of FITS until there is that great new format that would be so much better for everything. (At least I haven't seen anything like that.) > This is due to a couple things: > Lack of software that supports units in the first place, and the fact that > people edit FITS files by hand without software that forces them to choose from > a standard list of unit strings, and without running the resulting file through > any manner of validation software. So what you are saying is that /people/ (both users and software developers) are "broken". That I can agree with, and would not exclude myself. ;-) > The best we can do then is inform the user when invalid unit strings are found > and suggest *possible* alternatives. The matching for alternatives is a fairly > general heuristic and not based on any real world "common" misspellings. Yes, but why not? If you had an internal list of known bad unit usage, then it could correctly suggest e.g. "erg/s/cm**2/Angstrom" for "FLAM". I think that is what Derek was suggesting. If the misspelling is not in that list, you can still fall back to that general heuristic method. Cheers, Peter. -- Dr. Peter Weilbacher http://www.aip.de/People/PWeilbacher Phone +49 331 74 99-667 encryption key ID 7D6B4AA0 ------------------------------------------------------------------------ Leibniz-Institut f?r Astrophysik Potsdam (AIP) An der Sternwarte 16, D-14482 Potsdam Vorstand: Prof. Dr. Matthias Steinmetz, Dr. Ulrich M?ller Stiftung b?rgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026 From hodge at stsci.edu Tue Jul 29 14:32:58 2014 From: hodge at stsci.edu (Phil Hodge) Date: Tue, 29 Jul 2014 14:32:58 -0400 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> <53D66561.3090808@stsci.edu> Message-ID: <53D7E8DA.6010701@stsci.edu> On 07/29/2014 01:17 PM, Peter Weilbacher wrote: >>> vega = apt.Table.read('ftp://ftp.stsci.edu/cdbs/calspec/alpha_lyr_stis_007.fits') >>> > >WARNING: UnitsWarning: 'ANGSTROMS' did not parse as fits unit: At col 0, Unit 'ANGSTROMS' not supported by the FITS standard. Did you mean Angstrom or angstrom? [astropy.units.core] > This suggestion is not completely right, is it? The FITS standard says > "Note that, per IAU convention, case is significant throughout." > and the table of allowed units only has the version "Angstrom". And the unit is "angstrom", not "Angstrom", in spite of the FITS standard. Unit names in English are lower case. Unit abbreviations begin with an upper case letter if and only if the unit is named after a person (except L for liter is OK). See the AIP Style Manual, Table IV, for example, or The NIST Guide for the use of the International System of Units (http://www.nist.gov/pml/pubs/sp811/). The FITS standard doesn't have to be so rigid. Phil From David.Syphers at Colorado.EDU Tue Jul 29 15:34:39 2014 From: David.Syphers at Colorado.EDU (David Syphers) Date: Tue, 29 Jul 2014 13:34:39 -0600 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <53D7E8DA.6010701@stsci.edu> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> <53D66561.3090808@stsci.edu> <53D7E8DA.6010701@stsci.edu> Message-ID: <18CAC28B-2EDB-4921-A6D3-1B35832D8142@colorado.edu> On Jul 29, 2014, at 12:32 PM, Phil Hodge wrote: > On 07/29/2014 01:17 PM, Peter Weilbacher wrote: >>>> vega = apt.Table.read('ftp://ftp.stsci.edu/cdbs/calspec/alpha_lyr_stis_007.fits') >>>>>> WARNING: UnitsWarning: 'ANGSTROMS' did not parse as fits unit: At col 0, Unit 'ANGSTROMS' not supported by the FITS standard. Did you mean Angstrom or angstrom? [astropy.units.core] >> This suggestion is not completely right, is it? The FITS standard says >> "Note that, per IAU convention, case is significant throughout." >> and the table of allowed units only has the version "Angstrom". > > And the unit is "angstrom", not "Angstrom", in spite of the FITS > standard. Unit names in English are lower case. Unit abbreviations > begin with an upper case letter if and only if the unit is named after a > person Meet Anders Jonas ?ngstr?m: http://en.wikipedia.org/wiki/Anders_Jonas_%C3%85ngstr%C3%B6m -David From msk at astro.umd.edu Tue Jul 29 15:42:04 2014 From: msk at astro.umd.edu (Michael S. P. Kelley) Date: Tue, 29 Jul 2014 15:42:04 -0400 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <18CAC28B-2EDB-4921-A6D3-1B35832D8142@colorado.edu> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> <53D66561.3090808@stsci.edu> <53D7E8DA.6010701@stsci.edu> <18CAC28B-2EDB-4921-A6D3-1B35832D8142@colorado.edu> Message-ID: Thanks for that info. FYI, Here's essentially the same recommendation, but at the IAU: Quantity, Unit: Name, Symbol, Value length, angstrom, ?, 10^-10 m = 0.1 nm http://www.iau.org/publications/proceedings_rules/units/ Cheers, Mike On Tue, Jul 29, 2014 at 3:34 PM, David Syphers wrote: > On Jul 29, 2014, at 12:32 PM, Phil Hodge wrote: > >> On 07/29/2014 01:17 PM, Peter Weilbacher wrote: >>>>> vega = apt.Table.read('ftp://ftp.stsci.edu/cdbs/calspec/alpha_lyr_stis_007.fits') >>>>>>> WARNING: UnitsWarning: 'ANGSTROMS' did not parse as fits unit: At col 0, Unit 'ANGSTROMS' not supported by the FITS standard. Did you mean Angstrom or angstrom? [astropy.units.core] >>> This suggestion is not completely right, is it? The FITS standard says >>> "Note that, per IAU convention, case is significant throughout." >>> and the table of allowed units only has the version "Angstrom". >> >> And the unit is "angstrom", not "Angstrom", in spite of the FITS >> standard. Unit names in English are lower case. Unit abbreviations >> begin with an upper case letter if and only if the unit is named after a >> person > > Meet Anders Jonas ?ngstr?m: http://en.wikipedia.org/wiki/Anders_Jonas_%C3%85ngstr%C3%B6m > > -David From David.Syphers at Colorado.EDU Tue Jul 29 15:42:54 2014 From: David.Syphers at Colorado.EDU (David Syphers) Date: Tue, 29 Jul 2014 13:42:54 -0600 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <18CAC28B-2EDB-4921-A6D3-1B35832D8142@colorado.edu> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> <53D66561.3090808@stsci.edu> <53D7E8DA.6010701@stsci.edu> <18CAC28B-2EDB-4921-A6D3-1B35832D8142@colorado.edu> Message-ID: On Jul 29, 2014, at 1:34 PM, David Syphers wrote: > On Jul 29, 2014, at 12:32 PM, Phil Hodge wrote: > >> On 07/29/2014 01:17 PM, Peter Weilbacher wrote: >>>>> vega = apt.Table.read('ftp://ftp.stsci.edu/cdbs/calspec/alpha_lyr_stis_007.fits') >>>>>>> WARNING: UnitsWarning: 'ANGSTROMS' did not parse as fits unit: At col 0, Unit 'ANGSTROMS' not supported by the FITS standard. Did you mean Angstrom or angstrom? [astropy.units.core] >>> This suggestion is not completely right, is it? The FITS standard says >>> "Note that, per IAU convention, case is significant throughout." >>> and the table of allowed units only has the version "Angstrom". >> >> And the unit is "angstrom", not "Angstrom", in spite of the FITS >> standard. Unit names in English are lower case. Unit abbreviations >> begin with an upper case letter if and only if the unit is named after a >> person > > Meet Anders Jonas ?ngstr?m: http://en.wikipedia.org/wiki/Anders_Jonas_%C3%85ngstr%C3%B6m Um, sorry, ignore the idiot who conflated "unit names" with "unit abbreviations". Still, go meet Anders. Worth knowing him. -David From hodge at stsci.edu Tue Jul 29 15:39:52 2014 From: hodge at stsci.edu (Phil Hodge) Date: Tue, 29 Jul 2014 15:39:52 -0400 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <18CAC28B-2EDB-4921-A6D3-1B35832D8142@colorado.edu> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> <53D66561.3090808@stsci.edu> <53D7E8DA.6010701@stsci.edu> <18CAC28B-2EDB-4921-A6D3-1B35832D8142@colorado.edu> Message-ID: <53D7F888.70904@stsci.edu> On 07/29/2014 03:34 PM, David Syphers wrote: > Meet Anders Jonas ?ngstr?m:http://en.wikipedia.org/wiki/Anders_Jonas_%C3%85ngstr%C3%B6m It's the abbreviation, not the full unit name, that begins with (or is) an upper case letter if the unit is named for a person. Phil From thomas.robitaille at gmail.com Tue Jul 29 17:21:38 2014 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 29 Jul 2014 22:21:38 +0100 Subject: [AstroPy] Transforming an image into polar coordinates and back to cartesian In-Reply-To: <17423714-A683-41BD-B4F9-90C1D14BF07F@gmail.com> References: <17423714-A683-41BD-B4F9-90C1D14BF07F@gmail.com> Message-ID: <53D81062.4030406@gmail.com> Hi Maria, The scipy map_coordinates function might help you do what you need: http://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.interpolation.map_coordinates.html You can use it to reproject from cartesian to polar using interpolation, then interpolate it back to cartesian. Cheers, Tom Maria de Juan Ovelar wrote: > Dear all, > > I want to transform an image (array) into polar coordinates, operate on it and transform it back to cartesian. I found an entry on the stackoverflow forum with some ideas but I can't manage to recover the image in cartesian properly using those recipes...Is there any scipy or astropy function that can help? > > Thanks! > Maria > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From derek at astro.physik.uni-goettingen.de Tue Jul 29 17:43:09 2014 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Tue, 29 Jul 2014 23:43:09 +0200 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <53D7F888.70904@stsci.edu> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> <53D66561.3090808@stsci.edu> <53D7E8DA.6010701@stsci.edu> <18CAC28B-2EDB-4921-A6D3-1B35832D8142@colorado.edu> <53D7F888.70904@stsci.edu> Message-ID: <373AD7D4-D5AB-484E-BFCD-28D5289BA012@astro.physik.uni-goettingen.de> On 29 Jul 2014, at 09:39 pm, Phil Hodge wrote: >> Meet Anders Jonas ?ngstr?m:http://en.wikipedia.org/wiki/Anders_Jonas_%C3%85ngstr%C3%B6m > > It's the abbreviation, not the full unit name, that begins with (or is) > an upper case letter if the unit is named for a person. As with newton or kelvin? But that leads a bit astray from the original problem. I certainly think capitalisation variants should be tolerated, and specifically for FITS I wonder if it even makes sense to raise a warning, as I have hardly seen any real life FITS header that was not FORTRAN 6-style fully capitalised. The example I gave was about angstroms, which is arguably poor language and even unnecessarily creates a >8 character keyword, and ?units? like ?FLAM? which are of course of relatively limited use. My original point was if/why one could not offer similar suggestions for correct units in the case of ?ct? instead of ?counts?, but as Erik has clarified these suggestions are simply heuristic guesses from utils.misc.did_you_mean. Therefore it could not come up with a useful replacement for FLAM (and even a truly smart algorithm or complete lexicographic database would have no way to tell whether to suggest erg/s/cm**2/A, erg/s/cm**2/cm, W/m**2/um? An interesting note btw. is that angstrom or Angstrom are listed in units.format.fits among deprecated_units; however Fits is initialising its ._units from the union of units and deprecated_units, and the ._deprecated_units from the union of deprecated_names and deprecated_units. That?s why angstrom is even suggested as a replacement; not sure about the exact logic behind this. Cheers, Derek From ramberg at yahoo.com Wed Jul 30 10:14:20 2014 From: ramberg at yahoo.com (Jim Ramberg) Date: Wed, 30 Jul 2014 07:14:20 -0700 Subject: [AstroPy] OSX issues with the location of gfortran Message-ID: Hello: Recent releases of OSX has gfortran being moved to the gcc package. So astropy tests that have a preset path for gfortran are failing Here is one of the errors I see: /Users/ramberg/astropy/docs/convolution/kernels.rst:304: UnexpectedException __________________________________________________________________________ [doctest] index.rst __________________________________________________________________________ 023 Hubble constant at z=0 (i.e., ``H0``), and the number of transverse proper 024 kpc corresponding to an arcminute at z=3:: 025 026 >>> from astropy.cosmology import WMAP9 as cosmo 027 >>> cosmo.H(0) # doctest: +FLOAT_CMP 028 029 030 .. doctest-requires:: scipy 031 032 >>> cosmo.kpc_proper_per_arcmin(3) # doctest: +FLOAT_CMP UNEXPECTED EXCEPTION: ImportError('dlopen(/usr/local/lib/python2.7/site-packages/scipy/special/_uf uncs.so, 2): Library not loaded: /usr/local/Cellar/gfortran/4.8.1/gfortran/lib/libgfortran.3.dylib\n Referenced from: /usr/local/lib/python2.7/site-packages/scipy/special/_ufuncs.so\n Reason: image not found',) Traceback (most recent call last): I was wondering if there is a workaround for this or should I just create a symlink The correct location on my system is: /usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/i386/l ibgfortran.3.dylib I am running osx mavericks. Thanks Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From deil.christoph at googlemail.com Wed Jul 30 10:24:46 2014 From: deil.christoph at googlemail.com (Christoph Deil) Date: Wed, 30 Jul 2014 16:24:46 +0200 Subject: [AstroPy] OSX issues with the location of gfortran In-Reply-To: References: Message-ID: <7275A092-C35E-4427-A027-B2E68A8EDB00@gmail.com> On 30 Jul 2014, at 16:14, Jim Ramberg wrote: > Hello: > Recent releases of OSX has gfortran being moved to the gcc package. So astropy tests that have a preset path for gfortran are failing > > Here is one of the errors I see: > > /Users/ramberg/astropy/docs/convolution/kernels.rst:304: UnexpectedException > __________________________________________________________________________ [doctest] index.rst __________________________________________________________________________ > 023 Hubble constant at z=0 (i.e., ``H0``), and the number of transverse proper > 024 kpc corresponding to an arcminute at z=3:: > 025 > 026 >>> from astropy.cosmology import WMAP9 as cosmo > 027 >>> cosmo.H(0) # doctest: +FLOAT_CMP > 028 > 029 > 030 .. doctest-requires:: scipy > 031 > 032 >>> cosmo.kpc_proper_per_arcmin(3) # doctest: +FLOAT_CMP > UNEXPECTED EXCEPTION: ImportError('dlopen(/usr/local/lib/python2.7/site-packages/scipy/special/_ufuncs.so, 2): Library not loaded: /usr/local/Cellar/gfortran/4.8.1/gfortran/lib/libgfortran.3.dylib\n Referenced from: /usr/local/lib/python2.7/site-packages/scipy/special/_ufuncs.so\n Reason: image not found',) > Traceback (most recent call last): > > > > I was wondering if there is a workaround for this or should I just create a symlink > The correct location on my system is: /usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/i386/libgfortran.3.dylib > > I am running osx mavericks. > > Thanks > Jim > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy Hi Jim, this looks like an installation issue of your libgfortran or scipy ? I guess already `import scipy.special` fails for you? From your console output I can see you used Homebrew (http://brew.sh/) to install libgfortran. I?m using Macports (http://www.macports.org/) to install libgfortran and scipy, so I don?t know how to resolve this installation issue. If you don?t get a useful reply on this Astropy mailing list, you might have more luck asking on the Homebrew or Scipy mailing list. Cheers, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbradley at stsci.edu Wed Jul 30 10:23:21 2014 From: lbradley at stsci.edu (Larry Bradley) Date: Wed, 30 Jul 2014 10:23:21 -0400 Subject: [AstroPy] OSX issues with the location of gfortran In-Reply-To: References: Message-ID: Hi Jim, It appears that your version of scipy is linked to the wrong gfortran library. It looks like you are using homebrew. If you updated gfortran or gcc then you need to re-compile/re-install scipy to find the correct libraries. Does 'import scipy' from python currently work? On Wed, Jul 30, 2014 at 10:14 AM, Jim Ramberg wrote: > Hello: > Recent releases of OSX has gfortran being moved to the gcc package. So > astropy tests that have a preset path for gfortran are failing > > Here is one of the errors I see: > > /Users/ramberg/astropy/docs/convolution/kernels.rst:304: UnexpectedException > __________________________________________________________________________ > [doctest] index.rst > __________________________________________________________________________ > 023 Hubble constant at z=0 (i.e., ``H0``), and the number of transverse > proper > 024 kpc corresponding to an arcminute at z=3:: > 025 > 026 >>> from astropy.cosmology import WMAP9 as cosmo > 027 >>> cosmo.H(0) # doctest: +FLOAT_CMP > 028 > 029 > 030 .. doctest-requires:: scipy > 031 > 032 >>> cosmo.kpc_proper_per_arcmin(3) # doctest: +FLOAT_CMP > UNEXPECTED EXCEPTION: > ImportError('dlopen(/usr/local/lib/python2.7/site-packages/scipy/special/_ufuncs.so, > 2): Library not loaded: > /usr/local/Cellar/gfortran/4.8.1/gfortran/lib/libgfortran.3.dylib\n > Referenced from: > /usr/local/lib/python2.7/site-packages/scipy/special/_ufuncs.so\n Reason: > image not found',) > Traceback (most recent call last): > > > > I was wondering if there is a workaround for this or should I just create a > symlink > The correct location on my system is: > /usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/i386/libgfortran.3.dylib > > I am running osx mavericks. > > Thanks > Jim > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From derek at astro.physik.uni-goettingen.de Wed Jul 30 10:30:33 2014 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Wed, 30 Jul 2014 16:30:33 +0200 Subject: [AstroPy] OSX issues with the location of gfortran In-Reply-To: References: Message-ID: <0A4DC30E-6EDC-4BF5-90CE-CBA2E4E79241@astro.physik.uni-goettingen.de> On 30 Jul 2014, at 04:14 pm, Jim Ramberg wrote: > Recent releases of OSX has gfortran being moved to the gcc package. So astropy tests that have a preset path for gfortran are failing > > Here is one of the errors I see: > > /Users/ramberg/astropy/docs/convolution/kernels.rst:304: UnexpectedException > __________________________________________________________________________ [doctest] index.rst __________________________________________________________________________ > 023 Hubble constant at z=0 (i.e., ``H0``), and the number of transverse proper > 024 kpc corresponding to an arcminute at z=3:: > 025 > 026 >>> from astropy.cosmology import WMAP9 as cosmo > 027 >>> cosmo.H(0) # doctest: +FLOAT_CMP > 028 > 029 > 030 .. doctest-requires:: scipy > 031 > 032 >>> cosmo.kpc_proper_per_arcmin(3) # doctest: +FLOAT_CMP > UNEXPECTED EXCEPTION: ImportError('dlopen(/usr/local/lib/python2.7/site-packages/scipy/special/_ufuncs.so, 2): Library not loaded: /usr/local/Cellar/gfortran/4.8.1/gfortran/lib/libgfortran.3.dylib\n Referenced from: /usr/local/lib/python2.7/site-packages/scipy/special/_ufuncs.so\n Reason: image not found',) > Traceback (most recent call last): > > > > I was wondering if there is a workaround for this or should I just create a symlink > The correct location on my system is: /usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/i386/libgfortran.3.dylib There is no gfortran included with the system-provided gcc (which is actually clang/LLVM), so it?s location depends on whatever additional gcc installation you are using, not on the OS X version - yours seems to be a rather exotic one. So the gfortran path should probably have been set at compile time of your astropy or scipy installation, wherever it found the working gfortran installation during 'setup.py build?. Creating the symlink might work around this, but a better solution would probably be to rebuild your scipy installation to make it aware of the changed gfortran paths (and build against the installed version, gcc-4.8.3, whereas yours apparently had originally been built agains 4.8.1). HTH, Derek From demitri.muna at gmail.com Wed Jul 30 11:34:23 2014 From: demitri.muna at gmail.com (Demitri Muna) Date: Wed, 30 Jul 2014 09:34:23 -0600 Subject: [AstroPy] OSX issues with the location of gfortran In-Reply-To: <0A4DC30E-6EDC-4BF5-90CE-CBA2E4E79241@astro.physik.uni-goettingen.de> References: <0A4DC30E-6EDC-4BF5-90CE-CBA2E4E79241@astro.physik.uni-goettingen.de> Message-ID: On Jul 30, 2014, at 8:30 AM, Derek Homeier wrote: > There is no gfortran included with the system-provided gcc (which is actually clang/LLVM), > so it?s location depends on whatever additional gcc installation you are using, not on the > OS X version - yours seems to be a rather exotic one. This is correct - I strongly suggest installing gfortran from this binary rather than Homebrew or the like. http://gcc.gnu.org/wiki/GFortranBinaries#MacOS _________________________________________ Demitri Muna Department of Astronomy Il Ohio State University http://scicoder.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramberg at yahoo.com Wed Jul 30 16:44:30 2014 From: ramberg at yahoo.com (Jim Ramberg) Date: Wed, 30 Jul 2014 13:44:30 -0700 Subject: [AstroPy] OSX issues with the location of gfortran In-Reply-To: <0A4DC30E-6EDC-4BF5-90CE-CBA2E4E79241@astro.physik.uni-goettingen.de> Message-ID: Just some clarifications: I am using homebrew ( which is becoming more and more popular) as my package manager under Mavericks . So himeko:astropy ramberg$ brew install gfortran Error: No available formula for gfortran GNU Fortran is now provided as part of GCC, and can be installed with: brew install gcc Other people reported the same issue on stackflow and the solution is to re-install scipy so it can compile the binaries using the correct version of gfortran. From what I was reading; it sounds like some libraries were checked in that shouldn't have been. The net result being all passed : platform darwin -- Python 2.7.8 -- pytest-2.5.1 Running tests with Astropy version 1.0.dev9525. Running tests in astropy /Users/ramberg/astropy/docs. Platform: Darwin-13.3.0-x86_64-i386-64bit Executable: /usr/local/opt/python/bin/python2.7 Full Python Version: 2.7.8 (default, Jul 30 2014, 08:54:34) [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] encodings: sys: ascii, locale: UTF-8, filesystem: utf-8, unicode bits: 15 byteorder: little float info: dig: 15, mant_dig: 15 Numpy: 1.8.1 Scipy: 0.14.0 Matplotlib: 1.3.1 h5py: 2.3.1 =============== 7747 passed, 121 skipped, 12 xfailed, 3 xpassed in 786.28 seconds ================ Thanks for the fast response time. Jim On 7/30/14, 7:30 AM, "Derek Homeier" wrote: > On 30 Jul 2014, at 04:14 pm, Jim Ramberg wrote: > >> Recent releases of OSX has gfortran being moved to the gcc package. So >> astropy tests that have a preset path for gfortran are failing >> >> Here is one of the errors I see: >> >> /Users/ramberg/astropy/docs/convolution/kernels.rst:304: UnexpectedException >> __________________________________________________________________________ >> [doctest] index.rst >> __________________________________________________________________________ >> 023 Hubble constant at z=0 (i.e., ``H0``), and the number of transverse >> proper >> 024 kpc corresponding to an arcminute at z=3:: >> 025 >> 026 >>> from astropy.cosmology import WMAP9 as cosmo >> 027 >>> cosmo.H(0) # doctest: +FLOAT_CMP >> 028 >> 029 >> 030 .. doctest-requires:: scipy >> 031 >> 032 >>> cosmo.kpc_proper_per_arcmin(3) # doctest: +FLOAT_CMP >> UNEXPECTED EXCEPTION: >> ImportError('dlopen(/usr/local/lib/python2.7/site-packages/scipy/special/_ufu >> ncs.so, 2): Library not loaded: >> /usr/local/Cellar/gfortran/4.8.1/gfortran/lib/libgfortran.3.dylib\n >> Referenced from: >> /usr/local/lib/python2.7/site-packages/scipy/special/_ufuncs.so\n Reason: >> image not found',) >> Traceback (most recent call last): >> >> >> >> I was wondering if there is a workaround for this or should I just create a >> symlink >> The correct location on my system is: >> /usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/i386/li >> bgfortran.3.dylib > > There is no gfortran included with the system-provided gcc (which is actually > clang/LLVM), > so it?s location depends on whatever additional gcc installation you are > using, not on the > OS X version - yours seems to be a rather exotic one. So the gfortran path > should probably > have been set at compile time of your astropy or scipy installation, wherever > it found the > working gfortran installation during 'setup.py build?. > Creating the symlink might work around this, but a better solution would > probably be to rebuild > your scipy installation to make it aware of the changed gfortran paths (and > build against the > installed version, gcc-4.8.3, whereas yours apparently had originally been > built agains 4.8.1). > > HTH, > Derek > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From mdroe at stsci.edu Thu Jul 31 09:51:33 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 31 Jul 2014 09:51:33 -0400 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <373AD7D4-D5AB-484E-BFCD-28D5289BA012@astro.physik.uni-goettingen.de> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> <53D66561.3090808@stsci.edu> <53D7E8DA.6010701@stsci.edu> <18CAC28B-2EDB-4921-A6D3-1B35832D8142@colorado.edu> <53D7F888.70904@stsci.edu> <373AD7D4-D5AB-484E-BFCD-28D5289BA012@astro.physik.uni-goettingen.de> Message-ID: <53DA49E5.7060403@stsci.edu> On 07/29/2014 05:43 PM, Derek Homeier wrote: > On 29 Jul 2014, at 09:39 pm, Phil Hodge wrote: > >>> Meet Anders Jonas ?ngstr?m:http://en.wikipedia.org/wiki/Anders_Jonas_%C3%85ngstr%C3%B6m >> It's the abbreviation, not the full unit name, that begins with (or is) >> an upper case letter if the unit is named for a person. > As with newton or kelvin? But that leads a bit astray from the original problem. > I certainly think capitalisation variants should be tolerated, The problem is that capitalization is meaningful in units. mm vs. Mm is an obvious one. > and specifically for > FITS I wonder if it even makes sense to raise a warning, as I have hardly seen > any real life FITS header that was not FORTRAN 6-style fully capitalised. > The example I gave was about angstroms, which is arguably poor language and > even unnecessarily creates a >8 character keyword, and ?units? like ?FLAM? which > are of course of relatively limited use. > My original point was if/why one could not offer similar suggestions for correct units > in the case of ?ct? instead of ?counts?, but as Erik has clarified these suggestions are > simply heuristic guesses from utils.misc.did_you_mean. > Therefore it could not come up with a useful replacement for FLAM (and even a > truly smart algorithm or complete lexicographic database would have no way to > tell whether to suggest erg/s/cm**2/A, erg/s/cm**2/cm, W/m**2/um? I?m not opposed to extending |did_you_mean| to include some hard-coded suggestions in addition to the current algorithm which is just based on string edit distance. If someone was willing to develop the mapping itself, I?m happy to work on the implementation. > An interesting note btw. is that angstrom or Angstrom are listed in units.format.fits among > deprecated_units; however Fits is initialising its ._units from the union of units and deprecated_units, > and the ._deprecated_units from the union of deprecated_names and deprecated_units. > That?s why angstrom is even suggested as a replacement; not sure about the exact logic > behind this. I?ll look into this. That logic may be broken. Mike > Cheers, > Derek > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Thu Jul 31 10:01:13 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 31 Jul 2014 10:01:13 -0400 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <53DA49E5.7060403@stsci.edu> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> <53D66561.3090808@stsci.edu> <53D7E8DA.6010701@stsci.edu> <18CAC28B-2EDB-4921-A6D3-1B35832D8142@colorado.edu> <53D7F888.70904@stsci.edu> <373AD7D4-D5AB-484E-BFCD-28D5289BA012@astro.physik.uni-goettingen.de> <53DA49E5.7060403@stsci.edu> Message-ID: <53DA4C29.50702@stsci.edu> On 07/31/2014 09:51 AM, Michael Droettboom wrote: > > On 07/29/2014 05:43 PM, Derek Homeier wrote: > >> On 29 Jul 2014, at 09:39 pm, Phil Hodge wrote: >> >>>> Meet Anders Jonas ?ngstr?m:http://en.wikipedia.org/wiki/Anders_Jonas_%C3%85ngstr%C3%B6m >>> It's the abbreviation, not the full unit name, that begins with (or is) >>> an upper case letter if the unit is named for a person. >> As with newton or kelvin... But that leads a bit astray from the original problem. >> I certainly think capitalisation variants should be tolerated, > > The problem is that capitalization is meaningful in units. mm vs. Mm > is an obvious one. > Sorry, I meant to add an even more problematic example. s (seconds) vs. S (Siemens) is another good one. wcslib provides flags to convert 'S' to 's' (since that's the more common usage), but that's just a mess. I *really* would prefer that files just said what they mean. We're in a growing pain period here, where many legacy FITS files have never used the units in a meaningful way before -- we're never going to get to a place where they are useful for calculation if we aren't strict about their specific meanings. Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Thu Jul 31 10:39:49 2014 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 31 Jul 2014 10:39:49 -0400 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> <53D66561.3090808@stsci.edu> Message-ID: <53DA5535.3000107@stsci.edu> On 07/29/2014 01:17 PM, Peter Weilbacher wrote: > >> Units, like most things in FITS, are broken. > Please stop that bashing of FITS until there is that great new format > that would be so much better for everything. (At least I haven't seen > anything like that.) It's not there yet, but we're working on it: http://asdf-standard.readthedocs.org/en/latest/ Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com From embray at stsci.edu Thu Jul 31 10:54:11 2014 From: embray at stsci.edu (Erik Bray) Date: Thu, 31 Jul 2014 10:54:11 -0400 Subject: [AstroPy] Need Help about Astropy.table.Table.write In-Reply-To: <53DA5535.3000107@stsci.edu> References: <53D24B5F.7010804@astro.umd.edu> <53D23889.6050807@gmail.com> <7203702.775961406052856075.JavaMail.coremail@mailweb> <22638082.966731406290068860.JavaMail.coremail@mailweb> <1466815.967341406291311814.JavaMail.coremail@mailweb> <1406293210.2874.4.camel@iota.localdomain> <53D66561.3090808@stsci.edu> <53DA5535.3000107@stsci.edu> Message-ID: <53DA5893.7090405@stsci.edu> On 07/31/2014 10:39 AM, Michael Droettboom wrote: > On 07/29/2014 01:17 PM, Peter Weilbacher wrote: >> >>> Units, like most things in FITS, are broken. >> Please stop that bashing of FITS until there is that great new format >> that would be so much better for everything. (At least I haven't seen >> anything like that.) > > It's not there yet, but we're working on it: > > http://asdf-standard.readthedocs.org/en/latest/ Nevermind that I would argue there are already many better data formats than FITS. The trick is to just find one everyone can agree on and not become to Balkanized. Though my comment really had mode to do laxness with which FITS files have been treated historically--a problem which is certainly not helped by the format's inherent limitations. Erik