From crawfordsm at gmail.com  Tue Oct  4 15:45:39 2016
From: crawfordsm at gmail.com (Steve Crawford)
Date: Tue, 4 Oct 2016 21:45:39 +0200
Subject: [AstroPy] IRAF geomap and geotran equivalent in AstroPy?
In-Reply-To: <CAEV45yDjEbMQf_JhP1SnwD=VyOG31xHwWgh4dJkK5_34wR9KwA@mail.gmail.com>
References: <CAEV45yDjEbMQf_JhP1SnwD=VyOG31xHwWgh4dJkK5_34wR9KwA@mail.gmail.com>
Message-ID: <CAE+obB_9g9C3MMcgRvr+hBX4ZM2bbr0sT9E+1hboR+Ki4RwDQg@mail.gmail.com>

Hi Russell,

Neither has a direct transformation into python as far as I know.
However, here are the status of some related things:

There are a lot of things in python that let's you transform your
image (scikit image for example).   In ccdproc, we have wrapped the
reproject package to provide a transform_image task:
http://ccdproc.readthedocs.io/en/latest/api/ccdproc.transform_image.html#ccdproc.transform_image

This will provide similar functionality to geotran but the user has to
provide what the transformation they want to provide.

Also, I've started on a little bit of a work in progress of a
geomap/ccmap replacement as it does seem like a high priority item.
However I have not made much progress at the moment, but if anyone
wants to coordinate, please let me know.

On the other hand, there are other packages (astrometry.net, swarp for
example) that do similar things as well that might be just as good or
better.

Cheers
Steve

On Wed, Sep 28, 2016 at 5:29 AM, Russell Kackley <rkackley at naoj.org> wrote:
> I have some code that uses the IRAF geomap and geotran tasks via the pyraf
> interface. I would like to replace those IRAF tasks with something from
> AstroPy, if possible. I searched the AstroPy mailing
> list archives to see if anyone had a suggestion for an AstroPy replacement
> for those two tasks. Back in June 2010, Juan Catalan asked if AstroPy had
> something equivalent to geomap and geotran.
>
> https://mail.scipy.org/pipermail/astropy/2010-June/000971.html
>
> However, I didn't see a reply that suggested an AstroPy equivalent for the
> IRAF tasks. Does anyone on the list have a suggestion for an AstroPy
> replacement of geomap and/or geotran? Thanks.
>
> --
> Russell Kackley
> Subaru Telescope
> Hilo, Hawaii
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>


From mihail.cara at gmail.com  Thu Oct  6 13:54:17 2016
From: mihail.cara at gmail.com (Mihai Cara)
Date: Thu, 06 Oct 2016 13:54:17 -0400
Subject: [AstroPy] IRAF geomap and geotran equivalent in AstroPy?
Message-ID: <D41C057B.1FF78%mihail.cara@gmail.com>

