From thomas.robitaille at gmail.com  Wed Oct  2 10:14:20 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Wed, 2 Oct 2013 16:14:20 +0200
Subject: [AstroPy] Final version of Astropy paper published online (and
 acknowledging software in papers)
Message-ID: <CAGMHX_07Dy0YVyfp3bF9ZTdoEuARpR7cPsD8E_kNLZ2xc5uXLw@mail.gmail.com>

Hi everyone,

This is just to let you know that the final version of Astropy was
published by A&A this week:

A&A: http://www.aanda.org/articles/aa/abs/2013/10/aa22068-13/aa22068-13.html

ADS: http://adsabs.harvard.edu/abs/2013A%26A...558A..33A

If you use Astropy directly - or as a dependency to another package -
for your work, please remember if possible to acknowledge the use of
Astropy at the end of papers using the following acknowledgment:

"This research made use of Astropy, a community-developed core Python
package for Astronomy (Astropy Collaboration, 2013)."

including the reference to the above paper. Please also make sure that
you ask people at your institution who are not on this list to
acknowledge Astropy, as well as any other software they use.

Related to this, I just posted about software (and other)
acknowledgments in my blog:

http://astrofrog.github.io/blog/2013/10/02/acknowledging-tools-services-in-papers/

>From searching through ADS, it's clear that we are not acknowledging
the tools we should be acknowledging - let's try and change this, to
ensure that the many developers who volunteer on open source projects
get the credit they deserve!

The AstroBetter wiki is trying to collect all acknowledgments:

http://www.astrobetter.com/wiki/tiki-index.php?page=Acknowledgements

If you develop a package and would like people to acknowledge it in
papers, please add it to the above page!

Thanks,
Tom


From iafe.leticia at gmail.com  Wed Oct  2 10:19:27 2013
From: iafe.leticia at gmail.com (Leticia Rodriguez)
Date: Wed, 2 Oct 2013 11:19:27 -0300
Subject: [AstroPy] Fwd: Help with encoding error
In-Reply-To: <CADiMhquxrez664gee-XsXLPur9coucnc7GczEoAq7yC+BbpmwQ@mail.gmail.com>
References: <CADiMhquxrez664gee-XsXLPur9coucnc7GczEoAq7yC+BbpmwQ@mail.gmail.com>
Message-ID: <CADiMhquP=C18YTy-+aKW0KdJ2-nyTrtNtkMcC+8-GVpShm3eHQ@mail.gmail.com>

Hi,

I want to use the "?" character in a fit header. The verify in astropy is
giving me an error.

WARNING: VerifyWarning:         Card 'OBSERVER' is not FITS standard
(invalid value string: 'Maria Rosa Mu?oz ').  Fixed 'OBSERVER' card to meet
the FITS standard. [astropy.io.fits.verify]
ERROR: UnicodeDecodeError: 'ascii' codec can't decode byte 0xf1 in position
1946: ordinal not in range(128) [astropy.io.fits.header]
Traceback (most recent call last):
  File "./fixfitheader.py", line 30, in <module>
    hdulist.writeto(sys.argv[2]+'/'+filename, output_verify='fix')
  File
"/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/hdulist.py",
line 675, in writeto
    hdu._writeto(hdulist.__file)
  File
"/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/base.py", line
497, in _writeto
    self._writeheader(fileobj)
  File
"/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/base.py", line
428, in _writeheader
    self._header.tofile(fileobj)
  File "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/header.py",
line 625, in tofile
    fileobj.write(blocks.encode('ascii'))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf1 in position 1946:
ordinal not in range(128)

Is there a solution for this issue?

Thanks.
BR
Leticia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131002/a6ca029e/attachment.html>

From stsci.perry at gmail.com  Wed Oct  2 10:34:11 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Wed, 2 Oct 2013 10:34:11 -0400
Subject: [AstroPy] Fwd: Help with encoding error
In-Reply-To: <CADiMhquP=C18YTy-+aKW0KdJ2-nyTrtNtkMcC+8-GVpShm3eHQ@mail.gmail.com>
References: <CADiMhquxrez664gee-XsXLPur9coucnc7GczEoAq7yC+BbpmwQ@mail.gmail.com>
	<CADiMhquP=C18YTy-+aKW0KdJ2-nyTrtNtkMcC+8-GVpShm3eHQ@mail.gmail.com>
Message-ID: <DBC718EF-6FDC-4A01-A558-85E6CE365650@gmail.com>


On Oct 2, 2013, at 10:19 AM, Leticia Rodriguez wrote:

> Hi,
> 
> I want to use the "?" character in a fit header. The verify in astropy is giving me an error.
> 
> WARNING: VerifyWarning:         Card 'OBSERVER' is not FITS standard (invalid value string: 'Maria Rosa Mu?oz ').  Fixed 'OBSERVER' card to meet the FITS standard. [astropy.io.fits.verify]
> ERROR: UnicodeDecodeError: 'ascii' codec can't decode byte 0xf1 in position 1946: ordinal not in range(128) [astropy.io.fits.header]
> Traceback (most recent call last):
>   File "./fixfitheader.py", line 30, in <module>
>     hdulist.writeto(sys.argv[2]+'/'+filename, output_verify='fix')
>   File "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/hdulist.py", line 675, in writeto
>     hdu._writeto(hdulist.__file)
>   File "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/base.py", line 497, in _writeto
>     self._writeheader(fileobj)
>   File "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/base.py", line 428, in _writeheader
>     self._header.tofile(fileobj)
>   File "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/header.py", line 625, in tofile
>     fileobj.write(blocks.encode('ascii'))
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf1 in position 1946: ordinal not in range(128)
> 
> Is there a solution for this issue?
> 
Yes, don't use FITS. :-) But seriously, here's what the FITS standard says about headers:

3.2. Individual FITS Structures

The primary HDU and every extension HDU shall consist of one or more 2880-byte header blocks immediately followed by an optional sequence of associated 2880-byte data blocks. The header blocks shall contain only the restricted set of ASCII text characters, decimal 32 through 126 (hexadecimal 20 through 7E). The ASCII control characters with decimal values less than 32 (including the null, tab, carriage return, and line feed characters), and the delete character (decimal 127 or hexadecimal 7F) must not appear anywhere within a header block

So basically, the character you want is illegal in a FITS header. So no, there isn't a simple solution.

Perry



From iafe.leticia at gmail.com  Wed Oct  2 10:37:45 2013
From: iafe.leticia at gmail.com (Leticia Rodriguez)
Date: Wed, 2 Oct 2013 11:37:45 -0300
Subject: [AstroPy] Fwd: Help with encoding error
In-Reply-To: <DBC718EF-6FDC-4A01-A558-85E6CE365650@gmail.com>
References: <CADiMhquxrez664gee-XsXLPur9coucnc7GczEoAq7yC+BbpmwQ@mail.gmail.com>
	<CADiMhquP=C18YTy-+aKW0KdJ2-nyTrtNtkMcC+8-GVpShm3eHQ@mail.gmail.com>
	<DBC718EF-6FDC-4A01-A558-85E6CE365650@gmail.com>
Message-ID: <CADiMhqukP629aCS_FgE+PrX+xmVhutvcC6TUhpVPYVoFeGmyaQ@mail.gmail.com>

Thanks for all the answers.

Leticia.


2013/10/2 Perry Greenfield <stsci.perry at gmail.com>

>
> On Oct 2, 2013, at 10:19 AM, Leticia Rodriguez wrote:
>
> > Hi,
> >
> > I want to use the "?" character in a fit header. The verify in astropy
> is giving me an error.
> >
> > WARNING: VerifyWarning:         Card 'OBSERVER' is not FITS standard
> (invalid value string: 'Maria Rosa Mu?oz ').  Fixed 'OBSERVER' card to meet
> the FITS standard. [astropy.io.fits.verify]
> > ERROR: UnicodeDecodeError: 'ascii' codec can't decode byte 0xf1 in
> position 1946: ordinal not in range(128) [astropy.io.fits.header]
> > Traceback (most recent call last):
> >   File "./fixfitheader.py", line 30, in <module>
> >     hdulist.writeto(sys.argv[2]+'/'+filename, output_verify='fix')
> >   File
> "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/hdulist.py",
> line 675, in writeto
> >     hdu._writeto(hdulist.__file)
> >   File
> "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/base.py", line
> 497, in _writeto
> >     self._writeheader(fileobj)
> >   File
> "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/base.py", line
> 428, in _writeheader
> >     self._header.tofile(fileobj)
> >   File
> "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/header.py", line
> 625, in tofile
> >     fileobj.write(blocks.encode('ascii'))
> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xf1 in position
> 1946: ordinal not in range(128)
> >
> > Is there a solution for this issue?
> >
> Yes, don't use FITS. :-) But seriously, here's what the FITS standard says
> about headers:
>
> 3.2. Individual FITS Structures
>
> The primary HDU and every extension HDU shall consist of one or more
> 2880-byte header blocks immediately followed by an optional sequence of
> associated 2880-byte data blocks. The header blocks shall contain only the
> restricted set of ASCII text characters, decimal 32 through 126
> (hexadecimal 20 through 7E). The ASCII control characters with decimal
> values less than 32 (including the null, tab, carriage return, and line
> feed characters), and the delete character (decimal 127 or hexadecimal 7F)
> must not appear anywhere within a header block
>
> So basically, the character you want is illegal in a FITS header. So no,
> there isn't a simple solution.
>
> Perry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131002/b7528bad/attachment.html>

From embray at stsci.edu  Mon Oct  7 18:12:33 2013
From: embray at stsci.edu (Erik Bray)
Date: Mon, 7 Oct 2013 18:12:33 -0400
Subject: [AstroPy] Fwd: Help with encoding error
In-Reply-To: <CADiMhquP=C18YTy-+aKW0KdJ2-nyTrtNtkMcC+8-GVpShm3eHQ@mail.gmail.com>
References: <CADiMhquxrez664gee-XsXLPur9coucnc7GczEoAq7yC+BbpmwQ@mail.gmail.com>
	<CADiMhquP=C18YTy-+aKW0KdJ2-nyTrtNtkMcC+8-GVpShm3eHQ@mail.gmail.com>
Message-ID: <525331D1.3020701@stsci.edu>

On 10/02/2013 10:19 AM, Leticia Rodriguez wrote:
> Hi,
>
> I want to use the "?" character in a fit header. The verify in astropy is giving
> me an error.
>
> WARNING: VerifyWarning:         Card 'OBSERVER' is not FITS standard (invalid
> value string: 'Maria Rosa Mu?oz ').  Fixed 'OBSERVER' card to meet the FITS
> standard. [astropy.io.fits.verify]
> ERROR: UnicodeDecodeError: 'ascii' codec can't decode byte 0xf1 in position
> 1946: ordinal not in range(128) [astropy.io.fits.header]
> Traceback (most recent call last):
>    File "./fixfitheader.py", line 30, in <module>
>      hdulist.writeto(sys.argv[2]+'/'+filename, output_verify='fix')
>    File "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/hdulist.py",
> line 675, in writeto
>      hdu._writeto(hdulist.__file)
>    File "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/base.py",
> line 497, in _writeto
>      self._writeheader(fileobj)
>    File "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/hdu/base.py",
> line 428, in _writeheader
>      self._header.tofile(fileobj)
>    File "/usr/local/lib/python2.6/dist-packages/astropy/io/fits/header.py", line
> 625, in tofile
>      fileobj.write(blocks.encode('ascii'))
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf1 in position 1946:
> ordinal not in range(128)
>
> Is there a solution for this issue?
>
> Thanks.
> BR
> Leticia.

I'm going to open an issue against PyFITS for this anyways.  It says "fixed 
'OBSERVER' card to meet the FITS standard" but obviously it didn't strip the 
illegal character, and wound up with a unicode error only later on when trying 
to write the header.  Instead this should have resulted in either an unfixable 
verification error, or might perhaps remove the offending character as a default 
"fix".

Erik



From semelipap at gmail.com  Fri Oct 11 02:13:34 2013
From: semelipap at gmail.com (=?ISO-8859-1?Q?Sem=E9li_Papadogiannakis?=)
Date: Fri, 11 Oct 2013 08:13:34 +0200
Subject: [AstroPy] sncosmo.fit_lc() error
Message-ID: <CANJh8smwn8vxyUi=0uR5SOWjzkfn=Ut=Q96_kRTJg8AWL+26uA@mail.gmail.com>

Hi,
I have been trying to use the function:


sncosmo.fit_lc() from the sncosmo package


to fit SNe lightcurves without much success.


model = sncosmo.get_model('hsiao', version='2.0')

model.set(mabs=-19, z=0.0e5, c=0.1, s=1.2)

data_fitting = {'time': time_normalised, 'flux': mag_lc,

'fluxerr': emag_lc, 'band': 'sdssr',

'zp': 0, 'magsys': 'ab'}


res = sncosmo.fit_lc(data_fitting, model, ['c', 's'])



The error I get is not helpful:


ERROR: ValueError: Error code returned by bispev: 10
[scipy.interpolate.fitpack2]
Traceback (most recent call last):
File "/home/astrobarn/R-band SN/New_R_band/template_maker.py", line 108, in
<module>
res = sncosmo.fit_lc(data_fitting, model, ['c', 's'])
File
"/home/astrobarn/.local/lib/python2.7/site-packages/sncosmo/fitting.py",
line 298, in fit_lc
d, l = m.migrad(ncall=max_ncall)
File "_libiminuit.pyx", line 331, in iminuit._libiminuit.Minuit.migrad
(iminuit/_libiminuit.cpp:4840)
File
"/home/astrobarn/.local/lib/python2.7/site-packages/sncosmo/fitting.py",
line 278, in chi2
return chi2_array_like(parvals)
File
"/home/astrobarn/.local/lib/python2.7/site-packages/sncosmo/fitting.py",
line 257, in chi2_array_like
zp=data['zp'], zpsys=data['zpsys'])
File
"/home/astrobarn/.local/lib/python2.7/site-packages/sncosmo/models.py",
line 486, in bandflux
flux = self._model_flux(phase[idx], d)
File
"/home/astrobarn/.local/lib/python2.7/site-packages/sncosmo/models.py",
line 721, in _model_flux
return dust_trans * self._flux(phase, disp)
File
"/home/astrobarn/anaconda/lib/python2.7/site-packages/scipy/interpolate/fitpack2.py",
line 552, in __call__
raise ValueError("Error code returned by bispev: %s" % ier)
ValueError: Error code returned by bispev: 10


Could you please help me understand what I am doing wrong.


Cheers,

Sem?li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131011/7078aa44/attachment.html>

From kylebarbary at gmail.com  Fri Oct 11 09:09:09 2013
From: kylebarbary at gmail.com (Kyle Barbary)
Date: Fri, 11 Oct 2013 08:09:09 -0500
Subject: [AstroPy] sncosmo.fit_lc() error
In-Reply-To: <CANJh8smwn8vxyUi=0uR5SOWjzkfn=Ut=Q96_kRTJg8AWL+26uA@mail.gmail.com>
References: <CANJh8smwn8vxyUi=0uR5SOWjzkfn=Ut=Q96_kRTJg8AWL+26uA@mail.gmail.com>
Message-ID: <CANO7-x--Md=U5nBj9aaYgu459gHxEn56N4S+rNLTtEK8knS8eQ@mail.gmail.com>

Hi Sem?li,
I'm the main developer of sncosmo. Without knowing what your data look
like, the cause of this error might be that your data are not ordered in
time. There have been several bugfixes on the master branch on github since
the v0.2 release. One of the things that has been fixed is that data are
now automatically ordered in time internally by fit_lc() to avoid this
problem. For now you can try ordering your data in time, or install the
development version from github master.

I opened an issue to fix the error message in cases where model.flux() or
model.bandflux() are called directly, rather than through fit_lc():
https://github.com/sncosmo/sncosmo/issues/15

Thanks for trying sncosmo. Feel free to contact me directly with any other
questions or problems!
- Kyle


On Fri, Oct 11, 2013 at 1:13 AM, Sem?li Papadogiannakis <semelipap at gmail.com
> wrote:

> Hi,
> I have been trying to use the function:
>
>
> sncosmo.fit_lc() from the sncosmo package
>
>
> to fit SNe lightcurves without much success.
>
>
> model = sncosmo.get_model('hsiao', version='2.0')
>
> model.set(mabs=-19, z=0.0e5, c=0.1, s=1.2)
>
> data_fitting = {'time': time_normalised, 'flux': mag_lc,
>
> 'fluxerr': emag_lc, 'band': 'sdssr',
>
> 'zp': 0, 'magsys': 'ab'}
>
>
> res = sncosmo.fit_lc(data_fitting, model, ['c', 's'])
>
>
>
> The error I get is not helpful:
>
>
> ERROR: ValueError: Error code returned by bispev: 10
> [scipy.interpolate.fitpack2]
> Traceback (most recent call last):
> File "/home/astrobarn/R-band SN/New_R_band/template_maker.py", line 108,
> in <module>
> res = sncosmo.fit_lc(data_fitting, model, ['c', 's'])
> File
> "/home/astrobarn/.local/lib/python2.7/site-packages/sncosmo/fitting.py",
> line 298, in fit_lc
> d, l = m.migrad(ncall=max_ncall)
> File "_libiminuit.pyx", line 331, in iminuit._libiminuit.Minuit.migrad
> (iminuit/_libiminuit.cpp:4840)
> File
> "/home/astrobarn/.local/lib/python2.7/site-packages/sncosmo/fitting.py",
> line 278, in chi2
> return chi2_array_like(parvals)
> File
> "/home/astrobarn/.local/lib/python2.7/site-packages/sncosmo/fitting.py",
> line 257, in chi2_array_like
> zp=data['zp'], zpsys=data['zpsys'])
> File
> "/home/astrobarn/.local/lib/python2.7/site-packages/sncosmo/models.py",
> line 486, in bandflux
> flux = self._model_flux(phase[idx], d)
> File
> "/home/astrobarn/.local/lib/python2.7/site-packages/sncosmo/models.py",
> line 721, in _model_flux
> return dust_trans * self._flux(phase, disp)
> File
> "/home/astrobarn/anaconda/lib/python2.7/site-packages/scipy/interpolate/fitpack2.py",
> line 552, in __call__
> raise ValueError("Error code returned by bispev: %s" % ier)
> ValueError: Error code returned by bispev: 10
>
>
> Could you please help me understand what I am doing wrong.
>
>
> Cheers,
>
> Sem?li
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131011/c46e85a5/attachment.html>

From maik.riechert at arcor.de  Wed Oct 16 08:48:23 2013
From: maik.riechert at arcor.de (Maik Riechert)
Date: Wed, 16 Oct 2013 14:48:23 +0200
Subject: [AstroPy] Running wcs_pix2world for all image pixels
Message-ID: <525E8B17.4080206@arcor.de>

Hi,

I'm quite new to python and astropy and got stuck at the following which 
probably is extremely easy to do.

I created a WCS object out of a FITS header and wanted to get the RA/Dec 
coordinates of each image pixel. I tried:

w.wcs_pix2world(np.ndindex(4256, 2832), 0)

where 4256x2832 are the image dimensions. This returns 'ValueError: 
object of too small depth for desired array'. I was trying to avoid 
allocating an array with all pixel coordinates and thought an iterator 
would work too.

What would you recommend for my case (translating every pixel)?

Cheers and thanks,
Maik




From maik.riechert at arcor.de  Wed Oct 16 09:58:15 2013
From: maik.riechert at arcor.de (Maik Riechert)
Date: Wed, 16 Oct 2013 15:58:15 +0200
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
Message-ID: <525E9B77.9020105@arcor.de>

Hi Tom,

That's exactly what I needed. Thanks!

It takes around 3s on my machine for a 4200x2800 image. Is that to be 
expected or are there some speedup tricks?

Maik

On 16/10/13 15:15, Thomas Robitaille wrote:
> Hi Maik,
>
> Someone asked a very similar question just yesterday on GitHub:
>
> https://github.com/astropy/astropy/issues/1587
>
> In short, the solution in your case is:
>
> NAXIS1 = 4256
> NAXIS2 = 2832
> x = np.arange(NAXIS1)
> y = np.arange(NAXIS2)
> X, Y = np.meshgrid(x, y)
> ra, dec = wcs.wcs_pix2world(X, Y, 0)
>
> Any luck?
>
> Tom
>
>
>
>
> On 16 October 2013 14:48, Maik Riechert <maik.riechert at arcor.de> wrote:
>> Hi,
>>
>> I'm quite new to python and astropy and got stuck at the following which
>> probably is extremely easy to do.
>>
>> I created a WCS object out of a FITS header and wanted to get the RA/Dec
>> coordinates of each image pixel. I tried:
>>
>> w.wcs_pix2world(np.ndindex(4256, 2832), 0)
>>
>> where 4256x2832 are the image dimensions. This returns 'ValueError:
>> object of too small depth for desired array'. I was trying to avoid
>> allocating an array with all pixel coordinates and thought an iterator
>> would work too.
>>
>> What would you recommend for my case (translating every pixel)?
>>
>> Cheers and thanks,
>> Maik
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy



From thomas.robitaille at gmail.com  Wed Oct 16 17:02:39 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Wed, 16 Oct 2013 23:02:39 +0200
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <525E9B77.9020105@arcor.de>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
	<525E9B77.9020105@arcor.de>
Message-ID: <CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>

On 16 October 2013 15:58, Maik Riechert <maik.riechert at arcor.de> wrote:
> Hi Tom,
>
> That's exactly what I needed. Thanks!
>
> It takes around 3s on my machine for a 4200x2800 image. Is that to be
> expected or are there some speedup tricks?

To be fair, you *are* converting 12 million positions through a WCS
transformation which is a non-trivial transformation so I'm not sure
if there are any speedups if you need all the values. However, the
question is whether you really need the world coordinates for *all*
pixels. What are you using the values for?

Cheers,
Tom

>
> Maik
>
>
> On 16/10/13 15:15, Thomas Robitaille wrote:
>>
>> Hi Maik,
>>
>> Someone asked a very similar question just yesterday on GitHub:
>>
>> https://github.com/astropy/astropy/issues/1587
>>
>> In short, the solution in your case is:
>>
>> NAXIS1 = 4256
>> NAXIS2 = 2832
>> x = np.arange(NAXIS1)
>> y = np.arange(NAXIS2)
>> X, Y = np.meshgrid(x, y)
>> ra, dec = wcs.wcs_pix2world(X, Y, 0)
>>
>> Any luck?
>>
>> Tom
>>
>>
>>
>>
>> On 16 October 2013 14:48, Maik Riechert <maik.riechert at arcor.de> wrote:
>>>
>>> Hi,
>>>
>>> I'm quite new to python and astropy and got stuck at the following which
>>> probably is extremely easy to do.
>>>
>>> I created a WCS object out of a FITS header and wanted to get the RA/Dec
>>> coordinates of each image pixel. I tried:
>>>
>>> w.wcs_pix2world(np.ndindex(4256, 2832), 0)
>>>
>>> where 4256x2832 are the image dimensions. This returns 'ValueError:
>>> object of too small depth for desired array'. I was trying to avoid
>>> allocating an array with all pixel coordinates and thought an iterator
>>> would work too.
>>>
>>> What would you recommend for my case (translating every pixel)?
>>>
>>> Cheers and thanks,
>>> Maik
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>
>


From d.berry at jach.hawaii.edu  Thu Oct 17 02:54:34 2013
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 17 Oct 2013 07:54:34 +0100
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
	<525E9B77.9020105@arcor.de>
	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
Message-ID: <CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>

On 16 October 2013 22:02, Thomas Robitaille <thomas.robitaille at gmail.com>wrote:

> On 16 October 2013 15:58, Maik Riechert <maik.riechert at arcor.de> wrote:
> > Hi Tom,
> >
> > That's exactly what I needed. Thanks!
> >
> > It takes around 3s on my machine for a 4200x2800 image. Is that to be
> > expected or are there some speedup tricks?
>
> To be fair, you *are* converting 12 million positions through a WCS
> transformation which is a non-trivial transformation so I'm not sure
> if there are any speedups if you need all the values. However, the
> question is whether you really need the world coordinates for *all*
> pixels. What are you using the values for?
>
>

AST attempts to speed up this sort of thing by using a recursive scheme as
follows:



Initial pane = whole array
wcs_values = TransformPane( Mapping, pane )


where the TransformPane function does the following:



- Do a linear fit between pixel and world coords at a small number of
positions spread across the pane.
- If the residuals of the fit are small enough:
   - use the fit to transform all positions in the pane and return them as
the function value.
- Otherwise, if the depth of recursion is less than some limit:
   - divide the pane into four quarters and invoke TransformPane
recursively on each quarter pane, gathering the returned wcs values
together and returning them to the caller.
- Otherwise:
   - Use the full mapping to transform the complete pane.




This means that for typical mappings that are locally smooth, you are
usually using a very simple and fast linear transformation for each point
rather than the full might of the complete pixel->wcs mapping. Clearly, you
need to set some limit to the depth of recursion - we use the criterion
that the number of pixels in the pane must be at least 4 times the number
of points needed to do the linear fit.

The user specifies the accuracy with which the points are to be found, and
this determines the maximum acceptable residuals for the fit. If the
residuals are higher, the pane is subdivided.

See for instance
http://starlink.jach.hawaii.edu/devdocs/sun211.htx/node430.html

David



> Cheers,
> Tom
>
> >
> > Maik
> >
> >
> > On 16/10/13 15:15, Thomas Robitaille wrote:
> >>
> >> Hi Maik,
> >>
> >> Someone asked a very similar question just yesterday on GitHub:
> >>
> >> https://github.com/astropy/astropy/issues/1587
> >>
> >> In short, the solution in your case is:
> >>
> >> NAXIS1 = 4256
> >> NAXIS2 = 2832
> >> x = np.arange(NAXIS1)
> >> y = np.arange(NAXIS2)
> >> X, Y = np.meshgrid(x, y)
> >> ra, dec = wcs.wcs_pix2world(X, Y, 0)
> >>
> >> Any luck?
> >>
> >> Tom
> >>
> >>
> >>
> >>
> >> On 16 October 2013 14:48, Maik Riechert <maik.riechert at arcor.de> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm quite new to python and astropy and got stuck at the following
> which
> >>> probably is extremely easy to do.
> >>>
> >>> I created a WCS object out of a FITS header and wanted to get the
> RA/Dec
> >>> coordinates of each image pixel. I tried:
> >>>
> >>> w.wcs_pix2world(np.ndindex(4256, 2832), 0)
> >>>
> >>> where 4256x2832 are the image dimensions. This returns 'ValueError:
> >>> object of too small depth for desired array'. I was trying to avoid
> >>> allocating an array with all pixel coordinates and thought an iterator
> >>> would work too.
> >>>
> >>> What would you recommend for my case (translating every pixel)?
> >>>
> >>> Cheers and thanks,
> >>> Maik
> >>>
> >>>
> >>> _______________________________________________
> >>> 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: <http://mail.python.org/pipermail/astropy/attachments/20131017/4b772cb3/attachment.html>