It has been a long time since I've used either geomap or geotran and so I
cannot guarantee that my suggestions will 100% match your needs.
DrizzlePac from STScI (https://github.com/spacetelescope/drizzlepac)
contains methods that replicate (somewhat) geomap except they can do the
fitting only using linear transformations (no support for higher order
polynomials):

import drizzlepac
drizzlepac.linearfit.fit_all(xy, uv, method='rscale')

NOTE: method='general' allows fitting for skews as well (that is, it
produces two rotation angles, two scales, and two shifts).

Another low-level package https://github.com/spacetelescope/drizzle can be
used to resample your images. However, you will need to provide your own
coordinate mappings computed from the transformations found in the fitting
step.

Mihai


>Today's Topics:
>
>   1. Re: IRAF geomap and geotran equivalent in AstroPy?
>      (Steve Crawford)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 4 Oct 2016 21:45:39 +0200
>From: Steve Crawford <crawfordsm at gmail.com>
>To: Astronomical Python mailing list <astropy at scipy.org>
>Subject: Re: [AstroPy] IRAF geomap and geotran equivalent in AstroPy?
>Message-ID:
>	<CAE+obB_9g9C3MMcgRvr+hBX4ZM2bbr0sT9E+1hboR+Ki4RwDQg at mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>Hi Russell,
>
>Neither has a direct transformation into python as far as I know.
>However, here are the status of some related things:
>
>There are a lot of things in python that let's you transform your
>image (scikit image for example).   In ccdproc, we have wrapped the
>reproject package to provide a transform_image task:
>http://ccdproc.readthedocs.io/en/latest/api/ccdproc.transform_image.html#c
>cdproc.transform_image
>
>This will provide similar functionality to geotran but the user has to
>provide what the transformation they want to provide.
>
>Also, I've started on a little bit of a work in progress of a
>geomap/ccmap replacement as it does seem like a high priority item.
>However I have not made much progress at the moment, but if anyone
>wants to coordinate, please let me know.
>
>On the other hand, there are other packages (astrometry.net, swarp for
>example) that do similar things as well that might be just as good or
>better.
>
>Cheers
>Steve
>
>On Wed, Sep 28, 2016 at 5:29 AM, Russell Kackley <rkackley at naoj.org>
>wrote:
>> I have some code that uses the IRAF geomap and geotran tasks via the
>>pyraf
>> interface. I would like to replace those IRAF tasks with something from
>> AstroPy, if possible. I searched the AstroPy mailing
>> list archives to see if anyone had a suggestion for an AstroPy
>>replacement
>> for those two tasks. Back in June 2010, Juan Catalan asked if AstroPy
>>had
>> something equivalent to geomap and geotran.
>>
>> https://mail.scipy.org/pipermail/astropy/2010-June/000971.html
>>
>> However, I didn't see a reply that suggested an AstroPy equivalent for
>>the
>> IRAF tasks. Does anyone on the list have a suggestion for an AstroPy
>> replacement of geomap and/or geotran? Thanks.
>>
>> --
>> Russell Kackley
>> Subaru Telescope
>> Hilo, Hawaii
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>AstroPy mailing list
>AstroPy at scipy.org
>https://mail.scipy.org/mailman/listinfo/astropy
>
>
>------------------------------
>
>End of AstroPy Digest, Vol 121, Issue 1
>***************************************




From baweaver at lbl.gov  Mon Oct 24 17:45:05 2016
From: baweaver at lbl.gov (Benjamin Alan Weaver)
Date: Mon, 24 Oct 2016 14:45:05 -0700
Subject: [AstroPy] "ASCII" tables that contain non-ASCII characters
Message-ID: <5a012f3a-c26f-a726-e122-28e88f7f4b2d@lbl.gov>

Hello y'all,

We are trying to read "ASCII" tables containing atomic line data
provided by NIST.  When you request the line wavelength data in
angstroms, NIST very helpfully labels the columns with the angstrom
symbol (?), which is not strictly part of the ASCII character set.

We can read these tables with Table.read() *and* the environment
variable LANG=en_US.utf-8 set.  However, if LANG is not set,
Table.read() fails to decode these files.

As far as I can tell the underlying read() function in astropy.io.ascii
does not accept keywords related to the file encoding.

So two questions:

1. Is the lack of an encoding keyword a bug that should be reported?

2. Is there a workaround that does not rely on LANG being set?

Kia ora koutou,
Benjamin Alan Weaver

-- 
We can lick gravity, but sometimes the paperwork is overwhelming.
  --Wernher von Braun


From nathan12343 at gmail.com  Mon Oct 24 18:01:32 2016
From: nathan12343 at gmail.com (Nathan Goldbaum)
Date: Mon, 24 Oct 2016 17:01:32 -0500
Subject: [AstroPy] "ASCII" tables that contain non-ASCII characters
In-Reply-To: <5a012f3a-c26f-a726-e122-28e88f7f4b2d@lbl.gov>
References: <5a012f3a-c26f-a726-e122-28e88f7f4b2d@lbl.gov>
Message-ID: <CAJXewOnQpf4oqQ_V9nxHbGp4xAyqQT_P6NDDm+DnakTmAZx3Cg@mail.gmail.com>

I believe this is issue 2923:

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

On Mon, Oct 24, 2016 at 4:45 PM, Benjamin Alan Weaver <baweaver at lbl.gov>
wrote:

> Hello y'all,
>
> We are trying to read "ASCII" tables containing atomic line data
> provided by NIST.  When you request the line wavelength data in
> angstroms, NIST very helpfully labels the columns with the angstrom
> symbol (?), which is not strictly part of the ASCII character set.
>
> We can read these tables with Table.read() *and* the environment
> variable LANG=en_US.utf-8 set.  However, if LANG is not set,
> Table.read() fails to decode these files.
>
> As far as I can tell the underlying read() function in astropy.io.ascii
> does not accept keywords related to the file encoding.
>
> So two questions:
>
> 1. Is the lack of an encoding keyword a bug that should be reported?
>
> 2. Is there a workaround that does not rely on LANG being set?
>
> Kia ora koutou,
> Benjamin Alan Weaver
>
> --
> We can lick gravity, but sometimes the paperwork is overwhelming.
>   --Wernher von Braun
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161024/4c8471b0/attachment.html>

From npkuin at gmail.com  Mon Oct 24 18:06:45 2016
From: npkuin at gmail.com (Paul Kuin)
Date: Mon, 24 Oct 2016 23:06:45 +0100
Subject: [AstroPy] "ASCII" tables that contain non-ASCII characters
In-Reply-To: <5a012f3a-c26f-a726-e122-28e88f7f4b2d@lbl.gov>
References: <5a012f3a-c26f-a726-e122-28e88f7f4b2d@lbl.gov>
Message-ID: <CANoQ6N2BS7gkPheUTVtFq6e1MQzv=sHFPAeDyC3kn_x5cX1c0w@mail.gmail.com>

Complain to NIST, I think is the best approach. ASCII is well-defined.

On Mon, Oct 24, 2016 at 10:45 PM, Benjamin Alan Weaver <baweaver at lbl.gov> wrote:
> Hello y'all,
>
> We are trying to read "ASCII" tables containing atomic line data
> provided by NIST.  When you request the line wavelength data in
> angstroms, NIST very helpfully labels the columns with the angstrom
> symbol (?), which is not strictly part of the ASCII character set.
>
> We can read these tables with Table.read() *and* the environment
> variable LANG=en_US.utf-8 set.  However, if LANG is not set,
> Table.read() fails to decode these files.
>
> As far as I can tell the underlying read() function in astropy.io.ascii
> does not accept keywords related to the file encoding.
>
> So two questions:
>
> 1. Is the lack of an encoding keyword a bug that should be reported?
>
> 2. Is there a workaround that does not rely on LANG being set?
>
> Kia ora koutou,
> Benjamin Alan Weaver
>
> --
> We can lick gravity, but sometimes the paperwork is overwhelming.
>   --Wernher von Braun
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://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) -204111 (work)
mobile +44(0)7908715953  skype ID: npkuin
Mullard Space Science Laboratory  ? University College London  ?
Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.


From derek at astro.physik.uni-goettingen.de  Mon Oct 24 18:11:34 2016
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Tue, 25 Oct 2016 00:11:34 +0200
Subject: [AstroPy] "ASCII" tables that contain non-ASCII characters
In-Reply-To: <CAJXewOnQpf4oqQ_V9nxHbGp4xAyqQT_P6NDDm+DnakTmAZx3Cg@mail.gmail.com>
References: <5a012f3a-c26f-a726-e122-28e88f7f4b2d@lbl.gov>
 <CAJXewOnQpf4oqQ_V9nxHbGp4xAyqQT_P6NDDm+DnakTmAZx3Cg@mail.gmail.com>
Message-ID: <36667231-37AF-486A-95E7-05E49F66F972@astro.physik.uni-goettingen.de>

On 25 Oct 2016, at 12:01 am, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
> 
> I believe this is issue 2923:
> 
> https://github.com/astropy/astropy/issues/2923
> 
> On Mon, Oct 24, 2016 at 4:45 PM, Benjamin Alan Weaver <baweaver at lbl.gov> wrote:
> Hello y'all,
> 
> We are trying to read "ASCII" tables containing atomic line data
> provided by NIST.  When you request the line wavelength data in
> angstroms, NIST very helpfully labels the columns with the angstrom
> symbol (?), which is not strictly part of the ASCII character set.
> 
> We can read these tables with Table.read() *and* the environment
> variable LANG=en_US.utf-8 set.  However, if LANG is not set,
> Table.read() fails to decode these files.
> 
> As far as I can tell the underlying read() function in astropy.io.ascii
> does not accept keywords related to the file encoding.
> 
> So two questions:
> 
> 1. Is the lack of an encoding keyword a bug that should be reported?
> 
> 2. Is there a workaround that does not rely on LANG being set?

A workaround that would at least get you away without manipulating the
environment outside Python would be

import locale
locale.setlocale(locale.LC_ALL, str(?en_US.utf8?))

Cheers,
					Derek



From aldcroft at head.cfa.harvard.edu  Mon Oct 24 21:53:20 2016
From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas)
Date: Mon, 24 Oct 2016 21:53:20 -0400
Subject: [AstroPy] "ASCII" tables that contain non-ASCII characters
In-Reply-To: <36667231-37AF-486A-95E7-05E49F66F972@astro.physik.uni-goettingen.de>
References: <5a012f3a-c26f-a726-e122-28e88f7f4b2d@lbl.gov>
 <CAJXewOnQpf4oqQ_V9nxHbGp4xAyqQT_P6NDDm+DnakTmAZx3Cg@mail.gmail.com>
 <36667231-37AF-486A-95E7-05E49F66F972@astro.physik.uni-goettingen.de>