From maik.riechert at arcor.de  Thu Oct 17 07:28:59 2013
From: maik.riechert at arcor.de (Maik Riechert)
Date: Thu, 17 Oct 2013 13:28:59 +0200
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>	<525E9B77.9020105@arcor.de>	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>
Message-ID: <525FC9FB.3080906@arcor.de>


On 17/10/13 08:54, David Berry wrote:
> AST attempts to speed up this sort of thing by using a recursive 
> scheme as follows:
> ...
> This means that for typical mappings that are locally smooth, you are 
> usually using a very simple and fast linear transformation for each 
> point rather than the full might of the complete pixel->wcs mapping. 
> Clearly, you need to set some limit to the depth of recursion - we use 
> the criterion that the number of pixels in the pane must be at least 4 
> times the number of points needed to do the linear fit.
>
> The user specifies the accuracy with which the points are to be found, 
> and this determines the maximum acceptable residuals for the fit. If 
> the residuals are higher, the pane is subdivided.
>
> See for instance 
> http://starlink.jach.hawaii.edu/devdocs/sun211.htx/node430.html

I tried to use trangrid (with starlink-pyast) but I must be doing 
something wrong:

width = hdulist[0].header['NAXIS1']
height = hdulist[0].header['NAXIS2']
(wcs,_) = starlink.Atl.readfitswcs(hdulist[0])
mapping = wcs.getmapping( starlink.Ast.BASE, starlink.Ast.CURRENT )
print mapping.trangrid([0,0],[width-1,height-1])

[[-0.69877269 -0.69914315 -0.69951373 ..., -1.22724324 -1.22756251
   -1.22788175]
  [ 0.83534859  0.83540118  0.83545372 ...,  0.5841799   0.58413968
    0.58409942]]

I am expecting coordinates ranging from 320..285 for RA and 48..33 for Dec.

For comparison, my astropy code looks like that:

wcs = WCS(hdulist[0].header)
x, y = np.meshgrid(np.arange(width), np.arange(height))
ra, dec = wcs.wcs_pix2world(x, y, 0)

Cheers
Maik

> David
>
>     Cheers,
>     Tom
>
>     >
>     > Maik
>     >
>     >
>     > On 16/10/13 15:15, Thomas Robitaille wrote:
>     >>
>     >> Hi Maik,
>     >>
>     >> Someone asked a very similar question just yesterday on GitHub:
>     >>
>     >> https://github.com/astropy/astropy/issues/1587
>     >>
>     >> In short, the solution in your case is:
>     >>
>     >> NAXIS1 = 4256
>     >> NAXIS2 = 2832
>     >> x = np.arange(NAXIS1)
>     >> y = np.arange(NAXIS2)
>     >> X, Y = np.meshgrid(x, y)
>     >> ra, dec = wcs.wcs_pix2world(X, Y, 0)
>     >>
>     >> Any luck?
>     >>
>     >> Tom
>     >>
>     >>
>     >>
>     >>
>     >> On 16 October 2013 14:48, Maik Riechert <maik.riechert at arcor.de
>     <mailto:maik.riechert at arcor.de>> wrote:
>     >>>
>     >>> Hi,
>     >>>
>     >>> I'm quite new to python and astropy and got stuck at the
>     following which
>     >>> probably is extremely easy to do.
>     >>>
>     >>> I created a WCS object out of a FITS header and wanted to get
>     the RA/Dec
>     >>> coordinates of each image pixel. I tried:
>     >>>
>     >>> w.wcs_pix2world(np.ndindex(4256, 2832), 0)
>     >>>
>     >>> where 4256x2832 are the image dimensions. This returns
>     'ValueError:
>     >>> object of too small depth for desired array'. I was trying to
>     avoid
>     >>> allocating an array with all pixel coordinates and thought an
>     iterator
>     >>> would work too.
>     >>>
>     >>> What would you recommend for my case (translating every pixel)?
>     >>>
>     >>> Cheers and thanks,
>     >>> Maik
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> AstroPy mailing list
>     >>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     >>> http://mail.scipy.org/mailman/listinfo/astropy
>     >
>     >
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/astropy
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131017/e47c52cd/attachment.html>

From d.berry at jach.hawaii.edu  Thu Oct 17 08:41:19 2013
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 17 Oct 2013 13:41:19 +0100
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <525FC9FB.3080906@arcor.de>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
	<525E9B77.9020105@arcor.de>
	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>
	<525FC9FB.3080906@arcor.de>
Message-ID: <CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>

On 17 October 2013 12:28, Maik Riechert <maik.riechert at arcor.de> wrote:

>
> On 17/10/13 08:54, David Berry wrote:
>
> AST attempts to speed up this sort of thing by using a recursive scheme as
> follows:
> ...
> This means that for typical mappings that are locally smooth, you are
> usually using a very simple and fast linear transformation for each point
> rather than the full might of the complete pixel->wcs mapping. Clearly, you
> need to set some limit to the depth of recursion - we use the criterion
> that the number of pixels in the pane must be at least 4 times the number
> of points needed to do the linear fit.
>
>  The user specifies the accuracy with which the points are to be found,
> and this determines the maximum acceptable residuals for the fit. If the
> residuals are higher, the pane is subdivided.
>
>  See for instance
> http://starlink.jach.hawaii.edu/devdocs/sun211.htx/node430.html
>
>
> I tried to use trangrid (with starlink-pyast) but I must be doing
> something wrong:
>
> width = hdulist[0].header['NAXIS1']
> height = hdulist[0].header['NAXIS2']
> (wcs,_) = starlink.Atl.readfitswcs(hdulist[0])
>

Hi Maik,


> mapping = wcs.getmapping( starlink.Ast.BASE, starlink.Ast.CURRENT )
>

You don't really need this invocation of getmapping. The "wcs" object is a
FrameSet, which is a subclass of Mapping. When used as a Mapping, a
FrameSet object behaves like the Mapping from its base Frame to its current
frame, so you can apply the trangrid method directly to "wcs" instead of
"mapping".


> print mapping.trangrid([0,0],[width-1,height-1])
>
> [[-0.69877269 -0.69914315 -0.69951373 ..., -1.22724324 -1.22756251
>   -1.22788175]
>  [ 0.83534859  0.83540118  0.83545372 ...,  0.5841799   0.58413968
>    0.58409942]]
>
> I am expecting coordinates ranging from 320..285 for RA and 48..33 for Dec.
>
>
Two issues:

1) AST uses radians to represent angles, not degrees. The above values are
consistent with the ranges you quote taking this into account.

2) The negative RA values need 2*PI added to them. Longitude axes such as
RA have the inconvenient characteristic of having a wrap-around
discontinuity somewhere. When reporting values to human beings is is usual
to put this discontinuity at RA=0. But this is not always what you want
when dealing with RA values in code. For instance, if your image contains
zero longitude, measuring RA intervals on your image is awkward. In this
case it would be much more convenient to put the discontinuity at RA=180,
so that RA=-10 is used in place of RA=350 (for instance).

In view of such uncertainty about the best place to put the discontinuity,
AST takes a neutral view and makes no assumption or guarantee about where
the discontinuity will be. Instead, it provides the astNorm method (a
method of the Frame class)  which "normalises" the axis values representing
a position within the Frame, to the form usually expected by human readers.
So for instance the SkyFrame class provides an implementation of astNorm
that puts longitude into the range [0,2*PI] and latitude into the range
[-PI/2,+PI/2].

AST's expectation is that the bulk of calculations performed on
(longitude,latitude) pairs will be unaffected by the position of the
discontinuity, and so it saves time by not performing normalisation
automatically. In the few cases where it really does matter that the
discontinuity is at a specific place,  the astNorm method can be used (or
you can do the normalisation using your own code if you know a priori that
the axis values represents a position on the sky).


David


For comparison, my astropy code looks like that:
>
> wcs = WCS(hdulist[0].header)
> x, y = np.meshgrid(np.arange(width), np.arange(height))
> ra, dec = wcs.wcs_pix2world(x, y, 0)
>
> Cheers
> Maik
>
>    David
>
>
>
>> Cheers,
>> Tom
>>
>> >
>> > Maik
>> >
>> >
>> > On 16/10/13 15:15, Thomas Robitaille wrote:
>> >>
>> >> Hi Maik,
>> >>
>> >> Someone asked a very similar question just yesterday on GitHub:
>> >>
>> >> https://github.com/astropy/astropy/issues/1587
>> >>
>> >> In short, the solution in your case is:
>> >>
>> >> NAXIS1 = 4256
>> >> NAXIS2 = 2832
>> >> x = np.arange(NAXIS1)
>> >> y = np.arange(NAXIS2)
>> >> X, Y = np.meshgrid(x, y)
>> >> ra, dec = wcs.wcs_pix2world(X, Y, 0)
>> >>
>> >> Any luck?
>> >>
>> >> Tom
>> >>
>> >>
>> >>
>> >>
>> >> On 16 October 2013 14:48, Maik Riechert <maik.riechert at arcor.de>
>> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I'm quite new to python and astropy and got stuck at the following
>> which
>> >>> probably is extremely easy to do.
>> >>>
>> >>> I created a WCS object out of a FITS header and wanted to get the
>> RA/Dec
>> >>> coordinates of each image pixel. I tried:
>> >>>
>> >>> w.wcs_pix2world(np.ndindex(4256, 2832), 0)
>> >>>
>> >>> where 4256x2832 are the image dimensions. This returns 'ValueError:
>> >>> object of too small depth for desired array'. I was trying to avoid
>> >>> allocating an array with all pixel coordinates and thought an iterator
>> >>> would work too.
>> >>>
>> >>> What would you recommend for my case (translating every pixel)?
>> >>>
>> >>> Cheers and thanks,
>> >>> Maik
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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: <http://mail.python.org/pipermail/astropy/attachments/20131017/df4ac3fa/attachment.html>

From maik.riechert at arcor.de  Thu Oct 17 10:28:49 2013
From: maik.riechert at arcor.de (Maik Riechert)
Date: Thu, 17 Oct 2013 16:28:49 +0200
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>	<525E9B77.9020105@arcor.de>	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>	<525FC9FB.3080906@arcor.de>
	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>
Message-ID: <525FF421.40105@arcor.de>


On 17/10/13 14:41, David Berry wrote:
> On 17 October 2013 12:28, Maik Riechert <maik.riechert at arcor.de 
> <mailto:maik.riechert at arcor.de>> wrote:
>
>
>     I tried to use trangrid (with starlink-pyast) but I must be doing
>     something wrong:
>     ...
>     [[-0.69877269 -0.69914315 -0.69951373 ..., -1.22724324 -1.22756251
>       -1.22788175]
>      [ 0.83534859  0.83540118  0.83545372 ...,  0.5841799 0.58413968
>        0.58409942]]
>
>     I am expecting coordinates ranging from 320..285 for RA and 48..33
>     for Dec.
>
>
> Two issues:
>
> 1) AST uses radians to represent angles, not degrees. The above values 
> are consistent with the ranges you quote taking this into account.
>
> 2) The negative RA values need 2*PI added to them. Longitude axes such 
> as RA have the inconvenient characteristic of having a wrap-around 
> discontinuity somewhere. When reporting values to human beings is is 
> usual to put this discontinuity at RA=0. But this is not always what 
> you want when dealing with RA values in code. For instance, if your 
> image contains zero longitude, measuring RA intervals on your image is 
> awkward. In this case it would be much more convenient to put the 
> discontinuity at RA=180, so that RA=-10 is used in place of RA=350 
> (for instance).
>
> In view of such uncertainty about the best place to put the 
> discontinuity, AST takes a neutral view and makes no assumption or 
> guarantee about where the discontinuity will be. Instead, it provides 
> the astNorm method (a method of the Frame class)  which "normalises" 
> the axis values representing a position within the Frame, to the form 
> usually expected by human readers. So for instance the SkyFrame class 
> provides an implementation of astNorm that puts longitude into the 
> range [0,2*PI] and latitude into the range [-PI/2,+PI/2].
>
> AST's expectation is that the bulk of calculations performed on 
> (longitude,latitude) pairs will be unaffected by the position of the 
> discontinuity, and so it saves time by not performing normalisation 
> automatically. In the few cases where it really does matter that the 
> discontinuity is at a specific place,  the astNorm method can be used 
> (or you can do the normalisation using your own code if you know a 
> priori that the axis values represents a position on the sky).
>

Thanks David for this detailed explanation. I could confirm the results 
now too. When using for instance 0.00005 as tolerance it is around 10 
times faster than the exact algorithm, very nice!

One more question though. I translated three single pixel coordinates to 
RA, Dec and then again to pixel coordinates using the tran() method. I 
expected that both sets of pixel coordinates are nearly identical (which 
they are when using astropy), but this is what I got:

Input pixel coords:
[[ -196.,   735.,  4059.],
  [ -504.,   459.,  2328.]]

Calculated pixel values:
[[ -205.93229216,   735.        ,  4179.93253144],
  [ -499.36855108,   459.        ,  2246.86209704]]

Note that (735,459) is the WCS center reference.

Any idea?

Maik

>
> David
>
>
>     For comparison, my astropy code looks like that:
>
>     wcs = WCS(hdulist[0].header)
>     x, y = np.meshgrid(np.arange(width), np.arange(height))
>     ra, dec = wcs.wcs_pix2world(x, y, 0)
>
>     Cheers
>     Maik
>
>>     David
>>
>>         Cheers,
>>         Tom
>>
>>         >
>>         > Maik
>>         >
>>         >
>>         > On 16/10/13 15:15, Thomas Robitaille wrote:
>>         >>
>>         >> Hi Maik,
>>         >>
>>         >> Someone asked a very similar question just yesterday on
>>         GitHub:
>>         >>
>>         >> https://github.com/astropy/astropy/issues/1587
>>         >>
>>         >> In short, the solution in your case is:
>>         >>
>>         >> NAXIS1 = 4256
>>         >> NAXIS2 = 2832
>>         >> x = np.arange(NAXIS1)
>>         >> y = np.arange(NAXIS2)
>>         >> X, Y = np.meshgrid(x, y)
>>         >> ra, dec = wcs.wcs_pix2world(X, Y, 0)
>>         >>
>>         >> Any luck?
>>         >>
>>         >> Tom
>>         >>
>>         >>
>>         >>
>>         >>
>>         >> On 16 October 2013 14:48, Maik Riechert
>>         <maik.riechert at arcor.de <mailto:maik.riechert at arcor.de>> wrote:
>>         >>>
>>         >>> Hi,
>>         >>>
>>         >>> I'm quite new to python and astropy and got stuck at the
>>         following which
>>         >>> probably is extremely easy to do.
>>         >>>
>>         >>> I created a WCS object out of a FITS header and wanted to
>>         get the RA/Dec
>>         >>> coordinates of each image pixel. I tried:
>>         >>>
>>         >>> w.wcs_pix2world(np.ndindex(4256, 2832), 0)
>>         >>>
>>         >>> where 4256x2832 are the image dimensions. This returns
>>         'ValueError:
>>         >>> object of too small depth for desired array'. I was
>>         trying to avoid
>>         >>> allocating an array with all pixel coordinates and
>>         thought an iterator
>>         >>> would work too.
>>         >>>
>>         >>> What would you recommend for my case (translating every
>>         pixel)?
>>         >>>
>>         >>> Cheers and thanks,
>>         >>> Maik
>>         >>>
>>         >>>
>>         >>> _______________________________________________
>>         >>> AstroPy mailing list
>>         >>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>         >>> http://mail.scipy.org/mailman/listinfo/astropy
>>         >
>>         >
>>         _______________________________________________
>>         AstroPy mailing list
>>         AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>         http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131017/ca0e6505/attachment.html>

From demitri.muna at gmail.com  Thu Oct 17 11:01:51 2013
From: demitri.muna at gmail.com (Demitri Muna)
Date: Thu, 17 Oct 2013 11:01:51 -0400
Subject: [AstroPy] aper.pro from idlutils
Message-ID: <D092EAA6-403B-407E-8D92-73141AF3F839@gmail.com>

Hi,

Is anyone aware of an equivalent of aper.pro from idlutils in Python? (Also C would be great.)

Cheers,
Demitri

_________________________________________
Demitri Muna

Department of Astronomy
An Ohio State University

http://scicoder.org/





From d.berry at jach.hawaii.edu  Thu Oct 17 11:20:04 2013
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 17 Oct 2013 16:20:04 +0100
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <525FF421.40105@arcor.de>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
	<525E9B77.9020105@arcor.de>
	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>
	<525FC9FB.3080906@arcor.de>
	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>
	<525FF421.40105@arcor.de>
Message-ID: <CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>

On 17 October 2013 15:28, Maik Riechert <maik.riechert at arcor.de> wrote:

>
> On 17/10/13 14:41, David Berry wrote:
>
> On 17 October 2013 12:28, Maik Riechert <maik.riechert at arcor.de> wrote:
>
>>
>> I tried to use trangrid (with starlink-pyast) but I must be doing
>> something wrong:
>> ...
>>
>> [[-0.69877269 -0.69914315 -0.69951373 ..., -1.22724324 -1.22756251
>>   -1.22788175]
>>  [ 0.83534859  0.83540118  0.83545372 ...,  0.5841799   0.58413968
>>    0.58409942]]
>>
>> I am expecting coordinates ranging from 320..285 for RA and 48..33 for
>> Dec.
>>
>>
>  Two issues:
>
>  1) AST uses radians to represent angles, not degrees. The above values
> are consistent with the ranges you quote taking this into account.
>
>  2) The negative RA values need 2*PI added to them. Longitude axes such
> as RA have the inconvenient characteristic of having a wrap-around
> discontinuity somewhere. When reporting values to human beings is is usual
> to put this discontinuity at RA=0. But this is not always what you want
> when dealing with RA values in code. For instance, if your image contains
> zero longitude, measuring RA intervals on your image is awkward. In this
> case it would be much more convenient to put the discontinuity at RA=180,
> so that RA=-10 is used in place of RA=350 (for instance).
>
>  In view of such uncertainty about the best place to put the
> discontinuity, AST takes a neutral view and makes no assumption or
> guarantee about where the discontinuity will be. Instead, it provides the
> astNorm method (a method of the Frame class)  which "normalises" the axis
> values representing a position within the Frame, to the form usually
> expected by human readers. So for instance the SkyFrame class provides an
> implementation of astNorm that puts longitude into the range [0,2*PI] and
> latitude into the range [-PI/2,+PI/2].
>
>  AST's expectation is that the bulk of calculations performed on
> (longitude,latitude) pairs will be unaffected by the position of the
> discontinuity, and so it saves time by not performing normalisation
> automatically. In the few cases where it really does matter that the
> discontinuity is at a specific place,  the astNorm method can be used (or
> you can do the normalisation using your own code if you know a priori that
> the axis values represents a position on the sky).
>
>
> Thanks David for this detailed explanation. I could confirm the results
> now too. When using for instance 0.00005 as tolerance it is around 10 times
> faster than the exact algorithm, very nice!
>
> One more question though. I translated three single pixel coordinates to
> RA, Dec and then again to pixel coordinates using the tran() method. I
> expected that both sets of pixel coordinates are nearly identical (which
> they are when using astropy), but this is what I got:
>
> Input pixel coords:
> [[ -196.,   735.,  4059.],
>  [ -504.,   459.,  2328.]]
>
> Calculated pixel values:
> [[ -205.93229216,   735.        ,  4179.93253144],
>  [ -499.36855108,   459.        ,  2246.86209704]]
>
> Note that (735,459) is the WCS center reference.
>
> Any idea?
>
>

Hi Maik,
              The tolerance you specify when running TranGrid is a distance
in the output coordinate system, which in your case I presume is (ra,dec).
So a tolerance value of 0.00005 is taken as a value in radians, which is
about 10 arc-seconds. So errors of up to this sort of size could be
expected from the linear approximations being used. What is the pixel size
in your case? You should find that using a smaller tolerance results in
smaller round-trip errors. If this is not the case, it may be a bug, in
which case I'd be interested to see the FITS header you are using so that I
can track it down.

David




> Maik
>
>
>
>  David
>
>
>   For comparison, my astropy code looks like that:
>>
>> wcs = WCS(hdulist[0].header)
>> x, y = np.meshgrid(np.arange(width), np.arange(height))
>> ra, dec = wcs.wcs_pix2world(x, y, 0)
>>
>> Cheers
>> Maik
>>
>>    David
>>
>>
>>
>>> Cheers,
>>> Tom
>>>
>>> >
>>> > Maik
>>> >
>>> >
>>> > On 16/10/13 15:15, Thomas Robitaille wrote:
>>> >>
>>> >> Hi Maik,
>>> >>
>>> >> Someone asked a very similar question just yesterday on GitHub:
>>> >>
>>> >> https://github.com/astropy/astropy/issues/1587
>>> >>
>>> >> In short, the solution in your case is:
>>> >>
>>> >> NAXIS1 = 4256
>>> >> NAXIS2 = 2832
>>> >> x = np.arange(NAXIS1)
>>> >> y = np.arange(NAXIS2)
>>> >> X, Y = np.meshgrid(x, y)
>>> >> ra, dec = wcs.wcs_pix2world(X, Y, 0)
>>> >>
>>> >> Any luck?
>>> >>
>>> >> Tom
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 16 October 2013 14:48, Maik Riechert <maik.riechert at arcor.de>
>>> wrote:
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>> I'm quite new to python and astropy and got stuck at the following
>>> which
>>> >>> probably is extremely easy to do.
>>> >>>
>>> >>> I created a WCS object out of a FITS header and wanted to get the
>>> RA/Dec
>>> >>> coordinates of each image pixel. I tried:
>>> >>>
>>> >>> w.wcs_pix2world(np.ndindex(4256, 2832), 0)
>>> >>>
>>> >>> where 4256x2832 are the image dimensions. This returns 'ValueError:
>>> >>> object of too small depth for desired array'. I was trying to avoid
>>> >>> allocating an array with all pixel coordinates and thought an
>>> iterator
>>> >>> would work too.
>>> >>>
>>> >>> What would you recommend for my case (translating every pixel)?
>>> >>>
>>> >>> Cheers and thanks,
>>> >>> Maik
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> 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: <http://mail.python.org/pipermail/astropy/attachments/20131017/531d302d/attachment.html>

From maik.riechert at arcor.de  Thu Oct 17 11:28:45 2013
From: maik.riechert at arcor.de (Maik Riechert)
Date: Thu, 17 Oct 2013 17:28:45 +0200
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>	<525E9B77.9020105@arcor.de>	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>	<525FC9FB.3080906@arcor.de>	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>	<525FF421.40105@arcor.de>
	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>
Message-ID: <5260022D.5040902@arcor.de>


On 17/10/13 17:20, David Berry wrote:
>
>
>
> On 17 October 2013 15:28, Maik Riechert <maik.riechert at arcor.de 
> <mailto:maik.riechert at arcor.de>> wrote:
>
>
>     On 17/10/13 14:41, David Berry wrote:
>>     On 17 October 2013 12:28, Maik Riechert <maik.riechert at arcor.de
>>     <mailto:maik.riechert at arcor.de>> wrote:
>>
>>
>>         I tried to use trangrid (with starlink-pyast) but I must be
>>         doing something wrong:
>>         ...
>>
>>         [[-0.69877269 -0.69914315 -0.69951373 ..., -1.22724324
>>         -1.22756251
>>           -1.22788175]
>>          [ 0.83534859  0.83540118  0.83545372 ...,  0.5841799  
>>         0.58413968
>>            0.58409942]]
>>
>>         I am expecting coordinates ranging from 320..285 for RA and
>>         48..33 for Dec.
>>
>>
>>     Two issues:
>>
>>     1) AST uses radians to represent angles, not degrees. The above
>>     values are consistent with the ranges you quote taking this into
>>     account.
>>
>>     2) The negative RA values need 2*PI added to them. Longitude axes
>>     such as RA have the inconvenient characteristic of having a
>>     wrap-around discontinuity somewhere. When reporting values to
>>     human beings is is usual to put this discontinuity at RA=0. But
>>     this is not always what you want when dealing with RA values in
>>     code. For instance, if your image contains zero longitude,
>>     measuring RA intervals on your image is awkward. In this case it
>>     would be much more convenient to put the discontinuity at RA=180,
>>     so that RA=-10 is used in place of RA=350 (for instance).
>>
>>     In view of such uncertainty about the best place to put the
>>     discontinuity, AST takes a neutral view and makes no assumption
>>     or guarantee about where the discontinuity will be. Instead, it
>>     provides the astNorm method (a method of the Frame class)  which
>>     "normalises" the axis values representing a position within the
>>     Frame, to the form usually expected by human readers. So for
>>     instance the SkyFrame class provides an implementation of astNorm
>>     that puts longitude into the range [0,2*PI] and latitude into the
>>     range [-PI/2,+PI/2].
>>
>>     AST's expectation is that the bulk of calculations performed on
>>     (longitude,latitude) pairs will be unaffected by the position of
>>     the discontinuity, and so it saves time by not performing
>>     normalisation automatically. In the few cases where it really
>>     does matter that the discontinuity is at a specific place,  the
>>     astNorm method can be used (or you can do the normalisation using
>>     your own code if you know a priori that the axis values
>>     represents a position on the sky).
>>
>
>     Thanks David for this detailed explanation. I could confirm the
>     results now too. When using for instance 0.00005 as tolerance it
>     is around 10 times faster than the exact algorithm, very nice!
>
>     One more question though. I translated three single pixel
>     coordinates to RA, Dec and then again to pixel coordinates using
>     the tran() method. I expected that both sets of pixel coordinates
>     are nearly identical (which they are when using astropy), but this
>     is what I got:
>
>     Input pixel coords:
>     [[ -196.,   735.,  4059.],
>      [ -504.,   459.,  2328.]]
>
>     Calculated pixel values:
>     [[ -205.93229216,   735.        ,  4179.93253144],
>      [ -499.36855108,   459.        ,  2246.86209704]]
>
>     Note that (735,459) is the WCS center reference.
>
>     Any idea?
>
>
>
> Hi Maik,
>               The tolerance you specify when running TranGrid is a 
> distance in the output coordinate system, which in your case I presume 
> is (ra,dec). So a tolerance value of 0.00005 is taken as a value in 
> radians, which is about 10 arc-seconds. So errors of up to this sort 
> of size could be expected from the linear approximations being used. 
> What is the pixel size in your case? You should find that using a 
> smaller tolerance results in smaller round-trip errors. If this is not 
> the case, it may be a bug, in which case I'd be interested to see the 
> FITS header you are using so that I can track it down.

I didn't use tranGrid here, just tran! So no tolerance involved.

NAXIS1  =                 1468 / image width
NAXIS2  =                  916 / image height
CTYPE1  = 'RA---TAN-SIP' / TAN (gnomic) projection + SIP distortions
CTYPE2  = 'DEC--TAN-SIP' / TAN (gnomic) projection + SIP distortions
EQUINOX =               2000.0 / Equatorial coordinates definition (yr)
LONPOLE =                180.0 / no comment
LATPOLE =                  0.0 / no comment
CRVAL1  =         302.88771538 / RA  of reference point
CRVAL2  =        41.8941029213 / DEC of reference point
CRPIX1  =                  735 / X reference pixel
CRPIX2  =                  459 / Y reference pixel
CUNIT1  = 'deg     ' / X pixel scale units
CUNIT2  = 'deg     ' / Y pixel scale units
CD1_1   =     -0.0157184611387 / Transformation matrix
CD1_2   =     0.00022032143241 / no comment
CD2_1   =   -0.000284856284919 / no comment
CD2_2   =     -0.0159943489114 / no comment
IMAGEW  =                 1468 / Image width,  in pixels.
IMAGEH  =                  916 / Image height, in pixels.
A_ORDER =                    2 / Polynomial order, axis 1
A_0_2   =   -5.10167355829E-05 / no comment
A_1_1   =   -5.54267287337E-05 / no comment
A_2_0   =    3.68095680847E-05 / no comment
B_ORDER =                    2 / Polynomial order, axis 2
B_0_2   =    2.49853669312E-05 / no comment
B_1_1   =    6.07756179822E-05 / no comment
B_2_0   =   -1.70350503136E-05 / no comment
AP_ORDER=                    2 / Inv polynomial order, axis 1
AP_0_1  =     -0.0014471978634 / no comment
AP_0_2  =     5.0935282476E-05 / no comment
AP_1_0  =    0.000641040653934 / no comment
AP_1_1  =    5.54267224252E-05 / no comment
AP_2_0  =     -3.674588665E-05 / no comment
BP_ORDER=                    2 / Inv polynomial order, axis 2
BP_0_1  =      0.0010860421788 / no comment
BP_0_2  =   -2.49999638422E-05 / no comment
BP_1_0  =   -0.000569392740582 / no comment
BP_1_1  =   -6.07473585161E-05 / no comment
BP_2_0  =     1.7000827442E-05 / no comment

Maik
>
> David
>
>
>     Maik
>
>
>>
>>     David
>>
>>
>>         For comparison, my astropy code looks like that:
>>
>>         wcs = WCS(hdulist[0].header)
>>         x, y = np.meshgrid(np.arange(width), np.arange(height))
>>         ra, dec = wcs.wcs_pix2world(x, y, 0)
>>
>>         Cheers
>>         Maik
>>
>>>         David
>>>
>>>             Cheers,
>>>             Tom
>>>
>>>             >
>>>             > Maik
>>>             >
>>>             >
>>>             > On 16/10/13 15:15, Thomas Robitaille wrote:
>>>             >>
>>>             >> Hi Maik,
>>>             >>
>>>             >> Someone asked a very similar question just yesterday
>>>             on GitHub:
>>>             >>
>>>             >> https://github.com/astropy/astropy/issues/1587
>>>             >>
>>>             >> In short, the solution in your case is:
>>>             >>
>>>             >> NAXIS1 = 4256
>>>             >> NAXIS2 = 2832
>>>             >> x = np.arange(NAXIS1)
>>>             >> y = np.arange(NAXIS2)
>>>             >> X, Y = np.meshgrid(x, y)
>>>             >> ra, dec = wcs.wcs_pix2world(X, Y, 0)
>>>             >>
>>>             >> Any luck?
>>>             >>
>>>             >> Tom
>>>             >>
>>>             >>
>>>             >>
>>>             >>
>>>             >> On 16 October 2013 14:48, Maik Riechert
>>>             <maik.riechert at arcor.de <mailto:maik.riechert at arcor.de>>
>>>             wrote:
>>>             >>>
>>>             >>> Hi,
>>>             >>>
>>>             >>> I'm quite new to python and astropy and got stuck at
>>>             the following which
>>>             >>> probably is extremely easy to do.
>>>             >>>
>>>             >>> I created a WCS object out of a FITS header and
>>>             wanted to get the RA/Dec
>>>             >>> coordinates of each image pixel. I tried:
>>>             >>>
>>>             >>> w.wcs_pix2world(np.ndindex(4256, 2832), 0)
>>>             >>>
>>>             >>> where 4256x2832 are the image dimensions. This
>>>             returns 'ValueError:
>>>             >>> object of too small depth for desired array'. I was
>>>             trying to avoid
>>>             >>> allocating an array with all pixel coordinates and
>>>             thought an iterator
>>>             >>> would work too.
>>>             >>>
>>>             >>> What would you recommend for my case (translating
>>>             every pixel)?
>>>             >>>
>>>             >>> Cheers and thanks,
>>>             >>> Maik
>>>             >>>
>>>             >>>
>>>             >>> _______________________________________________
>>>             >>> AstroPy mailing list
>>>             >>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>>             >>> http://mail.scipy.org/mailman/listinfo/astropy
>>>             >
>>>             >
>>>             _______________________________________________
>>>             AstroPy mailing list
>>>             AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>>             http://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131017/64e950ed/attachment.html>

From kyle at anl.gov  Thu Oct 17 11:33:51 2013
From: kyle at anl.gov (Kyle Barbary)
Date: Thu, 17 Oct 2013 10:33:51 -0500
Subject: [AstroPy] aper.pro from idlutils
In-Reply-To: <D092EAA6-403B-407E-8D92-73141AF3F839@gmail.com>
References: <D092EAA6-403B-407E-8D92-73141AF3F839@gmail.com>
Message-ID: <CANO7-x9Wkucb7g-LB9kA_GSHODf++uWKPS8kmU=2NO9=QWy9Ew@mail.gmail.com>

This seems pretty close to aper.pro:

http://photutils.readthedocs.org/en/latest/_generated/photutils.aperture.aperture_circular.html


On Thu, Oct 17, 2013 at 10:01 AM, Demitri Muna <demitri.muna at gmail.com>wrote:

> Hi,
>
> Is anyone aware of an equivalent of aper.pro from idlutils in Python?
> (Also C would be great.)
>
> Cheers,
> Demitri
>
> _________________________________________
> Demitri Muna
>
> Department of Astronomy
> An Ohio State University
>
> http://scicoder.org/
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131017/5296dba8/attachment.html>

From lbradley at stsci.edu  Thu Oct 17 12:21:47 2013
From: lbradley at stsci.edu (Larry Bradley)
Date: Thu, 17 Oct 2013 12:21:47 -0400
Subject: [AstroPy] aper.pro from idlutils
In-Reply-To: <D092EAA6-403B-407E-8D92-73141AF3F839@gmail.com>
References: <D092EAA6-403B-407E-8D92-73141AF3F839@gmail.com>
Message-ID: <CAFfmSa0m7j5mZx88W4sZCrsYq+w9SSY8kojFVZ45x4fCkj+CPQ@mail.gmail.com>

The photutils package can perform circular aperture photometry:

https://photutils.readthedocs.org/en/latest/_generated/photutils.aperture.aperture_circular.html#photutils.aperture.aperture_circular

https://github.com/astropy/photutils

Cheers,
Larry

On Thu, Oct 17, 2013 at 11:01 AM, Demitri Muna <demitri.muna at gmail.com> wrote:
> Hi,
>
> Is anyone aware of an equivalent of aper.pro from idlutils in Python? (Also C would be great.)
>
> Cheers,
> Demitri
>
> _________________________________________
> Demitri Muna
>
> Department of Astronomy
> An Ohio State University
>
> http://scicoder.org/
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From d.berry at jach.hawaii.edu  Fri Oct 18 04:54:16 2013
From: d.berry at jach.hawaii.edu (David Berry)
Date: Fri, 18 Oct 2013 09:54:16 +0100
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <5260022D.5040902@arcor.de>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
	<525E9B77.9020105@arcor.de>
	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>
	<525FC9FB.3080906@arcor.de>
	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>
	<525FF421.40105@arcor.de>
	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>
	<5260022D.5040902@arcor.de>
Message-ID: <CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>

On 17 October 2013 16:28, Maik Riechert <maik.riechert at arcor.de> wrote:

I didn't use tranGrid here, just tran! So no tolerance involved.
>

Doh! Sorry - didn't spot that.


>
> NAXIS1  =                 1468 / image
> width
> NAXIS2  =                  916 / image
> height
> CTYPE1  = 'RA---TAN-SIP' / TAN (gnomic) projection + SIP distortions
> CTYPE2  = 'DEC--TAN-SIP' / TAN (gnomic) projection + SIP distortions
> EQUINOX =               2000.0 / Equatorial coordinates definition (yr)
> LONPOLE =                180.0 / no
> comment
> LATPOLE =                  0.0 / no
> comment
> CRVAL1  =         302.88771538 / RA  of reference
> point
> CRVAL2  =        41.8941029213 / DEC of reference
> point
> CRPIX1  =                  735 / X reference
> pixel
> CRPIX2  =                  459 / Y reference
> pixel
> CUNIT1  = 'deg     ' / X pixel scale
> units
> CUNIT2  = 'deg     ' / Y pixel scale
> units
> CD1_1   =     -0.0157184611387 / Transformation
> matrix
> CD1_2   =     0.00022032143241 / no
> comment
> CD2_1   =   -0.000284856284919 / no
> comment
> CD2_2   =     -0.0159943489114 / no
> comment
> IMAGEW  =                 1468 / Image width,  in
> pixels.
> IMAGEH  =                  916 / Image height, in
> pixels.
> A_ORDER =                    2 / Polynomial order, axis
> 1
> A_0_2   =   -5.10167355829E-05 / no
> comment
> A_1_1   =   -5.54267287337E-05 / no
> comment
> A_2_0   =    3.68095680847E-05 / no
> comment
> B_ORDER =                    2 / Polynomial order, axis
> 2
> B_0_2   =    2.49853669312E-05 / no
> comment
> B_1_1   =    6.07756179822E-05 / no
> comment
> B_2_0   =   -1.70350503136E-05 / no
> comment
> AP_ORDER=                    2 / Inv polynomial order, axis
> 1
> AP_0_1  =     -0.0014471978634 / no
> comment
> AP_0_2  =     5.0935282476E-05 / no
> comment
> AP_1_0  =    0.000641040653934 / no
> comment
> AP_1_1  =    5.54267224252E-05 / no
> comment
> AP_2_0  =     -3.674588665E-05 / no
> comment
> BP_ORDER=                    2 / Inv polynomial order, axis
> 2
> BP_0_1  =      0.0010860421788 / no
> comment
> BP_0_2  =   -2.49999638422E-05 / no
> comment
> BP_1_0  =   -0.000569392740582 / no
> comment
> BP_1_1  =   -6.07473585161E-05 / no comment
> BP_2_0  =     1.7000827442E-05 / no comment
>

OK - so I suspect the problems may actually be in astropy rather than AST.
 Maybe the maintainers of astropy.wcs could comment.

The above header includes a polynomial distortion correction using the
Spitzer SIP conventions. The "A_" and "B_" headers give the coefficients of
the forward ( (x,y) to (ra,dec) ) polynomial, and the "AP_" and "BP_"
headers give the coefficients of the inverse ( (ra,dec) to (x,y) )
polynomial.

Using the header as supplied to transform the following pixel positions:

x = -196, 735, 4059
y = -504, 459, 2328

I get, using AST (converted to degrees):

ra = 328.090902, 302.887715, 265.839543
dec = 53.570723, 41.894103, 8.257963

whereas astropy gives:

ra = 326.992376, 302.866900, 263.545072
dec = 54.749009, 41.877821, 10.589047

For an independent check I also used SAO WCSTools which gave:

ra =  328.09090, 302.88772, 265.83954
dec = 53.57072, 41.89410, 8.25796

So AST and WCSTools agree, but astropy is different. This is not conclusive
in itself, but I then modified the header by removing all the SIP keywords
and removing "-SIP" from the CTYPE1/2 headers. With these changes the
header represents an undistorted TAN projection. I then transformed the
same pixel positions again using the changed header:

AST gave:

ra = 327.022569, 302.887715, 263.548641
dec = 54.758313, 41.894103, 10.599558

astropy gave:

ra = 326.992376, 302.866900, 263.545072
dec = 54.749009, 41.877822, 10.589047

and WCSTools gave:

ra = 327.02257, 302.88772, 263.54864
dec = 54.75831, 41.89410, 10.59956

So again AST and WCSTools agree, with astropy as the odd one out. But more
importantly, the astropy results are exactly the same as when using the
header that includes the SIP distortion. This seems to indicate that in
fact astropy is ignoring the SIP distortion. You can see that the astropy
values are much closer to the AST/WCSTools values when no distortion is
included.

Further, the second pixel position is actually the reference point of the
header (CRPIX1/2) and so the RA and Dec at this point should be exactly
equal to the values of CRVAL1/2, which is what AST and WCSTools report. But
astropy is off by about a pixel (58 arc-sec).

So to summarise, astropy seems to ignore the SIP distortion, and also
assigns a slightly wrong position to the reference point.  The astropy code
I am using is:

from astropy import wcs
from astropy.io import fits
hdulist = fits.open("maik.fit")
mywcs = wcs.WCS(hdulist[0].header)
x = [ -196.,   735.,  4059.]
y = [ -504.,   459.,  2328.]
ra, dec = mywcs.wcs_pix2world(x, y, 0)



Now regarding the inverse transformation back from (ra,dec) to (x,y). If in
fact astropy is not including any polynomial distortion, then it is
not surprising that it manages to recreate the original (x,y) values
exactly. AST also does that if you exclude the distortion terms. If the
distortion is included, AST gives:

x = -205.93, 735, 4179.93
y = -499.37, 459, 2246.86

WCSTools gives exactly the same values. This poor performance of AST and
WCSTools when including the distortion indicates that the coefficients of
the inverse polynomial included in the header (the "AP_" and "BP_" headers)
are inaccurate.  But AST has a facility to handle SIP headers that do not
include an inverse polynomial. In such cases, AST creates an inverse itself
by numerical inversion of the supplied forward polynomial. So if I remove
the "AP_" and "BP_" keywords from the header, and again transform the
(ra,dec) values back into (x,y) AST now gives:

x = -197.19, 735, 4061.94
y = -502.92, 459, 2324.94

which are much better but still not good. AST includes two alternative
schemes for implementing a missing SIP inverse:

1) it samples the forward transformation at a regular grid of pixel
positions and fits a polynomial surface to the results. This fit is
performed once, and if the residuals of the fit are sufficiently small, it
is then used to transform all subsequent points.

2) if the residuals of the above fit are too large, then each individual
(ra,dec) position is transformed using an iterative Newton-Raphson method.
This is much slower over-all than 1) but more accurate.

There is a problem in AST in that it is using option 1) above for your
header, when in fact it needs to use 2) to get sufficient accuracy.  The
recovered (x,y) values quoted above were created using option 1). With
option 2), the exact original (x,y) values are recovered to within 0.01
pixel.

I shall investigate this issue in AST. Thanks for the input.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131018/3d90291b/attachment.html>

From maik.riechert at arcor.de  Fri Oct 18 05:09:46 2013
From: maik.riechert at arcor.de (Maik Riechert)
Date: Fri, 18 Oct 2013 11:09:46 +0200
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>	<525E9B77.9020105@arcor.de>	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>	<525FC9FB.3080906@arcor.de>	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>	<525FF421.40105@arcor.de>	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>	<5260022D.5040902@arcor.de>
	<CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
Message-ID: <5260FADA.3050403@arcor.de>


On 18/10/13 10:54, David Berry wrote:
> So to summarise, astropy seems to ignore the SIP distortion, and also 
> assigns a slightly wrong position to the reference point. The astropy 
> code I am using is:
> ...
> ra, dec = mywcs.wcs_pix2world(x, y, 0)
>
Just a quick note, there are two methods, wcs_pix2world and 
all_pix2world and the former is described as not doing SIP correction, 
while the later does SIP, 'Paper IV', and some detector to plane 
correction. I haven't tried that yet, just wanted to give a hint.

Maik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131018/8488151b/attachment.html>

From mdroe at stsci.edu  Fri Oct 18 07:49:32 2013
From: mdroe at stsci.edu (Michael Droettboom)
Date: Fri, 18 Oct 2013 07:49:32 -0400
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>	<525E9B77.9020105@arcor.de>	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>	<525FC9FB.3080906@arcor.de>	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>	<525FF421.40105@arcor.de>	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>	<5260022D.5040902@arcor.de>
	<CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
Message-ID: <5261204C.5050208@stsci.edu>

On 10/18/2013 04:54 AM, David Berry wrote:
>
>
>
> On 17 October 2013 16:28, Maik Riechert <maik.riechert at arcor.de 
> <mailto:maik.riechert at arcor.de>> wrote:
>
>     I didn't use tranGrid here, just tran! So no tolerance involved.
>
>
> Doh! Sorry - didn't spot that.
>
>
>     NAXIS1  =                 1468 / image width
>     NAXIS2  =                  916 / image height
>     CTYPE1  = 'RA---TAN-SIP' / TAN (gnomic) projection + SIP distortions
>     CTYPE2  = 'DEC--TAN-SIP' / TAN (gnomic) projection + SIP distortions
>     EQUINOX =               2000.0 / Equatorial coordinates definition
>     (yr)
>     LONPOLE =                180.0 / no comment
>     LATPOLE =                  0.0 / no comment
>     CRVAL1  =         302.88771538 / RA  of reference point
>     CRVAL2  =        41.8941029213 / DEC of reference point
>     CRPIX1  =                  735 / X reference pixel
>     CRPIX2  =                  459 / Y reference pixel
>     CUNIT1  = 'deg     ' / X pixel scale units
>     CUNIT2  = 'deg     ' / Y pixel scale units
>     CD1_1   =     -0.0157184611387 / Transformation matrix
>     CD1_2   =     0.00022032143241 / no comment
>     CD2_1   =   -0.000284856284919 / no comment
>     CD2_2   =     -0.0159943489114 / no comment
>     IMAGEW  =                 1468 / Image width,  in pixels.
>     IMAGEH  =                  916 / Image height, in pixels.
>     A_ORDER =                    2 / Polynomial order, axis 1
>     A_0_2   =   -5.10167355829E-05 / no comment
>     A_1_1   =   -5.54267287337E-05 / no comment
>     A_2_0   =    3.68095680847E-05 / no comment
>     B_ORDER =                    2 / Polynomial order, axis 2
>     B_0_2   =    2.49853669312E-05 / no comment
>     B_1_1   =    6.07756179822E-05 / no comment
>     B_2_0   =   -1.70350503136E-05 / no comment
>     AP_ORDER=                    2 / Inv polynomial order, axis 1
>     AP_0_1  =     -0.0014471978634 / no comment
>     AP_0_2  =     5.0935282476E-05 / no comment
>     AP_1_0  =    0.000641040653934 / no comment
>     AP_1_1  =    5.54267224252E-05 / no comment
>     AP_2_0  =     -3.674588665E-05 / no comment
>     BP_ORDER=                    2 / Inv polynomial order, axis 2
>     BP_0_1  =      0.0010860421788 / no comment
>     BP_0_2  =   -2.49999638422E-05 / no comment
>     BP_1_0  =   -0.000569392740582 / no comment
>     BP_1_1  =   -6.07473585161E-05 / no comment
>     BP_2_0  =     1.7000827442E-05 / no comment
>
>
> OK - so I suspect the problems may actually be in astropy rather than 
> AST.  Maybe the maintainers of astropy.wcs could comment.
>
> The above header includes a polynomial distortion correction using the 
> Spitzer SIP conventions. The "A_" and "B_" headers give the 
> coefficients of the forward ( (x,y) to (ra,dec) ) polynomial, and the 
> "AP_" and "BP_" headers give the coefficients of the inverse ( 
> (ra,dec) to (x,y) ) polynomial.
>
> Using the header as supplied to transform the following pixel positions:
>
> x = -196, 735, 4059
> y = -504, 459, 2328
>
> I get, using AST (converted to degrees):
>
> ra = 328.090902, 302.887715, 265.839543
> dec = 53.570723, 41.894103, 8.257963
>
> whereas astropy gives:
>
> ra = 326.992376, 302.866900, 263.545072
> dec = 54.749009, 41.877821, 10.589047
>
> For an independent check I also used SAO WCSTools which gave:
>
> ra =  328.09090, 302.88772, 265.83954
> dec = 53.57072, 41.89410, 8.25796
>
> So AST and WCSTools agree, but astropy is different. This is not 
> conclusive in itself, but I then modified the header by removing all 
> the SIP keywords and removing "-SIP" from the CTYPE1/2 headers. With 
> these changes the header represents an undistorted TAN projection. I 
> then transformed the same pixel positions again using the changed header:
>
> AST gave:
>
> ra = 327.022569, 302.887715, 263.548641
> dec = 54.758313, 41.894103, 10.599558
>
> astropy gave:
>
> ra = 326.992376, 302.866900, 263.545072
> dec = 54.749009, 41.877822, 10.589047
>
> and WCSTools gave:
>
> ra = 327.02257, 302.88772, 263.54864
> dec = 54.75831, 41.89410, 10.59956
>
> So again AST and WCSTools agree, with astropy as the odd one out. But 
> more importantly, the astropy results are exactly the same as when 
> using the header that includes the SIP distortion. This seems to 
> indicate that in fact astropy is ignoring the SIP distortion. You can 
> see that the astropy values are much closer to the AST/WCSTools values 
> when no distortion is included.

You need to use wcs.all_pix2world to include the SIP distortion. SIP is 
not a part of the WCS standard, so we only perform it when explicitly 
asked for.  See:

https://astropy.readthedocs.org/en/v0.2.4/_generated/astropy.wcs.wcs.WCS.html#astropy.wcs.wcs.WCS.wcs_pix2world

Mike

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131018/42ccd517/attachment.html>

From d.berry at jach.hawaii.edu  Fri Oct 18 08:36:22 2013
From: d.berry at jach.hawaii.edu (David Berry)
Date: Fri, 18 Oct 2013 13:36:22 +0100
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <5261204C.5050208@stsci.edu>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
	<525E9B77.9020105@arcor.de>
	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>
	<525FC9FB.3080906@arcor.de>
	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>
	<525FF421.40105@arcor.de>
	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>
	<5260022D.5040902@arcor.de>
	<CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
	<5261204C.5050208@stsci.edu>
Message-ID: <CAALafn7ofw40ZYAOOKjcM9-rSU0aeDZa0epSSXQ=+A9SYJRPYQ@mail.gmail.com>

On 18 October 2013 12:49, Michael Droettboom <mdroe at stsci.edu> wrote:

>  On 10/18/2013 04:54 AM, David Berry wrote:
>
>
>
>
> On 17 October 2013 16:28, Maik Riechert <maik.riechert at arcor.de> wrote:
>
>  I didn't use tranGrid here, just tran! So no tolerance involved.
>>
>
>  Doh! Sorry - didn't spot that.
>
>
>>
>> NAXIS1  =                 1468 / image
>> width
>> NAXIS2  =                  916 / image
>> height
>> CTYPE1  = 'RA---TAN-SIP' / TAN (gnomic) projection + SIP distortions
>> CTYPE2  = 'DEC--TAN-SIP' / TAN (gnomic) projection + SIP distortions
>> EQUINOX =               2000.0 / Equatorial coordinates definition (yr)
>> LONPOLE =                180.0 / no
>> comment
>> LATPOLE =                  0.0 / no
>> comment
>> CRVAL1  =         302.88771538 / RA  of reference
>> point
>> CRVAL2  =        41.8941029213 / DEC of reference
>> point
>> CRPIX1  =                  735 / X reference
>> pixel
>> CRPIX2  =                  459 / Y reference
>> pixel
>> CUNIT1  = 'deg     ' / X pixel scale
>> units
>> CUNIT2  = 'deg     ' / Y pixel scale
>> units
>> CD1_1   =     -0.0157184611387 / Transformation
>> matrix
>> CD1_2   =     0.00022032143241 / no
>> comment
>> CD2_1   =   -0.000284856284919 / no
>> comment
>> CD2_2   =     -0.0159943489114 / no
>> comment
>> IMAGEW  =                 1468 / Image width,  in
>> pixels.
>> IMAGEH  =                  916 / Image height, in
>> pixels.
>> A_ORDER =                    2 / Polynomial order, axis
>> 1
>> A_0_2   =   -5.10167355829E-05 / no
>> comment
>> A_1_1   =   -5.54267287337E-05 / no
>> comment
>> A_2_0   =    3.68095680847E-05 / no
>> comment
>> B_ORDER =                    2 / Polynomial order, axis
>> 2
>> B_0_2   =    2.49853669312E-05 / no
>> comment
>> B_1_1   =    6.07756179822E-05 / no
>> comment
>> B_2_0   =   -1.70350503136E-05 / no
>> comment
>> AP_ORDER=                    2 / Inv polynomial order, axis
>> 1
>> AP_0_1  =     -0.0014471978634 / no
>> comment
>> AP_0_2  =     5.0935282476E-05 / no
>> comment
>> AP_1_0  =    0.000641040653934 / no
>> comment
>> AP_1_1  =    5.54267224252E-05 / no
>> comment
>> AP_2_0  =     -3.674588665E-05 / no
>> comment
>> BP_ORDER=                    2 / Inv polynomial order, axis
>> 2
>> BP_0_1  =      0.0010860421788 / no
>> comment
>> BP_0_2  =   -2.49999638422E-05 / no
>> comment
>> BP_1_0  =   -0.000569392740582 / no
>> comment
>> BP_1_1  =   -6.07473585161E-05 / no comment
>> BP_2_0  =     1.7000827442E-05 / no comment
>>
>
>  OK - so I suspect the problems may actually be in astropy rather than
> AST.  Maybe the maintainers of astropy.wcs could comment.
>
>  The above header includes a polynomial distortion correction using the
> Spitzer SIP conventions. The "A_" and "B_" headers give the coefficients of
> the forward ( (x,y) to (ra,dec) ) polynomial, and the "AP_" and "BP_"
> headers give the coefficients of the inverse ( (ra,dec) to (x,y) )
> polynomial.
>
>  Using the header as supplied to transform the following pixel positions:
>
>  x = -196, 735, 4059
> y = -504, 459, 2328
>
>  I get, using AST (converted to degrees):
>
>  ra = 328.090902, 302.887715, 265.839543
> dec = 53.570723, 41.894103, 8.257963
>
>  whereas astropy gives:
>
>  ra = 326.992376, 302.866900, 263.545072
> dec = 54.749009, 41.877821, 10.589047
>
>  For an independent check I also used SAO WCSTools which gave:
>
>  ra =  328.09090, 302.88772, 265.83954
> dec = 53.57072, 41.89410, 8.25796
>
>  So AST and WCSTools agree, but astropy is different. This is not
> conclusive in itself, but I then modified the header by removing all the
> SIP keywords and removing "-SIP" from the CTYPE1/2 headers. With these
> changes the header represents an undistorted TAN projection. I then
> transformed the same pixel positions again using the changed header:
>
>  AST gave:
>
>  ra = 327.022569, 302.887715, 263.548641
> dec = 54.758313, 41.894103, 10.599558
>
>  astropy gave:
>
>  ra = 326.992376, 302.866900, 263.545072
> dec = 54.749009, 41.877822, 10.589047
>
>  and WCSTools gave:
>
>  ra = 327.02257, 302.88772, 263.54864
> dec = 54.75831, 41.89410, 10.59956
>
>  So again AST and WCSTools agree, with astropy as the odd one out. But
> more importantly, the astropy results are exactly the same as when using
> the header that includes the SIP distortion. This seems to indicate that in
> fact astropy is ignoring the SIP distortion. You can see that the astropy
> values are much closer to the AST/WCSTools values when no distortion is
> included.
>
>
> You need to use wcs.all_pix2world to include the SIP distortion.  SIP is
> not a part of the WCS standard, so we only perform it when explicitly asked
> for.  See:
>
>
> https://astropy.readthedocs.org/en/v0.2.4/_generated/astropy.wcs.wcs.WCS.html#astropy.wcs.wcs.WCS.wcs_pix2world
>
>
Sorry - I didn't read the docs carefully enough.  So does application code
need to decide for itself whether to use "wcs_*" or "all_*" functions,
based on its own interpretation of the header? Or is it safe just to use
"all_*" all the time, for both standard and non-standard headers? If that's
the case, then some confusion may be avoided by removing "wcs_*"
 altogether.