Message-ID: <CAMtEP6w+TpN5zHdwgv67dJrYGJBv0dHudeOo2+4firDY_8PGaA@mail.gmail.com>

On Mon, Oct 24, 2016 at 6:11 PM, Derek Homeier <
derek at astro.physik.uni-goettingen.de> wrote:

> On 25 Oct 2016, at 12:01 am, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
> >
> > I believe this is issue 2923:
> >
> > https://github.com/astropy/astropy/issues/2923
> >
> > On Mon, Oct 24, 2016 at 4:45 PM, Benjamin Alan Weaver <baweaver at lbl.gov>
> wrote:
> > Hello y'all,
> >
> > We are trying to read "ASCII" tables containing atomic line data
> > provided by NIST.  When you request the line wavelength data in
> > angstroms, NIST very helpfully labels the columns with the angstrom
> > symbol (?), which is not strictly part of the ASCII character set.
> >
> > We can read these tables with Table.read() *and* the environment
> > variable LANG=en_US.utf-8 set.  However, if LANG is not set,
> > Table.read() fails to decode these files.
> >
> > As far as I can tell the underlying read() function in astropy.io.ascii
> > does not accept keywords related to the file encoding.
> >
> > So two questions:
> >
> > 1. Is the lack of an encoding keyword a bug that should be reported?
> >
> > 2. Is there a workaround that does not rely on LANG being set?
>
> A workaround that would at least get you away without manipulating the
> environment outside Python would be
>
> import locale
> locale.setlocale(locale.LC_ALL, str(?en_US.utf8?))
>