Using all_pix2world, I now get:

ra = 328.059328, 302.866902, 265.838882
dec = 53.564017, 41.877821, 8.245622

which are much closer to the AST/WCSTools values:

ra = 328.090902, 302.887715, 265.839543
dec = 53.570723, 41.894103, 8.257963

but there is still a discrepancy of about a pixel. Also, it is still the
case that the (ra,dec) values given by astropy at the reference pixel
(735,459) are not equal to (crval1,crval2), which they should be since the
forward polynomial in the header contains no offset terms (A_0_0 or B_0_0).

Answering my own question from the start of this email, I tried
using all_world2pix on a standard header formed by stripping out all the
SIP stuff, and I got the appended error.

David



/usr/lib64/python2.7/site-packages/scipy/optimize/nonlin.py:942:
RuntimeWarning: invalid value encountered in divide
  d = v / vdot(df, v)
Traceback (most recent call last):
  File "./aa.py", line 80, in <module>
    x, y = mywcs3.all_world2pix(ra, dec, 0)
  File
"/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
line 1177, in all_world2pix
    **kwargs)
  File
"/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
line 990, in _array_converter
    return _return_list_of_arrays(axes, origin)
  File
"/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
line 946, in _return_list_of_arrays
    output = func(xy, origin)
  File
"/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
line 1175, in <lambda>
    self._all_world2pix(*args, tolerance=tolerance, **kwargs),
  File
"/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
line 1166, in _all_world2pix
    soln = scipy.optimize.broyden1(func, x0, x_tol=tolerance)
  File "<string>", line 8, in broyden1
  File "/usr/lib64/python2.7/site-packages/scipy/optimize/nonlin.py", line
330, in nonlin_solve
    raise NoConvergence(_array_like(x, x0))
scipy.optimize.nonlin.NoConvergence: [-196. -504.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131018/99ab238b/attachment.html>

From d.berry at jach.hawaii.edu  Fri Oct 18 08:48:19 2013
From: d.berry at jach.hawaii.edu (David Berry)
Date: Fri, 18 Oct 2013 13:48:19 +0100
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
	<525E9B77.9020105@arcor.de>
	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>
	<525FC9FB.3080906@arcor.de>
	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>
	<525FF421.40105@arcor.de>
	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>
	<5260022D.5040902@arcor.de>
	<CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
Message-ID: <CAALafn6tNYm11xBB00Qe6BuVopKxFdhL5FJW_fEb5BP_EibshA@mail.gmail.com>

On 18 October 2013 09:54, David Berry <d.berry at jach.hawaii.edu> wrote:

>
> Now regarding the inverse transformation back from (ra,dec) to (x,y).
> [...] If the distortion is included, AST gives:
>
> x = -205.93, 735, 4179.93
> y = -499.37, 459, 2246.86
>
> WCSTools gives exactly the same values. This poor performance of AST and
> WCSTools when including the distortion indicates that the coefficients of
> the inverse polynomial included in the header (the "AP_" and "BP_" headers)
> are inaccurate.  But AST has a facility to handle SIP headers that do not
> include an inverse polynomial. In such cases, AST creates an inverse itself
> by numerical inversion of the supplied forward polynomial. So if I remove
> the "AP_" and "BP_" keywords from the header, and again transform the
> (ra,dec) values back into (x,y) AST now gives:
>
> x = -197.19, 735, 4061.94
> y = -502.92, 459, 2324.94
>
> which are much better but still not good. AST includes two alternative
> schemes for implementing a missing SIP inverse:
>
> 1) it samples the forward transformation at a regular grid of pixel
> positions and fits a polynomial surface to the results. This fit is
> performed once, and if the residuals of the fit are sufficiently small, it
> is then used to transform all subsequent points.
>
> 2) if the residuals of the above fit are too large, then each individual
> (ra,dec) position is transformed using an iterative Newton-Raphson method.
> This is much slower over-all than 1) but more accurate.
>
> There is a problem in AST in that it is using option 1) above for your
> header, when in fact it needs to use 2) to get sufficient accuracy.  The
> recovered (x,y) values quoted above were created using option 1). With
> option 2), the exact original (x,y) values are recovered to within 0.01
> pixel.
>
> I shall investigate this issue in AST. Thanks for the input.
>

In case you are interested, I've modified AST (v7.3.3) and pyast (v2.5) to
fix this.

Since I have come across several SIP headers that contain badly inaccurate
values for the inverse polynomial, I've followed astropy's lead and changed
AST so that it *always* calculates it's own inverse, ignoring any inverse
in the header.

The errors in the reconstructed (x,y) values were caused by the points
being way outside the bounds of the image. When AST calculates a fit to the
inverse, it previously used a grid that had the same bounds as the image,
so points outside this area were under-constrained, leading to poor fits
and bad errors. I've changed it so that the fit is now done on a much
larger area, and to a much  higher accuracy.  In the particular case of
your header, the fit fails to achieve the required accuracy and so the
transformation reverts to the Newton Raphson approach, which is slower but
more accurate.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131018/b5d62a32/attachment.html>

From hodge at stsci.edu  Fri Oct 18 08:56:47 2013
From: hodge at stsci.edu (Phil Hodge)
Date: Fri, 18 Oct 2013 08:56:47 -0400
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAALafn6tNYm11xBB00Qe6BuVopKxFdhL5FJW_fEb5BP_EibshA@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
	<525E9B77.9020105@arcor.de>
	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>
	<525FC9FB.3080906@arcor.de>
	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>
	<525FF421.40105@arcor.de>
	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>
	<5260022D.5040902@arcor.de>
	<CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
	<CAALafn6tNYm11xBB00Qe6BuVopKxFdhL5FJW_fEb5BP_EibshA@mail.gmail.com>
Message-ID: <5261300F.5010901@stsci.edu>

On 10/18/2013 08:48 AM, David Berry wrote:
> Since I have come across several SIP headers that contain badly 
> inaccurate values for the inverse polynomial, I've followed astropy's 
> lead and changed AST so that it *always* calculates it's own inverse, 
> ignoring any inverse in the header.

How do you know it's the inverse transform that's wrong, rather than the 
forward transform?  It seems to me that if the inverse transform is 
specified in the header, that's what should be used.

Phil


From thomas.robitaille at gmail.com  Fri Oct 18 09:01:53 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Fri, 18 Oct 2013 15:01:53 +0200
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAALafn7ofw40ZYAOOKjcM9-rSU0aeDZa0epSSXQ=+A9SYJRPYQ@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
	<525E9B77.9020105@arcor.de>
	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>
	<525FC9FB.3080906@arcor.de>
	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>
	<525FF421.40105@arcor.de>
	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>
	<5260022D.5040902@arcor.de>
	<CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
	<5261204C.5050208@stsci.edu>
	<CAALafn7ofw40ZYAOOKjcM9-rSU0aeDZa0epSSXQ=+A9SYJRPYQ@mail.gmail.com>
Message-ID: <CAGMHX_1EfA=Y51oiN-qV6VNEJO_u-DTBErOu9cexwdhgaQ45Eg@mail.gmail.com>

In the Astropy routine, you need to take care to set the origin
correctly (the last argument in the call to all_pix2world) - if it is
set to zero, the pixel coordinates have to be zero based (the bottom
left corner of the FITS image is then (0,0)). Tools such as ds9 assume
the bottom left corner is (1,1). Since you mention a 1 pixel offset, I
thought it could be related to this. Does AST always assume the pixel
values are 1-based?

Cheers,
Tom


On 18 October 2013 14:36, David Berry <d.berry at jach.hawaii.edu> wrote:
>
>
>
> On 18 October 2013 12:49, Michael Droettboom <mdroe at stsci.edu> wrote:
>>
>> On 10/18/2013 04:54 AM, David Berry wrote:
>>
>>
>>
>>
>> On 17 October 2013 16:28, Maik Riechert <maik.riechert at arcor.de> wrote:
>>
>>> I didn't use tranGrid here, just tran! So no tolerance involved.
>>
>>
>> Doh! Sorry - didn't spot that.
>>
>>>
>>>
>>> NAXIS1  =                 1468 / image width
>>> NAXIS2  =                  916 / image height
>>> CTYPE1  = 'RA---TAN-SIP' / TAN (gnomic) projection + SIP distortions
>>> CTYPE2  = 'DEC--TAN-SIP' / TAN (gnomic) projection + SIP distortions
>>> EQUINOX =               2000.0 / Equatorial coordinates definition (yr)
>>> LONPOLE =                180.0 / no comment
>>> LATPOLE =                  0.0 / no comment
>>> CRVAL1  =         302.88771538 / RA  of reference point
>>> CRVAL2  =        41.8941029213 / DEC of reference point
>>> CRPIX1  =                  735 / X reference pixel
>>> CRPIX2  =                  459 / Y reference pixel
>>> CUNIT1  = 'deg     ' / X pixel scale units
>>> CUNIT2  = 'deg     ' / Y pixel scale units
>>> CD1_1   =     -0.0157184611387 / Transformation matrix
>>> CD1_2   =     0.00022032143241 / no comment
>>> CD2_1   =   -0.000284856284919 / no comment
>>> CD2_2   =     -0.0159943489114 / no comment
>>> IMAGEW  =                 1468 / Image width,  in pixels.
>>> IMAGEH  =                  916 / Image height, in pixels.
>>> A_ORDER =                    2 / Polynomial order, axis 1
>>> A_0_2   =   -5.10167355829E-05 / no comment
>>> A_1_1   =   -5.54267287337E-05 / no comment
>>> A_2_0   =    3.68095680847E-05 / no comment
>>> B_ORDER =                    2 / Polynomial order, axis 2
>>> B_0_2   =    2.49853669312E-05 / no comment
>>> B_1_1   =    6.07756179822E-05 / no comment
>>> B_2_0   =   -1.70350503136E-05 / no comment
>>> AP_ORDER=                    2 / Inv polynomial order, axis 1
>>> AP_0_1  =     -0.0014471978634 / no comment
>>> AP_0_2  =     5.0935282476E-05 / no comment
>>> AP_1_0  =    0.000641040653934 / no comment
>>> AP_1_1  =    5.54267224252E-05 / no comment
>>> AP_2_0  =     -3.674588665E-05 / no comment
>>> BP_ORDER=                    2 / Inv polynomial order, axis 2
>>> BP_0_1  =      0.0010860421788 / no comment
>>> BP_0_2  =   -2.49999638422E-05 / no comment
>>> BP_1_0  =   -0.000569392740582 / no comment
>>> BP_1_1  =   -6.07473585161E-05 / no comment
>>> BP_2_0  =     1.7000827442E-05 / no comment
>>
>>
>> OK - so I suspect the problems may actually be in astropy rather than AST.
>> Maybe the maintainers of astropy.wcs could comment.
>>
>> The above header includes a polynomial distortion correction using the
>> Spitzer SIP conventions. The "A_" and "B_" headers give the coefficients of
>> the forward ( (x,y) to (ra,dec) ) polynomial, and the "AP_" and "BP_"
>> headers give the coefficients of the inverse ( (ra,dec) to (x,y) )
>> polynomial.
>>
>> Using the header as supplied to transform the following pixel positions:
>>
>> x = -196, 735, 4059
>> y = -504, 459, 2328
>>
>> I get, using AST (converted to degrees):
>>
>> ra = 328.090902, 302.887715, 265.839543
>> dec = 53.570723, 41.894103, 8.257963
>>
>> whereas astropy gives:
>>
>> ra = 326.992376, 302.866900, 263.545072
>> dec = 54.749009, 41.877821, 10.589047
>>
>> For an independent check I also used SAO WCSTools which gave:
>>
>> ra =  328.09090, 302.88772, 265.83954
>> dec = 53.57072, 41.89410, 8.25796
>>
>> So AST and WCSTools agree, but astropy is different. This is not
>> conclusive in itself, but I then modified the header by removing all the SIP
>> keywords and removing "-SIP" from the CTYPE1/2 headers. With these changes
>> the header represents an undistorted TAN projection. I then transformed the
>> same pixel positions again using the changed header:
>>
>> AST gave:
>>
>> ra = 327.022569, 302.887715, 263.548641
>> dec = 54.758313, 41.894103, 10.599558
>>
>> astropy gave:
>>
>> ra = 326.992376, 302.866900, 263.545072
>> dec = 54.749009, 41.877822, 10.589047
>>
>> and WCSTools gave:
>>
>> ra = 327.02257, 302.88772, 263.54864
>> dec = 54.75831, 41.89410, 10.59956
>>
>> So again AST and WCSTools agree, with astropy as the odd one out. But more
>> importantly, the astropy results are exactly the same as when using the
>> header that includes the SIP distortion. This seems to indicate that in fact
>> astropy is ignoring the SIP distortion. You can see that the astropy values
>> are much closer to the AST/WCSTools values when no distortion is included.
>>
>>
>> You need to use wcs.all_pix2world to include the SIP distortion.  SIP is
>> not a part of the WCS standard, so we only perform it when explicitly asked
>> for.  See:
>>
>>
>> https://astropy.readthedocs.org/en/v0.2.4/_generated/astropy.wcs.wcs.WCS.html#astropy.wcs.wcs.WCS.wcs_pix2world
>>
>
> Sorry - I didn't read the docs carefully enough.  So does application code
> need to decide for itself whether to use "wcs_*" or "all_*" functions, based
> on its own interpretation of the header? Or is it safe just to use "all_*"
> all the time, for both standard and non-standard headers? If that's the
> case, then some confusion may be avoided by removing "wcs_*"  altogether.
>
> Using all_pix2world, I now get:
>
> ra = 328.059328, 302.866902, 265.838882
> dec = 53.564017, 41.877821, 8.245622
>
> which are much closer to the AST/WCSTools values:
>
> ra = 328.090902, 302.887715, 265.839543
> dec = 53.570723, 41.894103, 8.257963
>
> but there is still a discrepancy of about a pixel. Also, it is still the
> case that the (ra,dec) values given by astropy at the reference pixel
> (735,459) are not equal to (crval1,crval2), which they should be since the
> forward polynomial in the header contains no offset terms (A_0_0 or B_0_0).
>
> Answering my own question from the start of this email, I tried using
> all_world2pix on a standard header formed by stripping out all the SIP
> stuff, and I got the appended error.
>
> David
>
>
>
> /usr/lib64/python2.7/site-packages/scipy/optimize/nonlin.py:942:
> RuntimeWarning: invalid value encountered in divide
>   d = v / vdot(df, v)
> Traceback (most recent call last):
>   File "./aa.py", line 80, in <module>
>     x, y = mywcs3.all_world2pix(ra, dec, 0)
>   File
> "/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
> line 1177, in all_world2pix
>     **kwargs)
>   File
> "/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
> line 990, in _array_converter
>     return _return_list_of_arrays(axes, origin)
>   File
> "/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
> line 946, in _return_list_of_arrays
>     output = func(xy, origin)
>   File
> "/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
> line 1175, in <lambda>
>     self._all_world2pix(*args, tolerance=tolerance, **kwargs),
>   File
> "/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
> line 1166, in _all_world2pix
>     soln = scipy.optimize.broyden1(func, x0, x_tol=tolerance)
>   File "<string>", line 8, in broyden1
>   File "/usr/lib64/python2.7/site-packages/scipy/optimize/nonlin.py", line
> 330, in nonlin_solve
>     raise NoConvergence(_array_like(x, x0))
> scipy.optimize.nonlin.NoConvergence: [-196. -504.]
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From maik.riechert at arcor.de  Fri Oct 18 09:05:37 2013
From: maik.riechert at arcor.de (Maik Riechert)
Date: Fri, 18 Oct 2013 15:05:37 +0200
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAALafn6tNYm11xBB00Qe6BuVopKxFdhL5FJW_fEb5BP_EibshA@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>	<525E9B77.9020105@arcor.de>	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>	<525FC9FB.3080906@arcor.de>	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>	<525FF421.40105@arcor.de>	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>	<5260022D.5040902@arcor.de>	<CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
	<CAALafn6tNYm11xBB00Qe6BuVopKxFdhL5FJW_fEb5BP_EibshA@mail.gmail.com>
Message-ID: <52613221.5090603@arcor.de>


On 18/10/13 14:48, David Berry wrote:
>
>
>
> On 18 October 2013 09:54, David Berry <d.berry at jach.hawaii.edu 
> <mailto:d.berry at jach.hawaii.edu>> wrote:
>
>
>     Now regarding the inverse transformation back from (ra,dec) to
>     (x,y). [...] If the distortion is included, AST gives:
>
>     x = -205.93, 735, 4179.93
>     y = -499.37, 459, 2246.86
>
>     WCSTools gives exactly the same values. This poor performance of
>     AST and WCSTools when including the distortion indicates that the
>     coefficients of the inverse polynomial included in the header (the
>     "AP_" and "BP_" headers) are inaccurate.  But AST has a facility
>     to handle SIP headers that do not include an inverse polynomial.
>     In such cases, AST creates an inverse itself by numerical
>     inversion of the supplied forward polynomial. So if I remove the
>     "AP_" and "BP_" keywords from the header, and again transform the
>     (ra,dec) values back into (x,y) AST now gives:
>
>     x = -197.19, 735, 4061.94
>     y = -502.92, 459, 2324.94
>
>     which are much better but still not good. AST includes two
>     alternative schemes for implementing a missing SIP inverse:
>
>     1) it samples the forward transformation at a regular grid of
>     pixel positions and fits a polynomial surface to the results. This
>     fit is performed once, and if the residuals of the fit are
>     sufficiently small, it is then used to transform all subsequent
>     points.
>
>     2) if the residuals of the above fit are too large, then each
>     individual (ra,dec) position is transformed using an iterative
>     Newton-Raphson method. This is much slower over-all than 1) but
>     more accurate.
>
>     There is a problem in AST in that it is using option 1) above for
>     your header, when in fact it needs to use 2) to get sufficient
>     accuracy.  The recovered (x,y) values quoted above were created
>     using option 1). With option 2), the exact original (x,y) values
>     are recovered to within 0.01 pixel.
>
>     I shall investigate this issue in AST. Thanks for the input.
>
>
> In case you are interested, I've modified AST (v7.3.3) and pyast 
> (v2.5) to fix this.
>
> Since I have come across several SIP headers that contain badly 
> inaccurate values for the inverse polynomial, I've followed astropy's 
> lead and changed AST so that it *always* calculates it's own inverse, 
> ignoring any inverse in the header.
>
> The errors in the reconstructed (x,y) values were caused by the points 
> being way outside the bounds of the image. When AST calculates a fit 
> to the inverse, it previously used a grid that had the same bounds as 
> the image, so points outside this area were under-constrained, leading 
> to poor fits and bad errors. I've changed it so that the fit is now 
> done on a much larger area, and to a much  higher accuracy.  In the 
> particular case of your header, the fit fails to achieve the 
> required accuracy and so the transformation reverts to the Newton 
> Raphson approach, which is slower but more accurate.
>
> David

I used astrometry.net to get the WCS headers, and for that I had to crop 
the original image such that only the starfield is visible (the original 
image contained some 'earthly' structures). But after that I actually 
need coordinates of the whole original image, that is, pixels which were 
outside the image used for astrometry solving. So it sounds like your 
latter change should be useful for that case.

Maik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131018/b7a17c95/attachment.html>

From d.berry at jach.hawaii.edu  Fri Oct 18 09:18:11 2013
From: d.berry at jach.hawaii.edu (David Berry)
Date: Fri, 18 Oct 2013 14:18:11 +0100
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <5261300F.5010901@stsci.edu>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
	<525E9B77.9020105@arcor.de>
	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>
	<525FC9FB.3080906@arcor.de>
	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>
	<525FF421.40105@arcor.de>
	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>
	<5260022D.5040902@arcor.de>
	<CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
	<CAALafn6tNYm11xBB00Qe6BuVopKxFdhL5FJW_fEb5BP_EibshA@mail.gmail.com>
	<5261300F.5010901@stsci.edu>
Message-ID: <CAALafn5mvDfpGbKE1fsmLtofcYau60GCAQ9PVYox7EOK6GnN6Q@mail.gmail.com>

On 18 October 2013 13:56, Phil Hodge <hodge at stsci.edu> wrote:

> On 10/18/2013 08:48 AM, David Berry wrote:
> > Since I have come across several SIP headers that contain badly
> > inaccurate values for the inverse polynomial, I've followed astropy's
> > lead and changed AST so that it *always* calculates it's own inverse,
> > ignoring any inverse in the header.
>
> How do you know it's the inverse transform that's wrong, rather than the
> forward transform?


That's a good question. I'm basing it on the assumption that in practice
people will probably determine the forward transformation directly, and get
the inverse from some sort of inversion of the forward transformation. So
the forward transformation is likely to be more accurate.


>  It seems to me that if the inverse transform is
> specified in the header, that's what should be used
>

I've come across several cases where the inverse transformation is not a
true inverse of the forward transformation. As in the case of Maik's
header, if you go from (x,y) to (ra,dec), and then back to (x,y) using the
inverse contained in the header, the (x,y) you end up with can be a long
way from the one you started with. Clearly such inverses are not very
helpful.

Maybe the thing to do is to do some tests on the supplied inverse, and only
replace it if it looks inaccurate.

It may be the case that the inverse in the header is only accurate over
some limited domain.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131018/e46c51f4/attachment.html>

From d.berry at jach.hawaii.edu  Fri Oct 18 09:44:40 2013
From: d.berry at jach.hawaii.edu (David Berry)
Date: Fri, 18 Oct 2013 14:44:40 +0100
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAGMHX_1EfA=Y51oiN-qV6VNEJO_u-DTBErOu9cexwdhgaQ45Eg@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>
	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>
	<525E9B77.9020105@arcor.de>
	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>
	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>
	<525FC9FB.3080906@arcor.de>
	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>
	<525FF421.40105@arcor.de>
	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>
	<5260022D.5040902@arcor.de>
	<CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
	<5261204C.5050208@stsci.edu>
	<CAALafn7ofw40ZYAOOKjcM9-rSU0aeDZa0epSSXQ=+A9SYJRPYQ@mail.gmail.com>
	<CAGMHX_1EfA=Y51oiN-qV6VNEJO_u-DTBErOu9cexwdhgaQ45Eg@mail.gmail.com>
Message-ID: <CAALafn6ZMeegSqPMQ197UewiMJrEo+g5XmvHXk6T6wRkx8tzuQ@mail.gmail.com>

On 18 October 2013 14:01, Thomas Robitaille <thomas.robitaille at gmail.com>wrote:

> In the Astropy routine, you need to take care to set the origin
> correctly (the last argument in the call to all_pix2world) - if it is
> set to zero, the pixel coordinates have to be zero based (the bottom
> left corner of the FITS image is then (0,0)). Tools such as ds9 assume
> the bottom left corner is (1,1). Since you mention a 1 pixel offset, I
> thought it could be related to this.


Thanks for the tip. That indeed clears up the discrepancy.


> Does AST always assume the pixel
> values are 1-based?
>
>
It all depends on the context. The FitsChan class takes in a set of FITS
headers and spits out a network of Frames with interconnecting Mappings
(a.k.a. "FrameSet"). One Frame represents pixel coordinates, and the others
represent the primary and alternate world coordinate systems.  In this
context, a position of (1,1) in the pixel frame corresponds to the first
pixel in the data array, because that's the convention used by FITS.  For
instance, this means that a pixel position of (crpix1,crpix2) gets mapped
onto a world position of (crval1,crval2), as required by the published
FITS-WCS papers.

On the other hand, there is nothing to stop a user from adding a second
pixel frame into this FrameSet to define some alternative pixel coordinate
system that is shifted with respect to FITS pixel coordinates.

Indeed, this is *exactly* what is done by the NDF data format that has been
in use by Starlink for 20 plus years. It defines two pixel coordinate
systems - "GRID" coordinates in which the first pixel has coords (1,1)
(i.e. the usual FITS definition), and "PIXEL" coordinates which is shifted
by an arbitrary amount with respect to GRID coords. The NDF format uses AST
to record the transformation between these two systems, and all the other
coordinate systems it knows about. For instance, this means that if you
take a cut-out of an image, then the user can there-after choose to refer
to pixels within the cut-out using either their offset from first pixel in
the cut-out (i.e. GRID coords), or their offset from the first pixel in the
in the original image (PIXEL coords).

So the bottom line is that AST allows you to put the origin of pixels
coords where ever you want.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131018/19f12f24/attachment.html>

From maik.riechert at arcor.de  Fri Oct 18 10:01:52 2013
From: maik.riechert at arcor.de (Maik Riechert)
Date: Fri, 18 Oct 2013 16:01:52 +0200
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAGMHX_1EfA=Y51oiN-qV6VNEJO_u-DTBErOu9cexwdhgaQ45Eg@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>	<525E9B77.9020105@arcor.de>	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>	<525FC9FB.3080906@arcor.de>	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>	<525FF421.40105@arcor.de>	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>	<5260022D.5040902@arcor.de>	<CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>	<5261204C.5050208@stsci.edu>	<CAALafn7ofw40ZYAOOKjcM9-rSU0aeDZa0epSSXQ=+A9SYJRPYQ@mail.gmail.com>
	<CAGMHX_1EfA=Y51oiN-qV6VNEJO_u-DTBErOu9cexwdhgaQ45Eg@mail.gmail.com>
Message-ID: <52613F50.4010205@arcor.de>

Tom, by "if it is set to zero, the pixel coordinates have to be zero 
based" do you include in that the reference pixel coordinate in the FITS 
header? If yes, then there's not really a choice here to say it's 
zero-based, as the FITS standard is 1-based?

Cheers
Maik

On 18/10/13 15:01, Thomas Robitaille wrote:
> In the Astropy routine, you need to take care to set the origin
> correctly (the last argument in the call to all_pix2world) - if it is
> set to zero, the pixel coordinates have to be zero based (the bottom
> left corner of the FITS image is then (0,0)). Tools such as ds9 assume
> the bottom left corner is (1,1). Since you mention a 1 pixel offset, I
> thought it could be related to this. Does AST always assume the pixel
> values are 1-based?
>
> Cheers,
> Tom
>
>
> On 18 October 2013 14:36, David Berry <d.berry at jach.hawaii.edu> wrote:
>>
>>
>> On 18 October 2013 12:49, Michael Droettboom <mdroe at stsci.edu> wrote:
>>> On 10/18/2013 04:54 AM, David Berry wrote:
>>>
>>>
>>>
>>>
>>> On 17 October 2013 16:28, Maik Riechert <maik.riechert at arcor.de> wrote:
>>>
>>>> I didn't use tranGrid here, just tran! So no tolerance involved.
>>>
>>> Doh! Sorry - didn't spot that.
>>>
>>>>
>>>> NAXIS1  =                 1468 / image width
>>>> NAXIS2  =                  916 / image height
>>>> CTYPE1  = 'RA---TAN-SIP' / TAN (gnomic) projection + SIP distortions
>>>> CTYPE2  = 'DEC--TAN-SIP' / TAN (gnomic) projection + SIP distortions
>>>> EQUINOX =               2000.0 / Equatorial coordinates definition (yr)
>>>> LONPOLE =                180.0 / no comment
>>>> LATPOLE =                  0.0 / no comment
>>>> CRVAL1  =         302.88771538 / RA  of reference point
>>>> CRVAL2  =        41.8941029213 / DEC of reference point
>>>> CRPIX1  =                  735 / X reference pixel
>>>> CRPIX2  =                  459 / Y reference pixel
>>>> CUNIT1  = 'deg     ' / X pixel scale units
>>>> CUNIT2  = 'deg     ' / Y pixel scale units
>>>> CD1_1   =     -0.0157184611387 / Transformation matrix
>>>> CD1_2   =     0.00022032143241 / no comment
>>>> CD2_1   =   -0.000284856284919 / no comment
>>>> CD2_2   =     -0.0159943489114 / no comment
>>>> IMAGEW  =                 1468 / Image width,  in pixels.
>>>> IMAGEH  =                  916 / Image height, in pixels.
>>>> A_ORDER =                    2 / Polynomial order, axis 1
>>>> A_0_2   =   -5.10167355829E-05 / no comment
>>>> A_1_1   =   -5.54267287337E-05 / no comment
>>>> A_2_0   =    3.68095680847E-05 / no comment
>>>> B_ORDER =                    2 / Polynomial order, axis 2
>>>> B_0_2   =    2.49853669312E-05 / no comment
>>>> B_1_1   =    6.07756179822E-05 / no comment
>>>> B_2_0   =   -1.70350503136E-05 / no comment
>>>> AP_ORDER=                    2 / Inv polynomial order, axis 1
>>>> AP_0_1  =     -0.0014471978634 / no comment
>>>> AP_0_2  =     5.0935282476E-05 / no comment
>>>> AP_1_0  =    0.000641040653934 / no comment
>>>> AP_1_1  =    5.54267224252E-05 / no comment
>>>> AP_2_0  =     -3.674588665E-05 / no comment
>>>> BP_ORDER=                    2 / Inv polynomial order, axis 2
>>>> BP_0_1  =      0.0010860421788 / no comment
>>>> BP_0_2  =   -2.49999638422E-05 / no comment
>>>> BP_1_0  =   -0.000569392740582 / no comment
>>>> BP_1_1  =   -6.07473585161E-05 / no comment
>>>> BP_2_0  =     1.7000827442E-05 / no comment
>>>
>>> OK - so I suspect the problems may actually be in astropy rather than AST.
>>> Maybe the maintainers of astropy.wcs could comment.
>>>
>>> The above header includes a polynomial distortion correction using the
>>> Spitzer SIP conventions. The "A_" and "B_" headers give the coefficients of
>>> the forward ( (x,y) to (ra,dec) ) polynomial, and the "AP_" and "BP_"
>>> headers give the coefficients of the inverse ( (ra,dec) to (x,y) )
>>> polynomial.
>>>
>>> Using the header as supplied to transform the following pixel positions:
>>>
>>> x = -196, 735, 4059
>>> y = -504, 459, 2328
>>>
>>> I get, using AST (converted to degrees):
>>>
>>> ra = 328.090902, 302.887715, 265.839543
>>> dec = 53.570723, 41.894103, 8.257963
>>>
>>> whereas astropy gives:
>>>
>>> ra = 326.992376, 302.866900, 263.545072
>>> dec = 54.749009, 41.877821, 10.589047
>>>
>>> For an independent check I also used SAO WCSTools which gave:
>>>
>>> ra =  328.09090, 302.88772, 265.83954
>>> dec = 53.57072, 41.89410, 8.25796
>>>
>>> So AST and WCSTools agree, but astropy is different. This is not
>>> conclusive in itself, but I then modified the header by removing all the SIP
>>> keywords and removing "-SIP" from the CTYPE1/2 headers. With these changes
>>> the header represents an undistorted TAN projection. I then transformed the
>>> same pixel positions again using the changed header:
>>>
>>> AST gave:
>>>
>>> ra = 327.022569, 302.887715, 263.548641
>>> dec = 54.758313, 41.894103, 10.599558
>>>
>>> astropy gave:
>>>
>>> ra = 326.992376, 302.866900, 263.545072
>>> dec = 54.749009, 41.877822, 10.589047
>>>
>>> and WCSTools gave:
>>>
>>> ra = 327.02257, 302.88772, 263.54864
>>> dec = 54.75831, 41.89410, 10.59956
>>>
>>> So again AST and WCSTools agree, with astropy as the odd one out. But more
>>> importantly, the astropy results are exactly the same as when using the
>>> header that includes the SIP distortion. This seems to indicate that in fact
>>> astropy is ignoring the SIP distortion. You can see that the astropy values
>>> are much closer to the AST/WCSTools values when no distortion is included.
>>>
>>>
>>> You need to use wcs.all_pix2world to include the SIP distortion.  SIP is
>>> not a part of the WCS standard, so we only perform it when explicitly asked
>>> for.  See:
>>>
>>>
>>> https://astropy.readthedocs.org/en/v0.2.4/_generated/astropy.wcs.wcs.WCS.html#astropy.wcs.wcs.WCS.wcs_pix2world
>>>
>> Sorry - I didn't read the docs carefully enough.  So does application code
>> need to decide for itself whether to use "wcs_*" or "all_*" functions, based
>> on its own interpretation of the header? Or is it safe just to use "all_*"
>> all the time, for both standard and non-standard headers? If that's the
>> case, then some confusion may be avoided by removing "wcs_*"  altogether.
>>
>> Using all_pix2world, I now get:
>>
>> ra = 328.059328, 302.866902, 265.838882
>> dec = 53.564017, 41.877821, 8.245622
>>
>> which are much closer to the AST/WCSTools values:
>>
>> ra = 328.090902, 302.887715, 265.839543
>> dec = 53.570723, 41.894103, 8.257963
>>
>> but there is still a discrepancy of about a pixel. Also, it is still the
>> case that the (ra,dec) values given by astropy at the reference pixel
>> (735,459) are not equal to (crval1,crval2), which they should be since the
>> forward polynomial in the header contains no offset terms (A_0_0 or B_0_0).
>>
>> Answering my own question from the start of this email, I tried using
>> all_world2pix on a standard header formed by stripping out all the SIP
>> stuff, and I got the appended error.
>>
>> David
>>
>>
>>
>> /usr/lib64/python2.7/site-packages/scipy/optimize/nonlin.py:942:
>> RuntimeWarning: invalid value encountered in divide
>>    d = v / vdot(df, v)
>> Traceback (most recent call last):
>>    File "./aa.py", line 80, in <module>
>>      x, y = mywcs3.all_world2pix(ra, dec, 0)
>>    File
>> "/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
>> line 1177, in all_world2pix
>>      **kwargs)
>>    File
>> "/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
>> line 990, in _array_converter
>>      return _return_list_of_arrays(axes, origin)
>>    File
>> "/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
>> line 946, in _return_list_of_arrays
>>      output = func(xy, origin)
>>    File
>> "/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
>> line 1175, in <lambda>
>>      self._all_world2pix(*args, tolerance=tolerance, **kwargs),
>>    File
>> "/home/dsb/.local/lib/python2.7/site-packages/astropy-0.3.dev5914-py2.7-linux-x86_64.egg/astropy/wcs/wcs.py",
>> line 1166, in _all_world2pix
>>      soln = scipy.optimize.broyden1(func, x0, x_tol=tolerance)
>>    File "<string>", line 8, in broyden1
>>    File "/usr/lib64/python2.7/site-packages/scipy/optimize/nonlin.py", line
>> 330, in nonlin_solve
>>      raise NoConvergence(_array_like(x, x0))
>> scipy.optimize.nonlin.NoConvergence: [-196. -504.]
>>
>>
>>
>> _______________________________________________
>> 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 jturner at gemini.edu  Fri Oct 18 13:42:36 2013
From: jturner at gemini.edu (James Turner)
Date: Fri, 18 Oct 2013 14:42:36 -0300
Subject: [AstroPy] Which ndimage?
Message-ID: <5261730C.8050605@gemini.edu>

Hi Perry et al.,

What's the difference between stsci.ndimage and scipy.ndimage?
I think I already know how we ended up with both, but is there
any reason to use one over the other (or to maintain both)?

Thanks,

JAmes.


From chanley at gmail.com  Fri Oct 18 14:46:27 2013
From: chanley at gmail.com (Christopher Hanley)
Date: Fri, 18 Oct 2013 14:46:27 -0400
Subject: [AstroPy] Which ndimage?
In-Reply-To: <5261730C.8050605@gemini.edu>
References: <5261730C.8050605@gemini.edu>
Message-ID: <42FB7E48-2DAC-4CCB-974B-2618ABAF4FEF@gmail.com>

The stsci.ndimage is a older fork of the scipy version that doesn't have other scipy dependencies.  This was done when numarray was killed and scipy was too difficult an install to require of our end users. Once Ureka is out of beta and is our standard distribution method there will be no reason that stsci.ndimage couldn't go away. 

Cheers,
Chris

> On Oct 18, 2013, at 13:42, James Turner <jturner at gemini.edu> wrote:
> 
> Hi Perry et al.,
> 
> What's the difference between stsci.ndimage and scipy.ndimage?
> I think I already know how we ended up with both, but is there
> any reason to use one over the other (or to maintain both)?
> 
> Thanks,
> 
> JAmes.
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From indiajoe at gmail.com  Fri Oct 18 16:56:44 2013
From: indiajoe at gmail.com (Joe Philip Ninan)
Date: Sat, 19 Oct 2013 02:26:44 +0530
Subject: [AstroPy] iraf's imexamine equivalent in python
Message-ID: <CAJ_T+b6Ro-C5FNsbXEFH0Dp6uX5N0XSXaVZCj1uyfAD+KMpa2w@mail.gmail.com>

Hi,
I am trying to pythonise many of my old Pyraf interactive scripts to as
much pure python as possible. One of the major hurdle is a replacement for
iraf's imexamine.

I have heavily used
imx=iraf.imexam(Stdout=1) after displaying fits in ds9,
mainly to get FWHM, star centroid, radial profile plot and statistics like
sigma, mean etc.

Do we have anything to basically do these interactive things in astropy?

If not, I plan to write one as described below. any suggestions?

1)load fits data as a numpy matrix using pyfits/io.fits
2)display fits using imshow of matplotlib
3)Use keystrokes to choose options like (a,e,r etc. of imexam)
4)Use MouseEvents in matplotlib to pick coordinates from display by
clicking.
5)use numpy to fit 2d gaussian / line to extracted data from matrix
6)use matplotlib to plot those results.

I am not much happy with using matplotlib's imshow to display fits images.
Is there any other display (like ds9) which provides MouseEvents ?
The 3d surface plots in matplotlib, i have found to be very slow when the
matrix is very large.
Even imshow is not very fast for large fits images.

Thanking you,
-cheers
joe





-- 
/---------------------------------------------------------------
"GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation

************************************************
Joe Philip Ninan    http://sites.google.com/site/jpninan/
Research Scholar        /________________\
DAA,                            | Vadakeparambil |
TIFR,                           | Pullad P.O.         |
Mumbai-05, India.      | Kerala, India      |
Ph: +917738438212   | PIN:689548       |
------------------------------\_______________/--------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131019/ba667041/attachment.html>

From indiajoe at gmail.com  Sat Oct 19 08:51:00 2013
From: indiajoe at gmail.com (Joe Philip Ninan)
Date: Sat, 19 Oct 2013 18:21:00 +0530
Subject: [AstroPy] iraf's imexamine equivalent in python
In-Reply-To: <5261ADCB.6020705@gmail.com>
References: <CAJ_T+b6Ro-C5FNsbXEFH0Dp6uX5N0XSXaVZCj1uyfAD+KMpa2w@mail.gmail.com>
	<5261ADCB.6020705@gmail.com>
Message-ID: <CAJ_T+b4KfvMLyXy4S4_tsNdKZRvFkjG5GPDCmUH0caVnON6VTg@mail.gmail.com>

Hi Thoger,
Thanks for the ginga link.
It seems to be the one i should be using.
Right now going through their docs to see how to talk to it and retrieve
outputs from python script.
Thanks,
-cheers
joe



On 19 October 2013 03:23, Th?ger Emil Rivera-Thorsen
<thoger.emil at gmail.com>wrote:

>  It sounds like maybe Ginga would be a good starting point for you, if in
> fact it doesn't already have the functionality you want...?
>
> http://ejeschke.github.io/ginga/
>
>
>
>
> On 18-10-2013 22:56, Joe Philip Ninan wrote:
>
>   Hi,
> I am trying to pythonise many of my old Pyraf interactive scripts to as
> much pure python as possible. One of the major hurdle is a replacement for
> iraf's imexamine.
>
>  I have heavily used
> imx=iraf.imexam(Stdout=1) after displaying fits in ds9,
>  mainly to get FWHM, star centroid, radial profile plot and statistics
> like sigma, mean etc.
>
>  Do we have anything to basically do these interactive things in astropy?
>
>  If not, I plan to write one as described below. any suggestions?
>
>  1)load fits data as a numpy matrix using pyfits/io.fits
>    2)display fits using imshow of matplotlib
>  3)Use keystrokes to choose options like (a,e,r etc. of imexam)
> 4)Use MouseEvents in matplotlib to pick coordinates from display by
> clicking.
>  5)use numpy to fit 2d gaussian / line to extracted data from matrix
>  6)use matplotlib to plot those results.
>
>  I am not much happy with using matplotlib's imshow to display fits
> images.
> Is there any other display (like ds9) which provides MouseEvents ?
>  The 3d surface plots in matplotlib, i have found to be very slow when
> the matrix is very large.
>  Even imshow is not very fast for large fits images.
>
>  Thanking you,
>  -cheers
> joe
>
>
>
>
>
> --
> /---------------------------------------------------------------
> "GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation
>
> ************************************************
> Joe Philip Ninan    http://sites.google.com/site/jpninan/
> Research Scholar        /________________\
> DAA,                            | Vadakeparambil |
> TIFR,                           | Pullad P.O.         |
> Mumbai-05, India.      | Kerala, India      |
> Ph: +917738438212   | PIN:689548       |
> ------------------------------\_______________/--------------
>
>
> _______________________________________________
> AstroPy mailing listAstroPy at scipy.orghttp://mail.scipy.org/mailman/listinfo/astropy
>
>
>


-- 
/---------------------------------------------------------------
"GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation

************************************************
Joe Philip Ninan    http://sites.google.com/site/jpninan/
Research Scholar        /________________\
DAA,                            | Vadakeparambil |
TIFR,                           | Pullad P.O.         |
Mumbai-05, India.      | Kerala, India      |
Ph: +917738438212   | PIN:689548       |
------------------------------\_______________/--------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131019/ee04913a/attachment.html>

From ghang.naoc at gmail.com  Sat Oct 19 11:35:26 2013
From: ghang.naoc at gmail.com (gonghang.naoc)
Date: Sat, 19 Oct 2013 23:35:26 +0800
Subject: [AstroPy] how to detect emission lines in sloan spectrum?
Message-ID: <CABb23ms68B+untW8ZMit3f2HU8oqUp8sFauwfgk8ydiscbanYQ@mail.gmail.com>

hi,

Is there any handy module to detect emission lines in a spectrum like one
we get from sdss?The spectra of sloan are fits files and the wavelength
calibration has been done.Suppose the redshift is smaller than 300km/s

Case A:
We have a spectral line list.We just want to know whether there are some
kinds of  emission lines in the fits files.

Case B:
We do not have a line list.We just want to detect emission lines.

Thank you.
hang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131019/6bb5ce34/attachment.html>

From rays at blue-cove.com  Sat Oct 19 22:26:49 2013
From: rays at blue-cove.com (RayS)
Date: Sat, 19 Oct 2013 19:26:49 -0700
Subject: [AstroPy] iraf's imexamine equivalent in python
In-Reply-To: <CAJ_T+b6Ro-C5FNsbXEFH0Dp6uX5N0XSXaVZCj1uyfAD+KMpa2w@mail.g
	mail.com>
References: <CAJ_T+b6Ro-C5FNsbXEFH0Dp6uX5N0XSXaVZCj1uyfAD+KMpa2w@mail.gmail.com>
Message-ID: <201310200226.r9K2Qoqx014785@blue-cove.com>

At 01:56 PM 10/18/2013, Joe Philip Ninan wrote:

>6)use matplotlib to plot those results.
>
>I am not much happy with using matplotlib's imshow to display fits images.
>Is there any other display (like ds9) which provides MouseEvents ?

I normally develop with wxPython, which is fully event driven - I 
write a lot of interactive spectrograms etc.

>The 3d surface plots in matplotlib, i have found to be very slow 
>when the matrix is very large.
>Even imshow is not very fast for large fits images.

3D plots in MPL are horribly slow for 1kx2k waterfalls or 
spectrograms. I switched to openGL / Mayavi (mine is from Enthought).
http://docs.enthought.com/mayavi/mayavi/building_applications.html
I have an above derived 3D spectrogram example online: 
http://rjs.org/Python/mayavi_test.zip
The initial render is slow with a full array of 2048x785 and hogs 
500MB ram, but once the vertexes etc are in the GPU manipulation is instant.
There is a bug with VTK you need to mod in the install
https://github.com/enthought/mayavi/issues/52
I'd love to see others' Mayavi 3D code...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131019/5a468586/attachment.html>

From ghang.naoc at gmail.com  Sun Oct 20 12:03:19 2013
From: ghang.naoc at gmail.com (gonghang.naoc)
Date: Mon, 21 Oct 2013 00:03:19 +0800
Subject: [AstroPy] how to detect emission lines in sloan spectrum?
In-Reply-To: <CAEUX0XepKR9kPNz6McOo-uAzWJkQtNRi2o0htJRLiq4rsVLLEg@mail.gmail.com>
References: <CABb23ms68B+untW8ZMit3f2HU8oqUp8sFauwfgk8ydiscbanYQ@mail.gmail.com>
	<CAEUX0XepKR9kPNz6McOo-uAzWJkQtNRi2o0htJRLiq4rsVLLEg@mail.gmail.com>
Message-ID: <CABb23msav4s6b3BrmH29OL4jOYKRiFxCZ5oLw2gr1HPnXUgjqw@mail.gmail.com>

Hi Kevin,
So it is just like a local minimum or local maximum thing?Then we can write
our own code and we can define an amplitude or a sigma value,right?
My python version is 2.7.I can import scipy.signal successfully but  the
'module' object has no attribute 'argrelmax'. Do you have any idea?

Thank you.
hang




On Sun, Oct 20, 2013 at 1:44 AM, Kevin Gullikson
<kevin.gullikson at gmail.com>wrote:

> Scipy.signal has a function for finding extrema. I have used it
> successfully for finding absorption lines; I assume it also works for
> emission lines:
>
>
> http://docs.scipy.org/doc/scipy/reference/generated/scipy.signal.argrelmax.html#scipy.signal.argrelma<http://docs.scipy.org/doc/scipy/reference/generated/scipy.signal.argrelmax.html#scipy.signal.argrelmax>
>
>
> Kevin Gullikson
>
>
> On Sat, Oct 19, 2013 at 10:35 AM, gonghang.naoc <ghang.naoc at gmail.com>wrote:
>
>> hi,
>>
>> Is there any handy module to detect emission lines in a spectrum like one
>> we get from sdss?The spectra of sloan are fits files and the wavelength
>> calibration has been done.Suppose the redshift is smaller than 300km/s
>>
>> Case A:
>> We have a spectral line list.We just want to know whether there are some
>> kinds of  emission lines in the fits files.
>>
>> Case B:
>> We do not have a line list.We just want to detect emission lines.
>>
>> Thank you.
>> hang
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131021/5fd166e2/attachment.html>

From demitri.muna at gmail.com  Sun Oct 20 13:29:43 2013
From: demitri.muna at gmail.com (Demitri Muna)
Date: Sun, 20 Oct 2013 13:29:43 -0400
Subject: [AstroPy] how to detect emission lines in sloan spectrum?
In-Reply-To: <CABb23ms68B+untW8ZMit3f2HU8oqUp8sFauwfgk8ydiscbanYQ@mail.gmail.com>
References: <CABb23ms68B+untW8ZMit3f2HU8oqUp8sFauwfgk8ydiscbanYQ@mail.gmail.com>
Message-ID: <BFA826F9-FD78-44FE-BD20-08487C8AFFCD@gmail.com>

Hi,

This doesn't answer everything you are looking for, but take a look at the "spectrumLines" query that's part of the SDSS API.

http://api.sdss3.org/api_spectrum_lines.html

Cheers,
Demitri

---

On Oct 19, 2013, at 11:35 AM, gonghang.naoc <ghang.naoc at gmail.com> wrote:

> hi,
> 
> Is there any handy module to detect emission lines in a spectrum like one we get from sdss?The spectra of sloan are fits files and the wavelength calibration has been done.Suppose the redshift is smaller than 300km/s
> 
> Case A:
> We have a spectral line list.We just want to know whether there are some kinds of  emission lines in the fits files.
> 
> Case B:
> We do not have a line list.We just want to detect emission lines.
> 
> Thank you.
> hang


_________________________________________
Demitri Muna

Department of Astronomy
Der Ohio State University

http://scicoder.org/





From maik.riechert at arcor.de  Mon Oct 21 09:45:27 2013
From: maik.riechert at arcor.de (Maik Riechert)
Date: Mon, 21 Oct 2013 15:45:27 +0200
Subject: [AstroPy] Running wcs_pix2world for all image pixels
In-Reply-To: <CAALafn6tNYm11xBB00Qe6BuVopKxFdhL5FJW_fEb5BP_EibshA@mail.gmail.com>
References: <525E8B17.4080206@arcor.de>	<CAGMHX_0vZvgn1rsn2X+AVOh84v8yXunBbpAzoA5Mq5SNrnB57Q@mail.gmail.com>	<525E9B77.9020105@arcor.de>	<CAGMHX_0aE6zjjq68YdkWYX2Cnnjw-hpOHEusT8wCoeYB22dZzw@mail.gmail.com>	<CAALafn6Njodzr4U8nZ9MRtNTp64dOV576c3sYBvSiaK+CLAtgg@mail.gmail.com>	<525FC9FB.3080906@arcor.de>	<CAALafn4LfD8hXOG9cHO4C1FHOz0aH7=PhZ7JPskuR43ek6MeHg@mail.gmail.com>	<525FF421.40105@arcor.de>	<CAALafn5C22T+oawtqy12_8GLpOWwmsSN5A3KWE7aKA3ofQE1eQ@mail.gmail.com>	<5260022D.5040902@arcor.de>	<CAALafn6vJPSJncnD3MtAH7246AO_uJc=nEFX_uNSYJPbbRAK-Q@mail.gmail.com>
	<CAALafn6tNYm11xBB00Qe6BuVopKxFdhL5FJW_fEb5BP_EibshA@mail.gmail.com>
Message-ID: <52652FF7.1070601@arcor.de>


On 18/10/13 14:48, David Berry wrote:
>
> On 18 October 2013 09:54, David Berry <d.berry at jach.hawaii.edu 
> <mailto:d.berry at jach.hawaii.edu>> wrote:
>
>
>     Now regarding the inverse transformation back from (ra,dec) to
>     (x,y). [...] If the distortion is included, AST gives:
>
>     x = -205.93, 735, 4179.93
>     y = -499.37, 459, 2246.86
>
>     WCSTools gives exactly the same values. This poor performance of
>     AST and WCSTools when including the distortion indicates that the
>     coefficients of the inverse polynomial included in the header (the
>     "AP_" and "BP_" headers) are inaccurate.  But AST has a facility
>     to handle SIP headers that do not include an inverse polynomial.
>     In such cases, AST creates an inverse itself by numerical
>     inversion of the supplied forward polynomial. So if I remove the
>     "AP_" and "BP_" keywords from the header, and again transform the
>     (ra,dec) values back into (x,y) AST now gives:
>
>     x = -197.19, 735, 4061.94
>     y = -502.92, 459, 2324.94
>
>     which are much better but still not good. AST includes two
>     alternative schemes for implementing a missing SIP inverse:
>
>     1) it samples the forward transformation at a regular grid of
>     pixel positions and fits a polynomial surface to the results. This
>     fit is performed once, and if the residuals of the fit are
>     sufficiently small, it is then used to transform all subsequent
>     points.
>
>     2) if the residuals of the above fit are too large, then each
>     individual (ra,dec) position is transformed using an iterative
>     Newton-Raphson method. This is much slower over-all than 1) but
>     more accurate.
>
>     There is a problem in AST in that it is using option 1) above for
>     your header, when in fact it needs to use 2) to get sufficient
>     accuracy.  The recovered (x,y) values quoted above were created
>     using option 1). With option 2), the exact original (x,y) values
>     are recovered to within 0.01 pixel.
>
>     I shall investigate this issue in AST. Thanks for the input.
>
>
> In case you are interested, I've modified AST (v7.3.3) and pyast 
> (v2.5) to fix this.
>
> Since I have come across several SIP headers that contain badly 
> inaccurate values for the inverse polynomial, I've followed astropy's 
> lead and changed AST so that it *always* calculates it's own inverse, 
> ignoring any inverse in the header.