You can make this a little cleaner using the set_locale context manager in
astropy:

from astropy.utils.misc import set_locale
with set_locale('en_US.utf8'):
    dat = Table.read(...)

As to the original question of whether this should be reported as a bug, it
has already been discussed in:

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

That discussion ended without any really clear consensus except that using
Python 3 is a good thing if that is an option.  I have never seriously
evaluated how difficult it would be to implement support for unicode inputs
for Python 2.  A basic recipe is shown in the stdlib csv package
documentation, but I don't know how messy a fully working implementation
would get.

Cheers,
Tom A


>
> Cheers,
>                                         Derek
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161024/df285c9e/attachment.html>

From stephenbailey at lbl.gov  Tue Oct 25 00:38:06 2016
From: stephenbailey at lbl.gov (Stephen Bailey)
Date: Mon, 24 Oct 2016 21:38:06 -0700
Subject: [AstroPy] "ASCII" tables that contain non-ASCII characters
In-Reply-To: <CAMtEP6w+TpN5zHdwgv67dJrYGJBv0dHudeOo2+4firDY_8PGaA@mail.gmail.com>
References: <5a012f3a-c26f-a726-e122-28e88f7f4b2d@lbl.gov>
 <CAJXewOnQpf4oqQ_V9nxHbGp4xAyqQT_P6NDDm+DnakTmAZx3Cg@mail.gmail.com>
 <36667231-37AF-486A-95E7-05E49F66F972@astro.physik.uni-goettingen.de>
 <CAMtEP6w+TpN5zHdwgv67dJrYGJBv0dHudeOo2+4firDY_8PGaA@mail.gmail.com>