Just a final remark. Having changed the origin to 1 for astropy I could 
produce consistent RA,Dec results from astropy (with SIP), starlink, and 
esutil. For starlink, the reverse direction is consistent now too, with 
the new version. A quick measurement yielded 3.6s for AstroPy, 3.8s for 
starlink (not using approximations), and 6.3s for esutil.

Thanks again for your support, it helped a lot!
Maik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131021/2980e371/attachment.html>

From indiajoe at gmail.com  Mon Oct 21 11:13:35 2013
From: indiajoe at gmail.com (Joe Philip Ninan)
Date: Mon, 21 Oct 2013 20:43:35 +0530
Subject: [AstroPy] iraf's imexamine equivalent in python
In-Reply-To: <201310200226.r9K2Qoqx014785@blue-cove.com>
References: <CAJ_T+b6Ro-C5FNsbXEFH0Dp6uX5N0XSXaVZCj1uyfAD+KMpa2w@mail.gmail.com>
	<201310200226.r9K2Qoqx014785@blue-cove.com>
Message-ID: <CAJ_T+b4p4wNn5W1ZD44=TG20uaxj=JJ2aiaZRTt6_O7YiKKKjA@mail.gmail.com>

Hi RayS,
Thanks for the suggestions.
I was so far trying to get ginga work from Ipython. (still stuck at some
error in PyQt4...)
I have never tried doing anything in wxPython before. But looks like I
should give a try on that also.
For 3d surface plot, I shall use Mayavi.
Thanking you,
-cheers
joe


On 20 October 2013 07:56, RayS <rays at blue-cove.com> wrote:

>  At 01:56 PM 10/18/2013, Joe Philip Ninan wrote:
>
> 6)use matplotlib to plot those results.
>
> I am not much happy with using matplotlib's imshow to display fits images.
> Is there any other display (like ds9) which provides MouseEvents ?
>
>
> I normally develop with wxPython, which is fully event driven - I write a
> lot of interactive spectrograms etc.
>
> The 3d surface plots in matplotlib, i have found to be very slow when the
> matrix is very large.
> Even imshow is not very fast for large fits images.
>
>
> 3D plots in MPL are horribly slow for 1kx2k waterfalls or spectrograms. I
> switched to openGL / Mayavi (mine is from Enthought).
>  http://docs.enthought.com/mayavi/mayavi/building_applications.html
> I have an above derived 3D spectrogram example online:
> http://rjs.org/Python/mayavi_test.zip
> The initial render is slow with a full array of 2048x785 and hogs 500MB
> ram, but once the vertexes etc are in the GPU manipulation is instant.
> There is a bug with VTK you need to mod in the install
>  https://github.com/enthought/mayavi/issues/52
> I'd love to see others' Mayavi 3D code...
>



-- 
/---------------------------------------------------------------
"GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation

************************************************
Joe Philip Ninan    http://sites.google.com/site/jpninan/
Research Scholar        /________________\
DAA,                            | Vadakeparambil |
TIFR,                           | Pullad P.O.         |
Mumbai-05, India.      | Kerala, India      |
Ph: +917738438212   | PIN:689548       |
------------------------------\_______________/--------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131021/a64f859b/attachment.html>

From lsinger at caltech.edu  Tue Oct 22 01:34:24 2013
From: lsinger at caltech.edu (Leo Singer)
Date: Mon, 21 Oct 2013 22:34:24 -0700
Subject: [AstroPy] How do you create a dimensionless Cartesian coordinate?
Message-ID: <57856994-A51E-47F7-977D-52A6C6E564C5@caltech.edu>

Hello,

How do you create a dimensionless Cartesian coordinate? If I try the obvious way, by passing pure numbers to the constructor, I get the following exception:

$ python -c "import astropy.coordinates; astropy.coordinates.CartesianPoints(1, 0, 0)"
ERROR: UnitsError: None is not a valid Unit [astropy.coordinates.distances]
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/.../local/lib/python2.7/site-packages/astropy/coordinates/distances.py", line 279, in __new__
    raise u.UnitsError(str(e))
astropy.units.core.UnitsError: None is not a valid Unit

This is using the latest build from master, by the way.

Thank you,
Leo Singer
Graduate Student @ LIGO-Caltech


From erik.tollerud at gmail.com  Wed Oct 23 13:37:17 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 23 Oct 2013 13:37:17 -0400
Subject: [AstroPy] astropy fashion update
In-Reply-To: <5FBD727F-6236-4ACE-B877-493D131707C4@gmail.com>
References: <52498931.9090307@postgrad.manchester.ac.uk>
	<5FBD727F-6236-4ACE-B877-493D131707C4@gmail.com>
Message-ID: <CAARXUwUpBer4oKPCOrmnwsoRm-3ud1kUMtza8_fC7mcveTcZng@mail.gmail.com>

I think the company behind the fashion.astropy.org site doesn't do
mugs, anyway... But I presume we don't mind someone using the custom
designer at http://www.cafepress.com/ in conjunction with the logos
from https://github.com/astropy/astropy-logo to make a mug. If the
logo becomes valuable enough that we need to start licensing rights,
we'll worry about it then :)

On Mon, Sep 30, 2013 at 10:50 AM, Perry Greenfield
<stsci.perry at gmail.com> wrote:
> We've looked as stickers a bit, but not mugs. I think we'll want to see the level of interest in the clothing before expanding our retail project :-)
>
> On Sep 30, 2013, at 10:22 AM, Leo Huckvale wrote:
>
>> Regarding suggestions for astropy merchandise, have you thought of
>> coffee mugs?
>>
>> Regards,
>> Leo Huckvale
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



-- 
Erik


From demitri.muna at gmail.com  Wed Oct 23 13:38:56 2013
From: demitri.muna at gmail.com (Demitri Muna)
Date: Wed, 23 Oct 2013 13:38:56 -0400
Subject: [AstroPy] astropy fashion update
In-Reply-To: <CAARXUwUpBer4oKPCOrmnwsoRm-3ud1kUMtza8_fC7mcveTcZng@mail.gmail.com>
References: <52498931.9090307@postgrad.manchester.ac.uk>
	<5FBD727F-6236-4ACE-B877-493D131707C4@gmail.com>
	<CAARXUwUpBer4oKPCOrmnwsoRm-3ud1kUMtza8_fC7mcveTcZng@mail.gmail.com>
Message-ID: <E7C0B049-76D7-4329-BE1F-D8386131E546@gmail.com>


On Oct 23, 2013, at 1:37 PM, Erik Tollerud <erik.tollerud at gmail.com> wrote:

> I think the company behind the fashion.astropy.org site doesn't do
> mugs, anyway... But I presume we don't mind someone using the custom
> designer at http://www.cafepress.com/ in conjunction with the logos
> from https://github.com/astropy/astropy-logo to make a mug. If the
> logo becomes valuable enough that we need to start licensing rights,
> we'll worry about it then :)

I will offer you $175,000 for your logo.

_________________________________________
Demitri Muna

Department of Astronomy
Ohio State University

http://scicoder.org/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131023/52822442/attachment.html>

From erik.tollerud at gmail.com  Wed Oct 23 13:59:39 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 23 Oct 2013 13:59:39 -0400
Subject: [AstroPy] How do you create a dimensionless Cartesian
	coordinate?
In-Reply-To: <57856994-A51E-47F7-977D-52A6C6E564C5@caltech.edu>
References: <57856994-A51E-47F7-977D-52A6C6E564C5@caltech.edu>
Message-ID: <CAARXUwXdW2g_+rzNoZAFvTgDReL7Fv359DXtRWgUR0g+UVzwxQ@mail.gmail.com>

You probably want this:

from astropy import units as u
from astropy.coordinates import CartesianPoints
cp = CartesianPoints(1, 0, 0, u.dimensionless_unscaled)

`dimensionless_unscaled` is an ordinary unit (with a string
representation of just '', the empty string), so you just pass that in
to indicate the units are supposed to be dimensionless. The reason
this is necessary is that the default argument to `unit` is None, and
None means "no unit given", rather than "dimensionless".




On Tue, Oct 22, 2013 at 1:34 AM, Leo Singer <lsinger at caltech.edu> wrote:
> Hello,
>
> How do you create a dimensionless Cartesian coordinate? If I try the obvious way, by passing pure numbers to the constructor, I get the following exception:
>
> $ python -c "import astropy.coordinates; astropy.coordinates.CartesianPoints(1, 0, 0)"
> ERROR: UnitsError: None is not a valid Unit [astropy.coordinates.distances]
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "/Users/.../local/lib/python2.7/site-packages/astropy/coordinates/distances.py", line 279, in __new__
>     raise u.UnitsError(str(e))
> astropy.units.core.UnitsError: None is not a valid Unit
>
> This is using the latest build from master, by the way.
>
> Thank you,
> Leo Singer
> Graduate Student @ LIGO-Caltech
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



-- 
Erik


From lsinger at caltech.edu  Wed Oct 23 14:03:48 2013
From: lsinger at caltech.edu (Leo Singer)
Date: Wed, 23 Oct 2013 11:03:48 -0700
Subject: [AstroPy] How do you create a dimensionless Cartesian
	coordinate?
In-Reply-To: <CAARXUwXdW2g_+rzNoZAFvTgDReL7Fv359DXtRWgUR0g+UVzwxQ@mail.gmail.com>
References: <57856994-A51E-47F7-977D-52A6C6E564C5@caltech.edu>
	<CAARXUwXdW2g_+rzNoZAFvTgDReL7Fv359DXtRWgUR0g+UVzwxQ@mail.gmail.com>
Message-ID: <0F5BF01B-1012-41E5-8B3F-F35B09A6843D@caltech.edu>

H Erik,

I found that:

astropy.coordinates.ICRSCoordinates(x=1, y=0, z=0)

also worked.

Leo

On Oct 23, 2013, at 10:59 AM, Erik Tollerud <erik.tollerud at gmail.com> wrote:

> You probably want this:
> 
> from astropy import units as u
> from astropy.coordinates import CartesianPoints
> cp = CartesianPoints(1, 0, 0, u.dimensionless_unscaled)
> 
> `dimensionless_unscaled` is an ordinary unit (with a string
> representation of just '', the empty string), so you just pass that in
> to indicate the units are supposed to be dimensionless. The reason
> this is necessary is that the default argument to `unit` is None, and
> None means "no unit given", rather than "dimensionless".
> 
> 
> 
> 
> On Tue, Oct 22, 2013 at 1:34 AM, Leo Singer <lsinger at caltech.edu> wrote:
>> Hello,
>> 
>> How do you create a dimensionless Cartesian coordinate? If I try the obvious way, by passing pure numbers to the constructor, I get the following exception:
>> 
>> $ python -c "import astropy.coordinates; astropy.coordinates.CartesianPoints(1, 0, 0)"
>> ERROR: UnitsError: None is not a valid Unit [astropy.coordinates.distances]
>> Traceback (most recent call last):
>>  File "<string>", line 1, in <module>
>>  File "/Users/.../local/lib/python2.7/site-packages/astropy/coordinates/distances.py", line 279, in __new__
>>    raise u.UnitsError(str(e))
>> astropy.units.core.UnitsError: None is not a valid Unit
>> 
>> This is using the latest build from master, by the way.
>> 
>> Thank you,
>> Leo Singer
>> Graduate Student @ LIGO-Caltech
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
> 
> 
> 
> -- 
> Erik



From demitri.muna at gmail.com  Wed Oct 23 14:03:45 2013
From: demitri.muna at gmail.com (Demitri Muna)
Date: Wed, 23 Oct 2013 14:03:45 -0400
Subject: [AstroPy] How do you create a dimensionless Cartesian
	coordinate?
In-Reply-To: <CAARXUwXdW2g_+rzNoZAFvTgDReL7Fv359DXtRWgUR0g+UVzwxQ@mail.gmail.com>
References: <57856994-A51E-47F7-977D-52A6C6E564C5@caltech.edu>
	<CAARXUwXdW2g_+rzNoZAFvTgDReL7Fv359DXtRWgUR0g+UVzwxQ@mail.gmail.com>
Message-ID: <1E0B087A-819D-4482-89F2-0BA78FA83CAB@gmail.com>


On Oct 23, 2013, at 1:59 PM, Erik Tollerud <erik.tollerud at gmail.com> wrote:

> The reason
> this is necessary is that the default argument to `unit` is None, and
> None means "no unit given", rather than "dimensionless".


I?ve been thinking about this. Is there a difference here? I kind of want do to do:

Something(value, unit=None)

to mean it?s dimensionless.

_________________________________________
Demitri Muna

Department of Astronomy
Il Ohio State University

http://scicoder.org/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131023/7e78336b/attachment.html>

From mdroe at stsci.edu  Thu Oct 24 12:25:54 2013
From: mdroe at stsci.edu (Michael Droettboom)
Date: Thu, 24 Oct 2013 12:25:54 -0400
Subject: [AstroPy] How do you create a dimensionless Cartesian
	coordinate?
In-Reply-To: <1E0B087A-819D-4482-89F2-0BA78FA83CAB@gmail.com>
References: <57856994-A51E-47F7-977D-52A6C6E564C5@caltech.edu>	<CAARXUwXdW2g_+rzNoZAFvTgDReL7Fv359DXtRWgUR0g+UVzwxQ@mail.gmail.com>
	<1E0B087A-819D-4482-89F2-0BA78FA83CAB@gmail.com>
Message-ID: <52694A12.7080301@stsci.edu>

On 10/23/2013 02:03 PM, Demitri Muna wrote:
>
> On Oct 23, 2013, at 1:59 PM, Erik Tollerud <erik.tollerud at gmail.com 
> <mailto:erik.tollerud at gmail.com>> wrote:
>
>> The reason
>> this is necessary is that the default argument to `unit` is None, and
>> None means "no unit given", rather than "dimensionless".
>
> I've been thinking about this. Is there a difference here? I kind of 
> want do to do:
>
> Something(value, unit=None)
>
> to mean it's dimensionless.
>

This was determined early on in the development of astropy.units that we 
need a way to distinguish between "no unit was defined", and "the unit 
is dimensionless".  "None" indicates no unit is assigned to the value.  
This is helpful, for example, for tools that read from files where units 
may be missing when they should be specified.

See this:

http://docs.astropy.org/en/latest/units/standard_units.html#the-dimensionless-unit

Mike

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131024/49c7eae2/attachment.html>

From indiajoe at gmail.com  Thu Oct 24 16:54:38 2013
From: indiajoe at gmail.com (Joe Philip Ninan)
Date: Fri, 25 Oct 2013 02:24:38 +0530
Subject: [AstroPy] Selecting data from ascii.table with multiple conditions
Message-ID: <CAJ_T+b79FK5B=GHoZuM4Lut=1kXjdyT8qnmvh3jmCTY+X9hQKw@mail.gmail.com>

Hi,
I wanted to pick out certain data from an ascii table based on conditions
on other columns, i was using the following way.

For example, Mytable is an ascii.table loaded from Daophot output file.
To extract the MAG of stars with ID > 60 and MAG>18,
Following is the command which works, i had to come up with.

Mytable[np.where((Mytable['ID']>60).data &
(Mytable['MAG']>18).data)]['MAG'].data.data

Quite a lot of ".data" to be appended !!
Am i missing some feature astropy already has for doing these kind of data
selection from table?

I didn't find any example for these kind of usage in the doc
http://docs.astropy.org/en/latest/io/ascii/index.html
May be we should add one.

Thanks,
-cheers
joe


-- 
/---------------------------------------------------------------
"GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation

************************************************
Joe Philip Ninan    http://sites.google.com/site/jpninan/
Research Scholar        /________________\
DAA,                            | Vadakeparambil |
TIFR,                           | Pullad P.O.         |
Mumbai-05, India.      | Kerala, India      |
Ph: +917738438212   | PIN:689548       |
------------------------------\_______________/--------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131025/dae0f7a0/attachment.html>

From demitri.muna at gmail.com  Thu Oct 24 20:26:39 2013
From: demitri.muna at gmail.com (Demitri Muna)
Date: Thu, 24 Oct 2013 20:26:39 -0400
Subject: [AstroPy] Dimensionless units
In-Reply-To: <52694A12.7080301@stsci.edu>
References: <57856994-A51E-47F7-977D-52A6C6E564C5@caltech.edu>	<CAARXUwXdW2g_+rzNoZAFvTgDReL7Fv359DXtRWgUR0g+UVzwxQ@mail.gmail.com>
	<1E0B087A-819D-4482-89F2-0BA78FA83CAB@gmail.com>
	<52694A12.7080301@stsci.edu>
Message-ID: <2B9C8969-3C30-4A27-875A-BF5759404D20@gmail.com>


On 24 Oct 2013, at 12:25 PM, Michael Droettboom <mdroe at stsci.edu> wrote:

> This was determined early on in the development of astropy.units that we need a way to distinguish between "no unit was defined", and "the unit is dimensionless".  "None" indicates no unit is assigned to the value.  This is helpful, for example, for tools that read from files where units may be missing when they should be specified.
> 
> See this:
> 
> http://docs.astropy.org/en/latest/units/standard_units.html#the-dimensionless-unit


I can't really argue with that. Looking at the link above though, two thoughts occur to me.

First, this doesn't seem consistent:

>>> from astropy import units as u
>>> u.dimensionless_unscaled
Unit(dimensionless)
It seems to me that dealing with the "scaled-ness" is not the common case, and that is a very long constant name. I'd propose that the constant be "u.dimensionless" - the same thing that the __repr__ is displaying, and that if one wants to indicate that it's scaled, that the constant be "u.dimensionless_scaled". I just think the latter is much less frequently used. This won't break things as we can just deprecate "u.dimensionless_unscaled" but have it equal to "u.dimensionless".

Second, I really don't like `Unit(1)` to mean dimensionless. It's not intuitive at all that that is the meaning. I'd like to deprecate that form. The docs specifically say the other form is recommended for readability - I'd like to have that enforced as I fear many people will use the unintuitive form.

Cheers,
Demitri

_________________________________________
Demitri Muna

Department of Astronomy
Il Ohio State University

http://scicoder.org/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131024/c76a8a12/attachment.html>

From aldcroft at head.cfa.harvard.edu  Thu Oct 24 22:32:09 2013
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Thu, 24 Oct 2013 22:32:09 -0400
Subject: [AstroPy] Selecting data from ascii.table with multiple
	conditions
In-Reply-To: <CAJ_T+b79FK5B=GHoZuM4Lut=1kXjdyT8qnmvh3jmCTY+X9hQKw@mail.gmail.com>
References: <CAJ_T+b79FK5B=GHoZuM4Lut=1kXjdyT8qnmvh3jmCTY+X9hQKw@mail.gmail.com>
Message-ID: <CAMtEP6wHbrp3ogYEi0ZotDHAyWa=KzTKqR_HxXAZcgga3V1E+g@mail.gmail.com>

On Thu, Oct 24, 2013 at 4:54 PM, Joe Philip Ninan <indiajoe at gmail.com>wrote:

> Hi,
> I wanted to pick out certain data from an ascii table based on conditions
> on other columns, i was using the following way.
>
> For example, Mytable is an ascii.table loaded from Daophot output file.
> To extract the MAG of stars with ID > 60 and MAG>18,
> Following is the command which works, i had to come up with.
>
> Mytable[np.where((Mytable['ID']>60).data &
> (Mytable['MAG']>18).data)]['MAG'].data.data
>
> Quite a lot of ".data" to be appended !!
> Am i missing some feature astropy already has for doing these kind of data
> selection from table?
>

Here's an example showing a more concise way to do this using boolean
masks.  In general you should not ever be using the .data attribute of
Columns.

In [2]: from astropy.table import Table
In [3]: import numpy as np
In [4]: t = Table([np.arange(10), np.arange(10)], names=('a', 'b'))
In [5]: mask = (t['a'] > 4) & (t['b'] < 8)
In [6]: t2 = t[mask]
In [7]: print t2
 a   b
--- ---
  5   5
  6   6
  7   7

Cheers,
Tom


>
> I didn't find any example for these kind of usage in the doc
> http://docs.astropy.org/en/latest/io/ascii/index.html
> May be we should add one.
>
> Thanks,
> -cheers
> joe
>
>
> --
> /---------------------------------------------------------------
> "GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation
>
> ************************************************
> Joe Philip Ninan    http://sites.google.com/site/jpninan/
> Research Scholar        /________________\
> DAA,                            | Vadakeparambil |
> TIFR,                           | Pullad P.O.         |
> Mumbai-05, India.      | Kerala, India      |
> Ph: +917738438212   | PIN:689548       |
> ------------------------------\_______________/--------------
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131024/97b371b8/attachment.html>

From semyeong.oh at gmail.com  Thu Oct 24 23:34:51 2013
From: semyeong.oh at gmail.com (Semyeong Oh)
Date: Thu, 24 Oct 2013 23:34:51 -0400
Subject: [AstroPy] reading table from string
Message-ID: <CAG-7A+6HS4e5LTO1PU4Pq1cfYnNJ_U=vYcsYC7_D9fPTbHYahQ@mail.gmail.com>

Hi,

If I use 'names' keyword when reading a table from string,
the first line is ignored.

new="""
3102  0.32      4167  4085   Q1250+568-A
877   0.22      4378  3892   "Source 82"
"""
t = ascii.read(new, names=['obsid','redshift','X','Y','object'])
print t


obsid redshift  X    Y     object
----- -------- ---- ---- ---------
  877     0.22 4378 3892 Source 82


Is this a bug?

Thanks,
Semyeong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131024/3fcbd1d3/attachment.html>

From yannick.roehlly at oamp.fr  Fri Oct 25 01:55:38 2013
From: yannick.roehlly at oamp.fr (Yannick Roehlly)
Date: Fri, 25 Oct 2013 07:55:38 +0200
Subject: [AstroPy] Selecting data from ascii.table with multiple
 conditions
In-Reply-To: <CAJ_T+b79FK5B=GHoZuM4Lut=1kXjdyT8qnmvh3jmCTY+X9hQKw@mail.gmail.com>
References: <CAJ_T+b79FK5B=GHoZuM4Lut=1kXjdyT8qnmvh3jmCTY+X9hQKw@mail.gmail.com>
Message-ID: <20131025075538.28ead1b7@oamp.fr>

Le Fri, 25 Oct 2013 02:24:38 +0530,
Joe Philip Ninan <indiajoe at gmail.com> a ?crit :

> Mytable[np.where((Mytable['ID']>60).data &
> (Mytable['MAG']>18).data)]['MAG'].data.data  
> 
> Quite a lot of ".data" to be appended !!
> Am i missing some feature astropy already has for doing these kind of
> data selection from table?

Hi Joe,

How do you read your table ? 

Mytable[(Mytable['ID']>60) & (Mytable['MAG']>18)] should do what you
want.

Cheers,

Yannick

-- 
You will never amount to much.
		-- Munich Schoolmaster, to Albert Einstein, age 10


From indiajoe at gmail.com  Fri Oct 25 05:27:38 2013
From: indiajoe at gmail.com (Joe Philip Ninan)
Date: Fri, 25 Oct 2013 14:57:38 +0530
Subject: [AstroPy] Selecting data from ascii.table with multiple
	conditions
In-Reply-To: <20131025075538.28ead1b7@oamp.fr>
References: <CAJ_T+b79FK5B=GHoZuM4Lut=1kXjdyT8qnmvh3jmCTY+X9hQKw@mail.gmail.com>
	<20131025075538.28ead1b7@oamp.fr>
Message-ID: <CAJ_T+b60R=AZJ_EWHgYsQRVGNFTSghvfwGpL0mh6CCZj_WkLdQ@mail.gmail.com>

Hi Yannick, Tom and Jeonghyun,
Thanks for the examples. They all worked.
I loaded the data with ascii.read() tool.
What confused me was Mytable['ID']>60  returned an object which contains a
boolean data array and another mask array.
Which is why i thought, i had to add .data before taking logical &, to make
sure data array is used.

Am I correct in assuming that this object which returned will basically
work like a standard numpy masked array? It will all make sense that way.
Thanks,
-cheers
joe



On 25 October 2013 11:25, Yannick Roehlly <yannick.roehlly at oamp.fr> wrote:

> Le Fri, 25 Oct 2013 02:24:38 +0530,
> Joe Philip Ninan <indiajoe at gmail.com> a ?crit :
>
> > Mytable[np.where((Mytable['ID']>60).data &
> > (Mytable['MAG']>18).data)]['MAG'].data.data
> >
> > Quite a lot of ".data" to be appended !!
> > Am i missing some feature astropy already has for doing these kind of
> > data selection from table?
>
> Hi Joe,
>
> How do you read your table ?
>
> Mytable[(Mytable['ID']>60) & (Mytable['MAG']>18)] should do what you
> want.
>
> Cheers,
>
> Yannick
>
> --
> You will never amount to much.
>                 -- Munich Schoolmaster, to Albert Einstein, age 10
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
/---------------------------------------------------------------
"GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation

************************************************
Joe Philip Ninan    http://sites.google.com/site/jpninan/
Research Scholar        /________________\
DAA,                            | Vadakeparambil |
TIFR,                           | Pullad P.O.         |
Mumbai-05, India.      | Kerala, India      |
Ph: +917738438212   | PIN:689548       |
------------------------------\_______________/--------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131025/f26ba862/attachment.html>

From stsci.perry at gmail.com  Fri Oct 25 08:09:34 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Fri, 25 Oct 2013 08:09:34 -0400
Subject: [AstroPy] Helping guide development of spectral reduction and
	analysis tools in astropy
References: <6788A02107EA644693721D7DEF3F408B473480D2@EXCHMAIL1.stsci.edu>
Message-ID: <B8DB03CE-611E-4FE0-B537-AEEA1F4C48BD@gmail.com>


Greetings,

At the last Astropy Coordination meeting at Yale, the group discussed what the priorities should be for spectral reduction and analysis tools in the upcoming year, and beyond. STScI will have resources to work on this, and there are a number of others interested in contributing to such work. It was agreed that there should be an effort to coordinate such efforts. This is the start of that.