Message-ID: <CAMCHcTrhC6_AdTtpZay5F4jg68QUbzn5mc3+wxvXX835SG0sHQ@mail.gmail.com>

Thanks for the suggestions.  The original problem also applies to python
3.5 though ? this isn't just a python 2.7 thing.  If LANG isn't set, the
ascii table readers can break even with python 3.5 and even if the
non-ascii character is in a comment field.  e.g. the following table can't
be read with format='ascii.basic' unless $LANG is set or one of locale
tricks from Thomas or Derek is used:

# Some comment
# ? or not?
# Another comment
x y
1 2
3 4
5 6

Also, for the record: apparently Mac OSX needs 'en_US.UTF-8' and not
'en_US.utf8'; flavors of Linux will accept either.

Stephen

In [*9*]: !cat blat.csv

# Some comment

# ? or not?

# Another comment

x y

1 2

3 4

5 6


In [*10*]: sys.version

Out[*10*]: '3.5.2 |Continuum Analytics, Inc.| (default, Jul  2 2016,
17:52:12) \n[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)]'


In [*11*]: print(os.getenv('LANG'))

None


In [*12*]: t = Table.read('blat.csv', format='ascii.basic')

---------------------------------------------------------------------------

UnicodeDecodeError                        Traceback (most recent call last)

<ipython-input-12-4c7389d51f8f> in <module>()

----> 1 t = Table.read('blat.csv', format='ascii.basic')


/Users/sbailey/anaconda/envs/desi/lib/python3.5/site-packages/astropy/table/table.py
in read(cls, *args, **kwargs)

*   2330*         passed through to the underlying data reader (e.g. `~
astropy.io.ascii.read`).