First, we would like to get input for what the greatest needs are to help determine the development priorities for such work. If you are interested in helping guide that work, please visit the following astropy wiki page to see what kind of information we are seeking.

https://github.com/astropy/astropy/wiki/SpectralAnalysisRoadmap

As information is collected, the results will be summarized on the wiki. Based upon these results, a roadmap will be developed outlining the development priorities of STScI, and suggested priorities for other developers. Once determined, STScI will then start implementing its part of the roadmap.

If you have further questions or issues, please use the email address astropy.spectra at gmail.com

Thank you for your time,

Perry Greenfield



From aldcroft at head.cfa.harvard.edu  Fri Oct 25 09:08:39 2013
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Fri, 25 Oct 2013 09:08:39 -0400
Subject: [AstroPy] Selecting data from ascii.table with multiple
	conditions
In-Reply-To: <CAJ_T+b60R=AZJ_EWHgYsQRVGNFTSghvfwGpL0mh6CCZj_WkLdQ@mail.gmail.com>
References: <CAJ_T+b79FK5B=GHoZuM4Lut=1kXjdyT8qnmvh3jmCTY+X9hQKw@mail.gmail.com>
	<20131025075538.28ead1b7@oamp.fr>
	<CAJ_T+b60R=AZJ_EWHgYsQRVGNFTSghvfwGpL0mh6CCZj_WkLdQ@mail.gmail.com>
Message-ID: <CAMtEP6znf77C38w3vqSRBH0RWGH5SrAgnUOfXKw+iNLkJqtxQg@mail.gmail.com>

On Fri, Oct 25, 2013 at 5:27 AM, Joe Philip Ninan <indiajoe at gmail.com>wrote:

> Hi Yannick, Tom and Jeonghyun,
> Thanks for the examples. They all worked.
> I loaded the data with ascii.read() tool.
> What confused me was Mytable['ID']>60  returned an object which contains a
> boolean data array and another mask array.
> Which is why i thought, i had to add .data before taking logical &, to
> make sure data array is used.
>
> Am I correct in assuming that this object which returned will basically
> work like a standard numpy masked array? It will all make sense that way.
>

Yes, that's correct.  The fact that you get a masked boolean array in this
case is a feature because it means if any elements in your MyTable['ID'])
are masked then the corresponding comparison truth values will be masked.
 I.e. if the input is not known then the comparison is likewise not known.

- Tom


> Thanks,
> -cheers
> joe
>
>
>
> On 25 October 2013 11:25, Yannick Roehlly <yannick.roehlly at oamp.fr> wrote:
>
>> Le Fri, 25 Oct 2013 02:24:38 +0530,
>> Joe Philip Ninan <indiajoe at gmail.com> a ?crit :
>>
>> > Mytable[np.where((Mytable['ID']>60).data &
>> > (Mytable['MAG']>18).data)]['MAG'].data.data
>> >
>> > Quite a lot of ".data" to be appended !!
>> > Am i missing some feature astropy already has for doing these kind of
>> > data selection from table?
>>
>> Hi Joe,
>>
>> How do you read your table ?
>>
>> Mytable[(Mytable['ID']>60) & (Mytable['MAG']>18)] should do what you
>> want.
>>
>> Cheers,
>>
>> Yannick
>>
>> --
>> You will never amount to much.
>>                 -- Munich Schoolmaster, to Albert Einstein, age 10
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>
>
>
> --
> /---------------------------------------------------------------
> "GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation
>
> ************************************************
> Joe Philip Ninan    http://sites.google.com/site/jpninan/
> Research Scholar        /________________\
> DAA,                            | Vadakeparambil |
> TIFR,                           | Pullad P.O.         |
> Mumbai-05, India.      | Kerala, India      |
> Ph: +917738438212   | PIN:689548       |
> ------------------------------\_______________/--------------
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131025/ecadd13d/attachment.html>

From sandily.r at gmail.com  Sun Oct 27 14:25:27 2013
From: sandily.r at gmail.com (Sandily Rivera)
Date: Sun, 27 Oct 2013 11:25:27 -0700
Subject: [AstroPy] Can't install aplpy
References: <BBEFA5E7-A261-44B0-BEBF-EAC451862136@gmail.com>
Message-ID: <E7B7F293-81E9-4300-831B-B7E43A3C12CD@gmail.com>


> 
> Hi, I'm trying to install the package APLpy but I can't, I have a Macbok pro with OS X 10.8.5.
> 
> This is what I typed:
> pip install --upgrade aplpy
> 
> and this is what I got:
> 
> 
> Downloading/unpacking aplpy
>  Downloading APLpy-0.9.9.tar.gz (689kB): 689kB downloaded
>  Running setup.py egg_info for package aplpy
>    Traceback (most recent call last):
>      File "<string>", line 16, in <module>
>      File "/private/var/folders/bf/jrt8km3d32n_l86k03wkv1l00000gn/T/pip_build_Sandily/aplpy/setup.py", line 31, in <module>
>        from astropy.setup_helpers import (register_commands, adjust_compiler,
>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/astropy/setup_helpers.py", line 46, in <module>
>        from sphinx.setup_command import BuildDoc as SphinxBuildDoc
>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/sphinx/setup_command.py", line 20, in <module>
>        from sphinx.application import Sphinx
>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/sphinx/application.py", line 21, in <module>
>        from docutils.parsers.rst import convert_directive_function, \
>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/parsers/rst/__init__.py", line 74, in <module>
>        import docutils.statemachine
>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/statemachine.py", line 113, in <module>
>        from docutils import utils
>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/utils/__init__.py", line 20, in <module>
>        import docutils.io
>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/io.py", line 18, in <module>
>        from docutils.utils.error_reporting import locale_encoding, ErrorString, ErrorOutput
>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/utils/error_reporting.py", line 47, in <module>
>        locale_encoding = locale.getlocale()[1] or locale.getdefaultlocale()[1]
>      File "/Users/NoeR/anaconda/lib/python2.7/locale.py", line 511, in getdefaultlocale
>        return _parse_localename(localename)
>      File "/Users/NoeR/anaconda/lib/python2.7/locale.py", line 443, in _parse_localename
>        raise ValueError, 'unknown locale: %s' % localename
>    ValueError: unknown locale: UTF-8
>    Complete output from command python setup.py egg_info:
>    Traceback (most recent call last):
> 
>  File "<string>", line 16, in <module>
> 
>  File "/private/var/folders/bf/jrt8km3d32n_l86k03wkv1l00000gn/T/pip_build_Sandily/aplpy/setup.py", line 31, in <module>
> 
>    from astropy.setup_helpers import (register_commands, adjust_compiler,
> 
>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/astropy/setup_helpers.py", line 46, in <module>
> 
>    from sphinx.setup_command import BuildDoc as SphinxBuildDoc
> 
>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/sphinx/setup_command.py", line 20, in <module>
> 
>    from sphinx.application import Sphinx
> 
>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/sphinx/application.py", line 21, in <module>
> 
>    from docutils.parsers.rst import convert_directive_function, \
> 
>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/parsers/rst/__init__.py", line 74, in <module>
> 
>    import docutils.statemachine
> 
>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/statemachine.py", line 113, in <module>
> 
>    from docutils import utils
> 
>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/utils/__init__.py", line 20, in <module>
> 
>    import docutils.io
> 
>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/io.py", line 18, in <module>
> 
>    from docutils.utils.error_reporting import locale_encoding, ErrorString, ErrorOutput
> 
>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/utils/error_reporting.py", line 47, in <module>
> 
>    locale_encoding = locale.getlocale()[1] or locale.getdefaultlocale()[1]
> 
>  File "/Users/NoeR/anaconda/lib/python2.7/locale.py", line 511, in getdefaultlocale
> 
>    return _parse_localename(localename)
> 
>  File "/Users/NoeR/anaconda/lib/python2.7/locale.py", line 443, in _parse_localename
> 
>    raise ValueError, 'unknown locale: %s' % localename
> 
> ValueError: unknown locale: UTF-8
> 
> ----------------------------------------
> Cleaning up...
> Command python setup.py egg_info failed with error code 1 in /private/var/folders/bf/jrt8km3d32n_l86k03wkv1l00000gn/T/pip_build_Sandily/aplpy
> Storing complete log in /Users/NoeR/.pip/pip.log
> 
> 
> I'm new at this so I don't know how to fix it, hope you can help me.
> 
> Thank you
> Sandily Rivera



From thomas.robitaille at gmail.com  Sun Oct 27 14:48:19 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Sun, 27 Oct 2013 19:48:19 +0100
Subject: [AstroPy] Can't install aplpy
In-Reply-To: <E7B7F293-81E9-4300-831B-B7E43A3C12CD@gmail.com>
References: <BBEFA5E7-A261-44B0-BEBF-EAC451862136@gmail.com>
	<E7B7F293-81E9-4300-831B-B7E43A3C12CD@gmail.com>
Message-ID: <CAGMHX_39zwqyYVx6geOCGjZMrRrK_DEdZa3MOVBuw00k3YcZoA@mail.gmail.com>

Hi Sandily,

Could you try doing:

export LOCALE="C"

then trying the pip command again? Any luck?

Cheers,
Tom


On 27 October 2013 19:25, Sandily Rivera <sandily.r at gmail.com> wrote:
>
>>
>> Hi, I'm trying to install the package APLpy but I can't, I have a Macbok pro with OS X 10.8.5.
>>
>> This is what I typed:
>> pip install --upgrade aplpy
>>
>> and this is what I got:
>>
>>
>> Downloading/unpacking aplpy
>>  Downloading APLpy-0.9.9.tar.gz (689kB): 689kB downloaded
>>  Running setup.py egg_info for package aplpy
>>    Traceback (most recent call last):
>>      File "<string>", line 16, in <module>
>>      File "/private/var/folders/bf/jrt8km3d32n_l86k03wkv1l00000gn/T/pip_build_Sandily/aplpy/setup.py", line 31, in <module>
>>        from astropy.setup_helpers import (register_commands, adjust_compiler,
>>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/astropy/setup_helpers.py", line 46, in <module>
>>        from sphinx.setup_command import BuildDoc as SphinxBuildDoc
>>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/sphinx/setup_command.py", line 20, in <module>
>>        from sphinx.application import Sphinx
>>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/sphinx/application.py", line 21, in <module>
>>        from docutils.parsers.rst import convert_directive_function, \
>>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/parsers/rst/__init__.py", line 74, in <module>
>>        import docutils.statemachine
>>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/statemachine.py", line 113, in <module>
>>        from docutils import utils
>>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/utils/__init__.py", line 20, in <module>
>>        import docutils.io
>>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/io.py", line 18, in <module>
>>        from docutils.utils.error_reporting import locale_encoding, ErrorString, ErrorOutput
>>      File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/utils/error_reporting.py", line 47, in <module>
>>        locale_encoding = locale.getlocale()[1] or locale.getdefaultlocale()[1]
>>      File "/Users/NoeR/anaconda/lib/python2.7/locale.py", line 511, in getdefaultlocale
>>        return _parse_localename(localename)
>>      File "/Users/NoeR/anaconda/lib/python2.7/locale.py", line 443, in _parse_localename
>>        raise ValueError, 'unknown locale: %s' % localename
>>    ValueError: unknown locale: UTF-8
>>    Complete output from command python setup.py egg_info:
>>    Traceback (most recent call last):
>>
>>  File "<string>", line 16, in <module>
>>
>>  File "/private/var/folders/bf/jrt8km3d32n_l86k03wkv1l00000gn/T/pip_build_Sandily/aplpy/setup.py", line 31, in <module>
>>
>>    from astropy.setup_helpers import (register_commands, adjust_compiler,
>>
>>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/astropy/setup_helpers.py", line 46, in <module>
>>
>>    from sphinx.setup_command import BuildDoc as SphinxBuildDoc
>>
>>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/sphinx/setup_command.py", line 20, in <module>
>>
>>    from sphinx.application import Sphinx
>>
>>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/sphinx/application.py", line 21, in <module>
>>
>>    from docutils.parsers.rst import convert_directive_function, \
>>
>>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/parsers/rst/__init__.py", line 74, in <module>
>>
>>    import docutils.statemachine
>>
>>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/statemachine.py", line 113, in <module>
>>
>>    from docutils import utils
>>
>>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/utils/__init__.py", line 20, in <module>
>>
>>    import docutils.io
>>
>>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/io.py", line 18, in <module>
>>
>>    from docutils.utils.error_reporting import locale_encoding, ErrorString, ErrorOutput
>>
>>  File "/Users/NoeR/anaconda/lib/python2.7/site-packages/docutils/utils/error_reporting.py", line 47, in <module>
>>
>>    locale_encoding = locale.getlocale()[1] or locale.getdefaultlocale()[1]
>>
>>  File "/Users/NoeR/anaconda/lib/python2.7/locale.py", line 511, in getdefaultlocale
>>
>>    return _parse_localename(localename)
>>
>>  File "/Users/NoeR/anaconda/lib/python2.7/locale.py", line 443, in _parse_localename
>>
>>    raise ValueError, 'unknown locale: %s' % localename
>>
>> ValueError: unknown locale: UTF-8
>>
>> ----------------------------------------
>> Cleaning up...
>> Command python setup.py egg_info failed with error code 1 in /private/var/folders/bf/jrt8km3d32n_l86k03wkv1l00000gn/T/pip_build_Sandily/aplpy
>> Storing complete log in /Users/NoeR/.pip/pip.log
>>
>>
>> I'm new at this so I don't know how to fix it, hope you can help me.
>>
>> Thank you
>> Sandily Rivera
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From embray at stsci.edu  Mon Oct 28 11:55:14 2013
From: embray at stsci.edu (Erik Bray)
Date: Mon, 28 Oct 2013 11:55:14 -0400
Subject: [AstroPy] reading table from string
In-Reply-To: <CAG-7A+6HS4e5LTO1PU4Pq1cfYnNJ_U=vYcsYC7_D9fPTbHYahQ@mail.gmail.com>
References: <CAG-7A+6HS4e5LTO1PU4Pq1cfYnNJ_U=vYcsYC7_D9fPTbHYahQ@mail.gmail.com>
Message-ID: <526E88E2.2020404@stsci.edu>

On 10/24/2013 11:34 PM, Semyeong Oh wrote:
> Hi,
>
> If I use 'names' keyword when reading a table from string,
> the first line is ignored.
>
> new="""
> 3102  0.32 <tel:3102%C2%A0%200.32>      4167  4085   Q1250+568-A
> 877   0.22      4378  3892   "Source 82"
> """
> t = ascii.read(new, names=['obsid','redshift','X','Y','object'])
> print t
>
>
> obsid redshift  X    Y     object
> ----- -------- ---- ---- ---------
>    877     0.22 4378 3892 Source 82
>
>
> Is this a bug?

Hi,

I'm not an expert with asciitables so I'm not sure, but I don't *think* that's a 
bug.  I think that the default reader assumes your first line is a header and 
throws it away.  For example, try:

print ascii.read(new, data_start=0, names=['obsid','redshift','X','Y','object'])

That should work.

That said, I think this is surprising behavior, especially considering that you 
manually provided the column names.  If I run it without providing column names 
it still reads the whole table and uses dummy column names:

In [9]: print ascii.read(dat)
col1 col2 col3 col4     col5
---- ---- ---- ---- -----------
3102 0.32 4167 4085 Q1250+568-A
  877 0.22 4378 3892   Source 82

So maybe this is a bug after all...

Erik


From embray at stsci.edu  Mon Oct 28 14:22:42 2013
From: embray at stsci.edu (Erik Bray)
Date: Mon, 28 Oct 2013 14:22:42 -0400
Subject: [AstroPy] reading table from string
In-Reply-To: <CAG-7A+6HS4e5LTO1PU4Pq1cfYnNJ_U=vYcsYC7_D9fPTbHYahQ@mail.gmail.com>
References: <CAG-7A+6HS4e5LTO1PU4Pq1cfYnNJ_U=vYcsYC7_D9fPTbHYahQ@mail.gmail.com>
Message-ID: <526EAB72.9030505@stsci.edu>

Indeed it does look like an issue has been opened about this:

https://github.com/astropy/astropy/issues/1692

As I suggested it's sort of the "intended" behavior, but that doesn't make it 
right as it's obviously confusing in this case.

Erik

On 10/24/2013 11:34 PM, Semyeong Oh wrote:
> Hi,
>
> If I use 'names' keyword when reading a table from string,
> the first line is ignored.
>
> new="""
> 3102  0.32 <tel:3102%C2%A0%200.32>      4167  4085   Q1250+568-A
> 877   0.22      4378  3892   "Source 82"
> """
> t = ascii.read(new, names=['obsid','redshift','X','Y','object'])
> print t
>
>
> obsid redshift  X    Y     object
> ----- -------- ---- ---- ---------
>    877     0.22 4378 3892 Source 82
>
>
> Is this a bug?
>
> Thanks,
> Semyeong
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



From herrero at iaa.es  Tue Oct 29 07:45:01 2013
From: herrero at iaa.es (Ruben Herrero-Illana)
Date: Tue, 29 Oct 2013 12:45:01 +0100
Subject: [AstroPy] Regrid images
Message-ID: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20@iaa.es>

Hi,

I often need to regrid an image to have the same pixel size, shape and coordinate system as other. Usually I use the CASA task 'imregrid', but I'm wondering if there is something similar implemented in AstroPy. 

Thank you!

Cheers,
Rub?n


---------------------------------------------
Rub?n Herrero-Illana
Instituto de Astrof?sica de Andaluc?a (IAA-CSIC)
Glorieta de la Astronom?a s/n
18008 - Granada (Spain)
Tel: (+34) 958 230 536
Fax: (+34) 958 814 530
herrero at iaa.es
---------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131029/31e9faac/attachment.html>

From slianou at uwo.ca  Tue Oct 29 10:24:47 2013
From: slianou at uwo.ca (Sofia Lianou)
Date: Tue, 29 Oct 2013 10:24:47 -0400
Subject: [AstroPy] Regrid images
In-Reply-To: <7690ffd31bdb6.526fc50c@uwo.ca>
References: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20@iaa.es>
	<7710ad241b7eb.526fc393@uwo.ca> <77a0d6471bda5.526fc3d0@uwo.ca>
	<76f0f2be1e08a.526fc40e@uwo.ca> <7710a4ce1f605.526fc44e@uwo.ca>
	<7730e0b21b99d.526fc48d@uwo.ca> <7680f3ef18888.526fc4cc@uwo.ca>
	<7690ffd31bdb6.526fc50c@uwo.ca>
Message-ID: <7730fd0d19b6d.526f8cef@uwo.ca>

Hi Ruben,?

We are currently working on a module, called imagecube, of which one task is designed to do exactly this. The plan is to submit this module under astropy in the near future. 


We will be happy to share in advance of formal release a preliminary copy of the module, so please contact us if you have an interest on this: Jeff Taylor <jeff.c.taylor at gmail.com>; Sophia Lianou <sophia.thl at gmail.com>; Pauline Barmby <pbarmby at uwo.ca> . 

Cheers,
Sophia

On 10/29/13, Ruben Herrero-Illana  <herrero at iaa.es> wrote:
> 
> 
> 
> 
> Hi,
> 
> 
> I often need to regrid an image to have the same pixel size, shape and coordinate system as other. Usually I use the CASA task 'imregrid', but I'm wondering if there is something similar implemented in AstroPy. 
> 
> 
> Thank you!
> 
> 
> Cheers,
> Rub?n
> 
> 
> 
> 
> ---------------------------------------------
> Rub?n Herrero-Illana
> 
> Instituto de Astrof?sica de Andaluc?a (IAA-CSIC)
> Glorieta de la Astronom?a s/n
> 18008 - Granada (Spain)
> 
> Tel: (+34) 958 230 536
> Fax: (+34) 958 814 530
> herrero at iaa.es
> ---------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131029/dc86cc6a/attachment.html>

From tim.jenness at gmail.com  Tue Oct 29 11:01:05 2013
From: tim.jenness at gmail.com (Tim Jenness)
Date: Tue, 29 Oct 2013 08:01:05 -0700
Subject: [AstroPy] Regrid images
In-Reply-To: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20@iaa.es>
References: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20@iaa.es>
Message-ID: <CA+G92RfC+coM_LFneeAFyTXSYOzYxnnHq4NWVTt+psm_nw-oEw@mail.gmail.com>

pyast can do this (there is an option for resampling or flux conserving
rebinning).

-- 
Tim Jenness


On Tue, Oct 29, 2013 at 4:45 AM, Ruben Herrero-Illana <herrero at iaa.es>wrote:

> Hi,
>
> I often need to regrid an image to have the same pixel size, shape and
> coordinate system as other. Usually I use the CASA task 'imregrid', but I'm
> wondering if there is something similar implemented in AstroPy.
>
> Thank you!
>
> Cheers,
> Rub?n
>
>
> ---------------------------------------------
> Rub?n Herrero-Illana
> Instituto de Astrof?sica de Andaluc?a (IAA-CSIC)
> Glorieta de la Astronom?a s/n
> 18008 - Granada (Spain)
> Tel: (+34) 958 230 536
> Fax: (+34) 958 814 530
> herrero at iaa.es
> ---------------------------------------------
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131029/04323ae5/attachment.html>

From adam.g.ginsburg at gmail.com  Tue Oct 29 11:00:50 2013
From: adam.g.ginsburg at gmail.com (Adam Ginsburg)
Date: Tue, 29 Oct 2013 16:00:50 +0100
Subject: [AstroPy] Regrid images
In-Reply-To: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20@iaa.es>
References: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20@iaa.es>
Message-ID: <CAEBNSwYQQL7k0p0ERHPGwPOXs6b92r+zLb9=zPOAptvKUCLfAg@mail.gmail.com>

For a 2D image, my recommendation is to use Tom Robitaille's montage wrapper:
http://www.astropy.org/montage-wrapper/
which means you'll need montage too:
http://montage.ipac.caltech.edu/


On Tue, Oct 29, 2013 at 12:45 PM, Ruben Herrero-Illana <herrero at iaa.es> wrote:
> Hi,
>
> I often need to regrid an image to have the same pixel size, shape and
> coordinate system as other. Usually I use the CASA task 'imregrid', but I'm
> wondering if there is something similar implemented in AstroPy.
>
> Thank you!
>
> Cheers,
> Rub?n
>
>
> ---------------------------------------------
> Rub?n Herrero-Illana
> Instituto de Astrof?sica de Andaluc?a (IAA-CSIC)
> Glorieta de la Astronom?a s/n
> 18008 - Granada (Spain)
> Tel: (+34) 958 230 536
> Fax: (+34) 958 814 530
> herrero at iaa.es
> ---------------------------------------------
>
>
> _______________________________________________
> 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 demitri.muna at gmail.com  Tue Oct 29 11:18:19 2013
From: demitri.muna at gmail.com (Demitri Muna)
Date: Tue, 29 Oct 2013 11:18:19 -0400
Subject: [AstroPy] Regrid images
In-Reply-To: <CAEBNSwYQQL7k0p0ERHPGwPOXs6b92r+zLb9=zPOAptvKUCLfAg@mail.gmail.com>
References: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20@iaa.es>
	<CAEBNSwYQQL7k0p0ERHPGwPOXs6b92r+zLb9=zPOAptvKUCLfAg@mail.gmail.com>
Message-ID: <3F40DCCB-C29D-4B3B-A155-D9AFD08EF8B4@gmail.com>

Hi,

Glad to hear there are several solutions in astropy to regrid an image as that?s certainly very useful.

Somewhat concerned that there are several solutions in astropy to regrid an image.

Demitri

_________________________________________
Demitri Muna

Department of Astronomy
La Ohio State University

http://scicoder.org/





From twblaise1er at gmail.com  Tue Oct 29 11:52:36 2013
From: twblaise1er at gmail.com (Blaise Tapsoba)
Date: Tue, 29 Oct 2013 17:52:36 +0200
Subject: [AstroPy] AstroPy Digest, Vol 85, Issue 21
In-Reply-To: <mailman.2669.1383058534.1002.astropy@scipy.org>
References: <mailman.2669.1383058534.1002.astropy@scipy.org>
Message-ID: <07915F87-E231-47D1-BB2B-2B8ABE84901A@gmail.com>



> Send AstroPy mailing list submissions to
> 	astropy at scipy.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.scipy.org/mailman/listinfo/astropy
> or, via email, send a message with subject or body 'help' to
> 	astropy-request at scipy.org
> 
> You can reach the person managing the list at
> 	astropy-owner at scipy.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AstroPy digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: reading table from string (Erik Bray)

For the first questions, reading table from string , I often use the following method
On 29 Oct 2013, at 4:55 PM, astropy-request at scipy.org wrote:

file = loadtxt('table.txt', skiprows  = 3)

column_1 = file[:,0]   # all the data of the first column
column_2  = file[1,:]  # the data of the second column

Blaise

>   2. Regrid images (Ruben Herrero-Illana)
>   3. Re: Regrid images (Sofia Lianou)
>   4. Re: Regrid images (Tim Jenness)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 28 Oct 2013 14:22:42 -0400
> From: Erik Bray <embray at stsci.edu>
> Subject: Re: [AstroPy] reading table from string
> To: <astropy at scipy.org>
> Message-ID: <526EAB72.9030505 at stsci.edu>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
> 
> Indeed it does look like an issue has been opened about this:
> 
> https://github.com/astropy/astropy/issues/1692
> 
> As I suggested it's sort of the "intended" behavior, but that doesn't make it 
> right as it's obviously confusing in this case.
> 
> Erik
> 
> On 10/24/2013 11:34 PM, Semyeong Oh wrote:
>> Hi,
>> 
>> If I use 'names' keyword when reading a table from string,
>> the first line is ignored.
>> 
>> new="""
>> 3102  0.32 <tel:3102%C2%A0%200.32>      4167  4085   Q1250+568-A
>> 877   0.22      4378  3892   "Source 82"
>> """
>> t = ascii.read(new, names=['obsid','redshift','X','Y','object'])
>> print t
>> 
>> 
>> obsid redshift  X    Y     object
>> ----- -------- ---- ---- ---------
>>   877     0.22 4378 3892 Source 82
>> 
>> 
>> Is this a bug?
>> 
>> Thanks,
>> Semyeong
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 29 Oct 2013 12:45:01 +0100
> From: Ruben Herrero-Illana <herrero at iaa.es>
> Subject: [AstroPy] Regrid images
> To: astropy at scipy.org
> Message-ID: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20 at iaa.es>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi,
> 
> I often need to regrid an image to have the same pixel size, shape and coordinate system as other. Usually I use the CASA task 'imregrid', but I'm wondering if there is something similar implemented in AstroPy. 
> 
> Thank you!
> 
> Cheers,
> Rub?n
> 
> 
> ---------------------------------------------
> Rub?n Herrero-Illana
> Instituto de Astrof?sica de Andaluc?a (IAA-CSIC)
> Glorieta de la Astronom?a s/n
> 18008 - Granada (Spain)
> Tel: (+34) 958 230 536
> Fax: (+34) 958 814 530
> herrero at iaa.es
> ---------------------------------------------
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.scipy.org/pipermail/astropy/attachments/20131029/31e9faac/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 29 Oct 2013 10:24:47 -0400
> From: Sofia Lianou <slianou at uwo.ca>
> Subject: Re: [AstroPy] Regrid images
> To: Ruben Herrero-Illana <herrero at iaa.es>, astropy at scipy.org
> Message-ID: <7730fd0d19b6d.526f8cef at uwo.ca>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi Ruben,?
> 
> We are currently working on a module, called imagecube, of which one task is designed to do exactly this. The plan is to submit this module under astropy in the near future. 
> 
> 
> We will be happy to share in advance of formal release a preliminary copy of the module, so please contact us if you have an interest on this: Jeff Taylor <jeff.c.taylor at gmail.com>; Sophia Lianou <sophia.thl at gmail.com>; Pauline Barmby <pbarmby at uwo.ca> . 
> 
> Cheers,
> Sophia
> 
> On 10/29/13, Ruben Herrero-Illana  <herrero at iaa.es> wrote:
>> 
>> 
>> 
>> 
>> Hi,
>> 
>> 
>> I often need to regrid an image to have the same pixel size, shape and coordinate system as other. Usually I use the CASA task 'imregrid', but I'm wondering if there is something similar implemented in AstroPy. 
>> 
>> 
>> Thank you!
>> 
>> 
>> Cheers,
>> Rub?n
>> 
>> 
>> 
>> 
>> ---------------------------------------------
>> Rub?n Herrero-Illana
>> 
>> Instituto de Astrof?sica de Andaluc?a (IAA-CSIC)
>> Glorieta de la Astronom?a s/n
>> 18008 - Granada (Spain)
>> 
>> Tel: (+34) 958 230 536
>> Fax: (+34) 958 814 530
>> herrero at iaa.es
>> ---------------------------------------------
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.scipy.org/pipermail/astropy/attachments/20131029/dc86cc6a/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 29 Oct 2013 08:01:05 -0700
> From: Tim Jenness <tim.jenness at gmail.com>
> Subject: Re: [AstroPy] Regrid images
> To: Ruben Herrero-Illana <herrero at iaa.es>, astropy <AstroPy at scipy.org>
> Message-ID:
> 	<CA+G92RfC+coM_LFneeAFyTXSYOzYxnnHq4NWVTt+psm_nw-oEw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> pyast can do this (there is an option for resampling or flux conserving
> rebinning).
> 
> -- 
> Tim Jenness
> 
> 
> On Tue, Oct 29, 2013 at 4:45 AM, Ruben Herrero-Illana <herrero at iaa.es>wrote:
> 
>> Hi,
>> 
>> I often need to regrid an image to have the same pixel size, shape and
>> coordinate system as other. Usually I use the CASA task 'imregrid', but I'm
>> wondering if there is something similar implemented in AstroPy.
>> 
>> Thank you!
>> 
>> Cheers,
>> Rub?n
>> 
>> 
>> ---------------------------------------------
>> Rub?n Herrero-Illana
>> Instituto de Astrof?sica de Andaluc?a (IAA-CSIC)
>> Glorieta de la Astronom?a s/n
>> 18008 - Granada (Spain)
>> Tel: (+34) 958 230 536
>> Fax: (+34) 958 814 530
>> herrero at iaa.es
>> ---------------------------------------------
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>> 
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.scipy.org/pipermail/astropy/attachments/20131029/04323ae5/attachment.html 
> 
> ------------------------------
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
> 
> 
> End of AstroPy Digest, Vol 85, Issue 21
> ***************************************



From twblaise1er at gmail.com  Tue Oct 29 11:55:31 2013
From: twblaise1er at gmail.com (Blaise Tapsoba)
Date: Tue, 29 Oct 2013 17:55:31 +0200
Subject: [AstroPy] AstroPy Digest, Vol 85, Issue 21
In-Reply-To: <mailman.2669.1383058534.1002.astropy@scipy.org>
References: <mailman.2669.1383058534.1002.astropy@scipy.org>
Message-ID: <5399DB57-9A67-472A-9270-F2D54B21642C@gmail.com>


On 29 Oct 2013, at 4:55 PM, astropy-request at scipy.org wrote:

> Send AstroPy mailing list submissions to
> 	astropy at scipy.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.scipy.org/mailman/listinfo/astropy
> or, via email, send a message with subject or body 'help' to
> 	astropy-request at scipy.org
> 
> You can reach the person managing the list at
> 	astropy-owner at scipy.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AstroPy digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: reading table from string (Erik Bray)

For this question I often use :
file = loadtxt('table.txt', skiprows  = 3)

column_1 = file[:,0] # all the first column
row_1 = file[0,:]  # all the second row

Blaise
(Ignore the previous email )
>   2. Regrid images (Ruben Herrero-Illana)
>   3. Re: Regrid images (Sofia Lianou)
>   4. Re: Regrid images (Tim Jenness)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 28 Oct 2013 14:22:42 -0400
> From: Erik Bray <embray at stsci.edu>
> Subject: Re: [AstroPy] reading table from string
> To: <astropy at scipy.org>
> Message-ID: <526EAB72.9030505 at stsci.edu>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
> 
> Indeed it does look like an issue has been opened about this:
> 
> https://github.com/astropy/astropy/issues/1692
> 
> As I suggested it's sort of the "intended" behavior, but that doesn't make it 
> right as it's obviously confusing in this case.
> 
> Erik
> 
> On 10/24/2013 11:34 PM, Semyeong Oh wrote:
>> Hi,
>> 
>> If I use 'names' keyword when reading a table from string,
>> the first line is ignored.
>> 
>> new="""
>> 3102  0.32 <tel:3102%C2%A0%200.32>      4167  4085   Q1250+568-A
>> 877   0.22      4378  3892   "Source 82"
>> """
>> t = ascii.read(new, names=['obsid','redshift','X','Y','object'])
>> print t
>> 
>> 
>> obsid redshift  X    Y     object
>> ----- -------- ---- ---- ---------
>>   877     0.22 4378 3892 Source 82
>> 
>> 
>> Is this a bug?
>> 
>> Thanks,
>> Semyeong
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 29 Oct 2013 12:45:01 +0100
> From: Ruben Herrero-Illana <herrero at iaa.es>
> Subject: [AstroPy] Regrid images
> To: astropy at scipy.org
> Message-ID: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20 at iaa.es>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi,
> 
> I often need to regrid an image to have the same pixel size, shape and coordinate system as other. Usually I use the CASA task 'imregrid', but I'm wondering if there is something similar implemented in AstroPy. 
> 
> Thank you!
> 
> Cheers,
> Rub?n
> 
> 
> ---------------------------------------------
> Rub?n Herrero-Illana
> Instituto de Astrof?sica de Andaluc?a (IAA-CSIC)
> Glorieta de la Astronom?a s/n
> 18008 - Granada (Spain)
> Tel: (+34) 958 230 536
> Fax: (+34) 958 814 530
> herrero at iaa.es
> ---------------------------------------------
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.scipy.org/pipermail/astropy/attachments/20131029/31e9faac/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 29 Oct 2013 10:24:47 -0400
> From: Sofia Lianou <slianou at uwo.ca>
> Subject: Re: [AstroPy] Regrid images
> To: Ruben Herrero-Illana <herrero at iaa.es>, astropy at scipy.org
> Message-ID: <7730fd0d19b6d.526f8cef at uwo.ca>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi Ruben,?
> 
> We are currently working on a module, called imagecube, of which one task is designed to do exactly this. The plan is to submit this module under astropy in the near future. 
> 
> 
> We will be happy to share in advance of formal release a preliminary copy of the module, so please contact us if you have an interest on this: Jeff Taylor <jeff.c.taylor at gmail.com>; Sophia Lianou <sophia.thl at gmail.com>; Pauline Barmby <pbarmby at uwo.ca> . 
> 
> Cheers,
> Sophia
> 
> On 10/29/13, Ruben Herrero-Illana  <herrero at iaa.es> wrote:
>> 
>> 
>> 
>> 
>> Hi,
>> 
>> 
>> I often need to regrid an image to have the same pixel size, shape and coordinate system as other. Usually I use the CASA task 'imregrid', but I'm wondering if there is something similar implemented in AstroPy. 
>> 
>> 
>> Thank you!
>> 
>> 
>> Cheers,
>> Rub?n
>> 
>> 
>> 
>> 
>> ---------------------------------------------
>> Rub?n Herrero-Illana
>> 
>> Instituto de Astrof?sica de Andaluc?a (IAA-CSIC)
>> Glorieta de la Astronom?a s/n
>> 18008 - Granada (Spain)
>> 
>> Tel: (+34) 958 230 536
>> Fax: (+34) 958 814 530
>> herrero at iaa.es
>> ---------------------------------------------
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.scipy.org/pipermail/astropy/attachments/20131029/dc86cc6a/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 29 Oct 2013 08:01:05 -0700
> From: Tim Jenness <tim.jenness at gmail.com>
> Subject: Re: [AstroPy] Regrid images
> To: Ruben Herrero-Illana <herrero at iaa.es>, astropy <AstroPy at scipy.org>
> Message-ID:
> 	<CA+G92RfC+coM_LFneeAFyTXSYOzYxnnHq4NWVTt+psm_nw-oEw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> pyast can do this (there is an option for resampling or flux conserving
> rebinning).
> 
> -- 
> Tim Jenness
> 
> 
> On Tue, Oct 29, 2013 at 4:45 AM, Ruben Herrero-Illana <herrero at iaa.es>wrote:
> 
>> Hi,
>> 
>> I often need to regrid an image to have the same pixel size, shape and
>> coordinate system as other. Usually I use the CASA task 'imregrid', but I'm
>> wondering if there is something similar implemented in AstroPy.
>> 
>> Thank you!
>> 
>> Cheers,
>> Rub?n
>> 
>> 
>> ---------------------------------------------
>> Rub?n Herrero-Illana
>> Instituto de Astrof?sica de Andaluc?a (IAA-CSIC)
>> Glorieta de la Astronom?a s/n
>> 18008 - Granada (Spain)
>> Tel: (+34) 958 230 536
>> Fax: (+34) 958 814 530
>> herrero at iaa.es
>> ---------------------------------------------
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>> 
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.scipy.org/pipermail/astropy/attachments/20131029/04323ae5/attachment.html 
> 
> ------------------------------
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
> 
> 
> End of AstroPy Digest, Vol 85, Issue 21
> ***************************************



From thomas.robitaille at gmail.com  Thu Oct 31 09:59:44 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Thu, 31 Oct 2013 14:59:44 +0100
Subject: [AstroPy] ANN: montage-wrapper 0.9.6
Message-ID: <CAGMHX_34QqFW4Cey9jmPRC2cRSZDPUbENdsNBcFdyBE0X-zUjA@mail.gmail.com>

Hi everyone,

I have released a new version of montage-wrapper, a Python wrapper to
the Montage Mosaicking software developed at IPAC
(http://montage.ipac.caltech.edu/). The Python wrapper can be found
at:

  http://www.astropy.org/montage-wrapper/

This release fixes installation issues that occurred with the previous
version. For anyone not familiar with Montage, you can use it to
reproject images in a flux-conserving manner, and make mosaics from
multiple FITS files. The Python package provides wrappers to all the
commands, as well as high-level functions that make it easy to
reproject and mosaic images.

To install:

  pip install montage-wrapper

To update:

  pip install montage-wrapper --upgrade --no-deps

Please let me know if you have any issues installing this package!

Cheers,
Tom


From mdroe at stsci.edu  Thu Oct 31 10:30:39 2013
From: mdroe at stsci.edu (Michael Droettboom)
Date: Thu, 31 Oct 2013 10:30:39 -0400
Subject: [AstroPy] Regrid images
In-Reply-To: <3F40DCCB-C29D-4B3B-A155-D9AFD08EF8B4@gmail.com>
References: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20@iaa.es>	<CAEBNSwYQQL7k0p0ERHPGwPOXs6b92r+zLb9=zPOAptvKUCLfAg@mail.gmail.com>
	<3F40DCCB-C29D-4B3B-A155-D9AFD08EF8B4@gmail.com>
Message-ID: <5272698F.4070801@stsci.edu>

On 10/29/2013 11:18 AM, Demitri Muna wrote:
> Hi,
>
> Glad to hear there are several solutions in astropy to regrid an image as that?s certainly very useful.
>
> Somewhat concerned that there are several solutions in astropy to regrid an image.
>

Let me allay your concerns somewhat: none of these suggested solutions 
are actually in astropy.  As is one of the explicit goals of astropy, 
hopefully the best parts of each of these can become the "one true way 
to do it" within astropy itself overtime.

Mike

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com



From stsci.perry at gmail.com  Thu Oct 31 10:47:06 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Thu, 31 Oct 2013 10:47:06 -0400
Subject: [AstroPy] Regrid images
In-Reply-To: <5272698F.4070801@stsci.edu>
References: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20@iaa.es>	<CAEBNSwYQQL7k0p0ERHPGwPOXs6b92r+zLb9=zPOAptvKUCLfAg@mail.gmail.com>
	<3F40DCCB-C29D-4B3B-A155-D9AFD08EF8B4@gmail.com>
	<5272698F.4070801@stsci.edu>
Message-ID: <11D7BD5A-8F95-4686-B523-8B9F403E64BB@gmail.com>

I'd add that regridding is a complicated topic. There are many alternative approaches to it, each with a different emphasis on what is important to optimize. There is no single approach that optimizes every aspect. And then there is the added complication of how regridding handles the input of how coordinates are transformed. Hopefully these will all be able to use the new WCS stuff.

Perry

On Oct 31, 2013, at 10:30 AM, Michael Droettboom wrote:

> On 10/29/2013 11:18 AM, Demitri Muna wrote:
>> Hi,
>> 
>> Glad to hear there are several solutions in astropy to regrid an image as that?s certainly very useful.
>> 
>> Somewhat concerned that there are several solutions in astropy to regrid an image.
>> 
> 
> Let me allay your concerns somewhat: none of these suggested solutions 
> are actually in astropy.  As is one of the explicit goals of astropy, 
> hopefully the best parts of each of these can become the "one true way 
> to do it" within astropy itself overtime.
> 
> Mike
> 
> -- 
>                    _
> |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
> 
> http://www.droettboom.com
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From thomas.robitaille at gmail.com  Thu Oct 31 11:13:24 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Thu, 31 Oct 2013 16:13:24 +0100
Subject: [AstroPy] Regrid images
In-Reply-To: <11D7BD5A-8F95-4686-B523-8B9F403E64BB@gmail.com>
References: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20@iaa.es>
	<CAEBNSwYQQL7k0p0ERHPGwPOXs6b92r+zLb9=zPOAptvKUCLfAg@mail.gmail.com>
	<3F40DCCB-C29D-4B3B-A155-D9AFD08EF8B4@gmail.com>
	<5272698F.4070801@stsci.edu>
	<11D7BD5A-8F95-4686-B523-8B9F403E64BB@gmail.com>
Message-ID: <CAGMHX_1S1Q3aCaGgZhPvYUC5WZpuVe8QMPKuHVa8p29jjiVQUA@mail.gmail.com>

Just to add to what's already been said, there is a Python wrapper
available for the Montage toolkit:

http://www.astropy.org/montage-wrapper/

which does flux-conserving reprojection. I replied to Ruben about
this, and previously forgot to cc this list.

Cheers,
Tom


On 31 October 2013 15:47, Perry Greenfield <stsci.perry at gmail.com> wrote:
> I'd add that regridding is a complicated topic. There are many alternative approaches to it, each with a different emphasis on what is important to optimize. There is no single approach that optimizes every aspect. And then there is the added complication of how regridding handles the input of how coordinates are transformed. Hopefully these will all be able to use the new WCS stuff.
>
> Perry
>
> On Oct 31, 2013, at 10:30 AM, Michael Droettboom wrote:
>
>> On 10/29/2013 11:18 AM, Demitri Muna wrote:
>>> Hi,
>>>
>>> Glad to hear there are several solutions in astropy to regrid an image as that?s certainly very useful.
>>>
>>> Somewhat concerned that there are several solutions in astropy to regrid an image.
>>>
>>
>> Let me allay your concerns somewhat: none of these suggested solutions
>> are actually in astropy.  As is one of the explicit goals of astropy,
>> hopefully the best parts of each of these can become the "one true way
>> to do it" within astropy itself overtime.
>>
>> Mike
>>
>> --
>>                    _
>> |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
>> |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>>
>> http://www.droettboom.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


From neilcrighton at gmail.com  Thu Oct 31 17:48:22 2013
From: neilcrighton at gmail.com (Neil Crighton)
Date: Fri, 1 Nov 2013 08:48:22 +1100
Subject: [AstroPy] Regrid images
In-Reply-To: <CAGMHX_1S1Q3aCaGgZhPvYUC5WZpuVe8QMPKuHVa8p29jjiVQUA@mail.gmail.com>
References: <2BF337C0-A1B8-4AF8-803B-FB3ACFB0EB20@iaa.es>
	<CAEBNSwYQQL7k0p0ERHPGwPOXs6b92r+zLb9=zPOAptvKUCLfAg@mail.gmail.com>
	<3F40DCCB-C29D-4B3B-A155-D9AFD08EF8B4@gmail.com>
	<5272698F.4070801@stsci.edu>
	<11D7BD5A-8F95-4686-B523-8B9F403E64BB@gmail.com>
	<CAGMHX_1S1Q3aCaGgZhPvYUC5WZpuVe8QMPKuHVa8p29jjiVQUA@mail.gmail.com>
Message-ID: <CAFDPQ54J3Wn6op7pYLhxgRapV2pqET68RvHFFudaSTgO1xwCyw@mail.gmail.com>

Montage is excellent (so is Tom's wrapper), but in my experience it's
prohibitively slow for very large images.  SWARP (
http://www.astromatic.net/software/swarp) works well on bigger images.

Neil


On 1 November 2013 02:13, Thomas Robitaille <thomas.robitaille at gmail.com>wrote:

> Just to add to what's already been said, there is a Python wrapper
> available for the Montage toolkit:
>
> http://www.astropy.org/montage-wrapper/
>
> which does flux-conserving reprojection. I replied to Ruben about
> this, and previously forgot to cc this list.
>
> Cheers,
> Tom
>
>
> On 31 October 2013 15:47, Perry Greenfield <stsci.perry at gmail.com> wrote:
> > I'd add that regridding is a complicated topic. There are many
> alternative approaches to it, each with a different emphasis on what is
> important to optimize. There is no single approach that optimizes every
> aspect. And then there is the added complication of how regridding handles
> the input of how coordinates are transformed. Hopefully these will all be
> able to use the new WCS stuff.
> >
> > Perry
> >
> > On Oct 31, 2013, at 10:30 AM, Michael Droettboom wrote:
> >
> >> On 10/29/2013 11:18 AM, Demitri Muna wrote:
> >>> Hi,
> >>>
> >>> Glad to hear there are several solutions in astropy to regrid an image
> as that?s certainly very useful.
> >>>
> >>> Somewhat concerned that there are several solutions in astropy to
> regrid an image.
> >>>
> >>
> >> Let me allay your concerns somewhat: none of these suggested solutions
> >> are actually in astropy.  As is one of the explicit goals of astropy,
> >> hopefully the best parts of each of these can become the "one true way
> >> to do it" within astropy itself overtime.
> >>
> >> Mike
> >>
> >> --
> >>                    _
> >> |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> >> |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
> >>
> >> http://www.droettboom.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
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20131101/f9b3b658/attachment.html>

From jakevdp at cs.washington.edu  Thu Oct 31 20:08:16 2013
From: jakevdp at cs.washington.edu (Jacob Vanderplas)
Date: Thu, 31 Oct 2013 17:08:16 -0700
Subject: [AstroPy] Inverting SIP distortions
Message-ID: <CACpqBg0ctUPPO7_+=hvYHw437YoT1JhL0-E+Ff95GDL0TDAY7Q@mail.gmail.com>

Hello,
I'm working on a problem that requires the inversion of SIP
corrections: that is, I have points in world coordinates that I want
to project onto an image plane.

My FITS header contains both the (A_p_q, B_p_q) coefficients for the
forward transformation, as well as the (AP_p_q, BP_p_q) required for
the backward transformation, according to the Shupe et al 2005
reference.

The astropy WCS object has methods sip_foc2pix() and sip_pix2foc(),
which appeared to be what I needed, but these don't seem to actually
invert each other. That is:

>>> from astropy.wcs import WCS
>>> wcs = WCS(header)
>>> Xpix = [[1, 1]]
>>> Xfoc = wcs.sip_pix2foc(Xpix, 0)
>>> print wcs.sip_foc2pix(Xfoc, 0)
[[ 1.2522118   1.74039233]]

I would have expected this to recover the input pixels, but it's
clearly not the case.  Is there any functionality in astropy that will
utilize the available AP/BP coefficients in my header to perform the
inverse SIP distortion?  Is there anything I'm doing wrong or missing
here?
Thanks,
   Jake


From npkuin at gmail.com  Thu Oct 31 21:02:12 2013
From: npkuin at gmail.com (Paul Kuin)
Date: Fri, 1 Nov 2013 01:02:12 +0000
Subject: [AstroPy] Inverting SIP distortions
In-Reply-To: <CACpqBg0ctUPPO7_+=hvYHw437YoT1JhL0-E+Ff95GDL0TDAY7Q@mail.gmail.com>
References: <CACpqBg0ctUPPO7_+=hvYHw437YoT1JhL0-E+Ff95GDL0TDAY7Q@mail.gmail.com>
Message-ID: <CANoQ6N1HsYn30qawURt7WnuXmrg3M6sZF6Ev-xyOSyrkLuxCrQ@mail.gmail.com>

I suppose the WCS you have has the right type, e.g., like:

       fh[int(ext)].header['CTYPE1']='RA---TAN-SIP'
       fh[int(ext)].header['CTYPE2']='DEC--TAN-SIP'

If so, I happen to use, to go from pixle position to ra,dec,

world = wS.all_pix2world([bore],0)[0]

did not invert, but it seems I'm using different function/method
whatever-its-called.  Any help?

Paul


On Fri, Nov 1, 2013 at 12:08 AM, Jacob Vanderplas <jakevdp at cs.washington.edu
> wrote:

> Hello,
> I'm working on a problem that requires the inversion of SIP
> corrections: that is, I have points in world coordinates that I want
> to project onto an image plane.
>
> My FITS header contains both the (A_p_q, B_p_q) coefficients for the
> forward transformation, as well as the (AP_p_q, BP_p_q) required for
> the backward transformation, according to the Shupe et al 2005
> reference.
>
> The astropy WCS object has methods sip_foc2pix() and sip_pix2foc(),
> which appeared to be what I needed, but these don't seem to actually
> invert each other. That is:
>
> >>> from astropy.wcs import WCS
> >>> wcs = WCS(header)
> >>> Xpix = [[1, 1]]
> >>> Xfoc = wcs.sip_pix2foc(Xpix, 0)
> >>> print wcs.sip_foc2pix(Xfoc, 0)
> [[ 1.2522118   1.74039233]]
>
> I would have expected this to recover the input pixels, but it's
> clearly not the case.  Is there any functionality in astropy that will
> utilize the available AP/BP coefficients in my header to perform the
> inverse SIP distortion?  Is there anything I'm doing wrong or missing
> here?
> Thanks,
>    Jake
> _______________________________________________
> 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: <http://mail.python.org/pipermail/astropy/attachments/20131101/a6e652b2/attachment.html>

From jakevdp at cs.washington.edu  Thu Oct 31 21:35:02 2013
From: jakevdp at cs.washington.edu (Jacob Vanderplas)
Date: Thu, 31 Oct 2013 18:35:02 -0700
Subject: [AstroPy] Inverting SIP distortions
In-Reply-To: <CANoQ6N1HsYn30qawURt7WnuXmrg3M6sZF6Ev-xyOSyrkLuxCrQ@mail.gmail.com>
References: <CACpqBg0ctUPPO7_+=hvYHw437YoT1JhL0-E+Ff95GDL0TDAY7Q@mail.gmail.com>
	<CANoQ6N1HsYn30qawURt7WnuXmrg3M6sZF6Ev-xyOSyrkLuxCrQ@mail.gmail.com>
Message-ID: <CACpqBg3h173ux48WaXw0aRQxc4UvoPjH=H0SZ2gDecBgftUrnA@mail.gmail.com>

Hi,
yes, I should have specified, it's a standard header type:

>>> print wcs.wcs.ctype
['RA---TAN-SIP', 'DEC--TAN-SIP']

  Jake


On Thu, Oct 31, 2013 at 6:02 PM, Paul Kuin <npkuin at gmail.com> wrote:
>
> I suppose the WCS you have has the right type, e.g., like:
>
>        fh[int(ext)].header['CTYPE1']='RA---TAN-SIP'
>        fh[int(ext)].header['CTYPE2']='DEC--TAN-SIP'
>
> If so, I happen to use, to go from pixle position to ra,dec,
>
> world = wS.all_pix2world([bore],0)[0]
>
> did not invert, but it seems I'm using different function/method
> whatever-its-called.  Any help?
>
> Paul
>
>
> On Fri, Nov 1, 2013 at 12:08 AM, Jacob Vanderplas
> <jakevdp at cs.washington.edu> wrote:
>>
>> Hello,
>> I'm working on a problem that requires the inversion of SIP
>> corrections: that is, I have points in world coordinates that I want
>> to project onto an image plane.
>>
>> My FITS header contains both the (A_p_q, B_p_q) coefficients for the
>> forward transformation, as well as the (AP_p_q, BP_p_q) required for
>> the backward transformation, according to the Shupe et al 2005
>> reference.
>>
>> The astropy WCS object has methods sip_foc2pix() and sip_pix2foc(),
>> which appeared to be what I needed, but these don't seem to actually
>> invert each other. That is:
>>
>> >>> from astropy.wcs import WCS
>> >>> wcs = WCS(header)
>> >>> Xpix = [[1, 1]]
>> >>> Xfoc = wcs.sip_pix2foc(Xpix, 0)
>> >>> print wcs.sip_foc2pix(Xfoc, 0)
>> [[ 1.2522118   1.74039233]]
>>
>> I would have expected this to recover the input pixels, but it's
>> clearly not the case.  Is there any functionality in astropy that will
>> utilize the available AP/BP coefficients in my header to perform the
>> inverse SIP distortion?  Is there anything I'm doing wrong or missing
>> here?
>> Thanks,
>>    Jake
>> _______________________________________________
>> 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.