*   2331*         """

-> 2332         return io_registry.read(cls, *args, **kwargs)

*   2333*

*   2334*     def write(self, *args, **kwargs):


/Users/sbailey/anaconda/envs/desi/lib/python3.5/site-packages/astropy/io/registry.py
in read(cls, *args, **kwargs)

*    349*

*    350*         reader = get_reader(format, cls)

--> 351         data = reader(*args, **kwargs)

*    352*

*    353*         if not isinstance(data, cls):


/Users/sbailey/anaconda/envs/desi/lib/python3.5/site-packages/astropy/io/ascii/connect.py
in io_read(format, filename, **kwargs)

*     35*     from .ui import read

*     36*     format = re.sub(r'^ascii\.', '', format)

---> 37     return read(filename, format=format, **kwargs)

*     38*

*     39*


/Users/sbailey/anaconda/envs/desi/lib/python3.5/site-packages/astropy/io/ascii/ui.py
in read(table, guess, **kwargs)

*    287*             try:

*    288*                 with get_readable_fileobj(table) as fileobj:

--> 289                     table = fileobj.read()

*    290*             except ValueError:  # unreadable or invalid binary
file

*    291*                 raise


/Users/sbailey/anaconda/envs/desi/lib/python3.5/encodings/ascii.py in
decode(self,
input, final)

*     24* class IncrementalDecoder(codecs.IncrementalDecoder):

*     25*     def decode(self, input, final=False):

---> 26         return codecs.ascii_decode(input, self.errors)[0]

*     27*

*     28* class StreamWriter(Codec,codecs.StreamWriter):


UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 17:
ordinal not in range(128)


In [*13*]: *with* set_locale('en_US.UTF-8'):

    ...:     t = Table.read('blat.csv', format='ascii.basic')


In [*14*]: t

Out[*14*]:

<Table length=3>

  x     y

int64 int64

----- -----

    1     2

    3     4

    5     6


On Mon, Oct 24, 2016 at 6:53 PM, Aldcroft, Thomas <
aldcroft at head.cfa.harvard.edu> wrote:

>
>
> On Mon, Oct 24, 2016 at 6:11 PM, Derek Homeier <derek at astro.physik.uni-
> goettingen.de> wrote:
>
>> On 25 Oct 2016, at 12:01 am, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>> >
>> > I believe this is issue 2923:
>> >
>> > https://github.com/astropy/astropy/issues/2923
>> >
>> > On Mon, Oct 24, 2016 at 4:45 PM, Benjamin Alan Weaver <baweaver at lbl.gov>
>> wrote:
>> > Hello y'all,
>> >
>> > We are trying to read "ASCII" tables containing atomic line data
>> > provided by NIST.  When you request the line wavelength data in
>> > angstroms, NIST very helpfully labels the columns with the angstrom
>> > symbol (?), which is not strictly part of the ASCII character set.
>> >
>> > We can read these tables with Table.read() *and* the environment
>> > variable LANG=en_US.utf-8 set.  However, if LANG is not set,
>> > Table.read() fails to decode these files.
>> >
>> > As far as I can tell the underlying read() function in astropy.io.ascii
>> > does not accept keywords related to the file encoding.
>> >
>> > So two questions:
>> >
>> > 1. Is the lack of an encoding keyword a bug that should be reported?
>> >
>> > 2. Is there a workaround that does not rely on LANG being set?
>>
>> A workaround that would at least get you away without manipulating the
>> environment outside Python would be
>>
>> import locale
>> locale.setlocale(locale.LC_ALL, str(?en_US.utf8?))
>>
>
> You can make this a little cleaner using the set_locale context manager in
> astropy:
>
> from astropy.utils.misc import set_locale
> with set_locale('en_US.utf8'):
>     dat = Table.read(...)
>
> As to the original question of whether this should be reported as a bug,
> it has already been discussed in:
>
>  https://github.com/astropy/astropy/issues/3826
>
> That discussion ended without any really clear consensus except that using
> Python 3 is a good thing if that is an option.  I have never seriously
> evaluated how difficult it would be to implement support for unicode inputs
> for Python 2.  A basic recipe is shown in the stdlib csv package
> documentation, but I don't know how messy a fully working implementation
> would get.
>
> Cheers,
> Tom A
>
>
>>
>> Cheers,
>>                                         Derek
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161024/805a2331/attachment.html>

From phibon at eso.org  Tue Oct 25 09:31:09 2016
From: phibon at eso.org (Pascale Hibon)
Date: Tue, 25 Oct 2016 13:31:09 +0000
Subject: [AstroPy] zhtools / pywavelet
Message-ID: <8936F551-1439-4506-8CAE-D5EE70BEEE24@eso.org>

Dear all,

I would like to use the pywavelet package to run a ?a trous? wavelet decomposition on an image.
There is a function called wvdecomp in the zhtools package (not a python package) which does it. But I would like to find the equivalent in python.
After reading some documentations, it seems that the pywavelet swt2 function could be used but a wavelet family need to be selected.
I was wondering if some of you have some experiences with pywavelet and have recommendation on how to use a ?a trous? wavelet decomposition with python.

Thank you for your help.

Best Regards,

Pascale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20161025/488d3473/attachment.html>

From Christoph.Deil at mpi-hd.mpg.de  Tue Oct 25 10:03:25 2016
From: Christoph.Deil at mpi-hd.mpg.de (Christoph Deil)
Date: Tue, 25 Oct 2016 16:03:25 +0200
Subject: [AstroPy] zhtools / pywavelet
In-Reply-To: <8936F551-1439-4506-8CAE-D5EE70BEEE24@eso.org>
References: <8936F551-1439-4506-8CAE-D5EE70BEEE24@eso.org>
Message-ID: <23B263EA-7585-4DA8-9B63-56179F9E13F7@mpi-hd.mpg.de>


> On 25 Oct 2016, at 15:31, Pascale Hibon <phibon at eso.org> wrote:
> 
> Dear all, 
> 
> I would like to use the pywavelet package to run a ?a trous? wavelet decomposition on an image.
> There is a function called wvdecomp in the zhtools package (not a python package) which does it. But I would like to find the equivalent in python.
> After reading some documentations, it seems that the pywavelet swt2 function could be used but a wavelet family need to be selected. 
> I was wondering if some of you have some experiences with pywavelet and have recommendation on how to use a ?a trous? wavelet decomposition with python.
> 
> Thank you for your help.
> 
> Best Regards, 
> 
> Pascale 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

Hi Pascale,

I?ve used ?a trous? from  https://github.com/abrazhe/image-funcut <https://github.com/abrazhe/image-funcut> a few years ago.
Don?t remember much about how it works or compares to pywavelet swt2, or if it?s maintained.

But I thought I?d mention it as another option you can look at.

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

From pae9 at leicester.ac.uk  Thu Oct  6 11:07:50 2016
From: pae9 at leicester.ac.uk (Phil Evans)
Date: Thu, 06 Oct 2016 15:07:50 -0000
Subject: [AstroPy] astropy/wcsaxes issue with regions that "wrap"
Message-ID: <c921e5f4-5cb5-bdc3-7c5a-fd2920393960@leicester.ac.uk>

HI all,

I have a plotting issue with astropy/wcsaxes.

I'm plotting a FITS image (aitoff projection), and then overlaying a ds9 
region file via pyregion. This all works fine, unless the region file 
happens to "wrap around" the axes. If this happens, the "filled" parts 
of the region are not those that lie inside the circle, instead they are 
those that lie outside the circle (in RA),

For example, in the first image attached, the region is a circle, radius 
46 degrees, centred on (29,11).
In the second image I've shifted it to (45,11), and again you can see 
the issue. If the "right hand end" of the circle wraps around the edger 
of the projection, the plotter is incorrectly choosing which points are 
inside and outside the circle.

A stripped down version of the python script is below. I'm using 
astropy1.2.1, wcsaxes 0.9 (i.e. latest versions from pip), and python 
2.7.2. Am I doing somethng wrong, or is this a bug in 
astropy/wcsaxes/matplotlib?

Thanks!

Phil

P.S. I realise that there is a "fix" which is to choose my origin such 
that no regions wrap, but that is not going to be appropriate, or 
necessarily even possible.




infile=args[0];
outStem=args[1]
hdu=fits.open(infile)[0]
wcs=WCS(hdu.header)

fig=plt.figure()
ax = WCSAxes(fig, [0.0, 0.0, 1.0, 1.0], wcs=wcs)

fig.add_axes(ax)
image=hdu.data
image[image<1e-6]=0
ax.imshow(image, cmap='gray_r', origin='lower', alpha=1.0, 
norm=LogNorm(vmin=1e-6, clip=False))

lon=ax.coords['RA']
lat=ax.coords['Dec']

lon.set_major_formatter('hh:mm:ss')
lon.set_ticks(values=[0,30,60,90,120,150,180,210,240,270,300,330,360]*u.degree, 
exclude_overlapping=False)
lat.set_ticks(spacing=30.0*u.degree)
lon.grid(color='black', alpha=1.0, linestyle='solid')
lat.grid(color='black', alpha=1.0, linestyle='solid')

r=pyregion.open(sunFile)
p, text_list = r.get_mpl_patches_texts()
p[0].set_facecolor('#CCCC00')
p[0].set_edgecolor('#CCCC00')
p[0].set_alpha(0.5)
p[0].set_transform(ax.get_transform('fk5'))
ax.add_patch(p[0])
plt.saveFig(outStem+".png", dpi=244)





-- 
-------------------------

Phil Evans,
Swift Development Scientist
X-ray and Observational Astronomy Group,
University of Leicester

Tel: +44 (0)116 252 5059
Mobile: +44 (0)7780 980240 (work)
Mobile: +44 (0)7974 977723 (personal)

pae9 at leicester.ac.uk

http://www.star.le.ac.uk/~pae9
http://www.swift.ac.uk

Follow me as a Swift scientist on Twitter: @swift_phil
http://www.star.le.ac.uk/~pae9/twitter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: badplot_1.png
Type: image/png
Size: 427367 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20161006/1946db97/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: badplot_2.png
Type: image/png
Size: 456809 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20161006/1946db97/attachment-0001.png>