FITS image manipulation

[Adam Ginsburg]

I find myself needing FITS image manipulation routines frequently in
my daily work, e.g. reprojection (which is in part addressed by
montage) and resampling. I've written some convenience routines for
these tasks and incorporated them into some of my own packages, e.g.:
https://github.com/keflavich/image_registration/blob/master/image_registration/FITS_tools/hcongrid.py
http://image-registration.readthedocs.org/en/latest/image_registration.FITS_tools.html#image_registration.FITS_tools.hcongrid

In short, these are routines that perform basic image manipulation
while correctly tracking the appropriate header changes. hcongrid &
montage have a lot of overlap in their capabilities and uses, but
hcongrid allows for interpolation while montage (afaik) does not.

Should these go somewhere in astropy? Or perhaps FITS image
manipulation routines deserve their own affiliated package?

I asked this question of Erik B. and he pointed out that this sort of
thing should be handled by the "generalized wcs" at some point in the
future, but as far as I know these very basic routines don't exist
now. If they're hiding somewhere, I'd really like to know.


P.S. Can we include
http://image-registration.readthedocs.org/en/latest/ as an
astropy-affiliate? Should that go into its own thread?

Thanks,
--
Adam Ginsburg
Fellow, European Southern Observatory
http://www.adamgginsburg.com/

[Erik Bray]

On Wed, Dec 11, 2013 at 12:55 PM, Adam Ginsburg
<adam.g....@gmail.com> wrote:
> I find myself needing FITS image manipulation routines frequently in
> my daily work, e.g. reprojection (which is in part addressed by
> montage) and resampling. I've written some convenience routines for
> these tasks and incorporated them into some of my own packages, e.g.:
> https://github.com/keflavich/image_registration/blob/master/image_registration/FITS_tools/hcongrid.py
> http://image-registration.readthedocs.org/en/latest/image_registration.FITS_tools.html#image_registration.FITS_tools.hcongrid
>
> In short, these are routines that perform basic image manipulation
> while correctly tracking the appropriate header changes. hcongrid &
> montage have a lot of overlap in their capabilities and uses, but
> hcongrid allows for interpolation while montage (afaik) does not.
>
> Should these go somewhere in astropy? Or perhaps FITS image
> manipulation routines deserve their own affiliated package?
>
> I asked this question of Erik B. and he pointed out that this sort of
> thing should be handled by the "generalized wcs" at some point in the
> future, but as far as I know these very basic routines don't exist
> now. If they're hiding somewhere, I'd really like to know.

To clarify, I don't really know if these routines would fall under
generalized WCS or not. More generally I would want to shy away from
any image manipulation routines that are in any way directly tied to
FITS images, since it makes them unusable for any data that isn't
being directly serialized to/from FITS.

[Wolfgang Kerzendorf]

I think this makes a great affiliated package and I would use it. Maybe some of this functionality will one day be in astropy - until then I think affiliated package is the right way to go.

Cheers,
Wolfgang

> --
> You received this message because you are subscribed to the Google Groups "astropy-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[James Turner]

> I think this makes a great affiliated package and I would use it. Maybe some of this functionality will one day be in astropy - until then I think affiliated package is the right way to go.

I suppose the kind of direction we're eventually headed in would
be a package that wraps ndimage (or whatever), accepting nddata
instances and doing all the right things with the WCS etc.? Or
more likely something that does slightly higher-level operations
than ndimage, eg. "resample this nddata's co-ordinates to that
one's".

I have some code that does this kind of thing for datacubes but
it uses my own data access class (experiment from ~2006) that
would need replacing with nddata & generalized WCS at some point
to handle more than IFU data via affine transforms (in the
meantime I'll make it more public when I'm finished with some
changes).

Cheers,

James.

[Erik Bray]

On Wed, Dec 11, 2013 at 3:02 PM, James Turner <jtu...@gemini.edu> wrote:
>> I think this makes a great affiliated package and I would use it. Maybe
>> some of this functionality will one day be in astropy - until then I think
>> affiliated package is the right way to go.
>
>
> I suppose the kind of direction we're eventually headed in would
> be a package that wraps ndimage (or whatever), accepting nddata
> instances and doing all the right things with the WCS etc.? Or
> more likely something that does slightly higher-level operations
> than ndimage, eg. "resample this nddata's co-ordinates to that
> one's".

That is the general idea. Just as we currently register Table
readers/writers for different file formats, there is a goal to do the
same for NDData (or even more specialized "subclasses" of NDData like
Image and Spectrum types). I don't know exactly how this would work,
but readers and writers for FITS images would have to know how to
recognize a FITS WCS, read that into the generalized WCS framework,
and write the correct values (or at least an approximation thereof) to
FITS WCS upon serialization back to FITS.

I have no idea how long it will be before such a framework is fully
usable but if I understand correctly that has been a goal all along.

[Steve Crawford]

There is also the planned ccdproc package that was started and has currently stalled out.   I was hoping/planning on adding this as an affiliated package, but I was hoping to first get it to the point where it had a good deal of the functionality before doing so.   However, I have made available what I have done so far here (which is very little):
https://github.com/crawfordsm/ccdproc/tree/master/ccdproc

Also see this pull request to the API:
https://github.com/astropy/astropy-api/pull/8

However, if this might be the right place for further image manipulation packages, I would be happy to at least clean up what I have right now so as to make it usable and to have this added as an affiliated package.

[Adam Ginsburg]

Steve - I think ccdproc and "FITS_tools" are complementary. CCDPROC
should still be made as its own affiliated package.

My view of FITS_tools - which I've now created from the astropy
affiliated package template: https://github.com/keflavich/fits_tools -
is that it should include only basic, fairly low-level wrappers of
image manipulation routines such as image reprojections and
interpolation. At the moment, the only things I've implemented are
wrappers of (wrappers of...) Montage and some simple interpolation
routines. The only difference between this package and python-montage
is that it includes some capability to interpolate while resampling.

pyAst apparently has a lot of the capabilities that one might want for
image manipulation, so those functions could be include as long as
they're wrapper to deal specifically with FITS images.

[Adam Ginsburg]

I renamed the repository to https://github.com/keflavich/FITS_tools in
case anyone goes looking (just changed the case).

But on a related note, is there presently any way to find the
transformation between two arbitrary WCS? i.e., given an image with
Galactic WCS, to find the coordinates of each pixel in RA/Dec? I know
this is intended to be a function of the "generalized wcs" at some
point, but does anything exist to do that right now? It could be done
by going through astropy.coordinates as an intermediate step, I think,
but that is likely to be slow and difficult.

[David Berry]

On 12 December 2013 09:49, Adam Ginsburg <adam.g....@gmail.com> wrote:
> I renamed the repository to https://github.com/keflavich/FITS_tools in
> case anyone goes looking (just changed the case).
>
> But on a related note, is there presently any way to find the
> transformation between two arbitrary WCS? i.e., given an image with
> Galactic WCS, to find the coordinates of each pixel in RA/Dec? I know
> this is intended to be a function of the "generalized wcs" at some
> point, but does anything exist to do that right now? It could be done
> by going through astropy.coordinates as an intermediate step, I think,
> but that is likely to be slow and difficult.

pyast can do it as shown in https://gist.github.com/dsberry/7916799 -
the magic all happens in the "convert" method of the Frame class.

David

[Christoph Deil]

On 12 Dec 2013, at 10:35, Adam Ginsburg <adam.g....@gmail.com> wrote:

> Steve - I think ccdproc and "FITS_tools" are complementary. CCDPROC
> should still be made as its own affiliated package.
>
> My view of FITS_tools - which I've now created from the astropy
> affiliated package template: https://github.com/keflavich/fits_tools -
> is that it should include only basic, fairly low-level wrappers of
> image manipulation routines such as image reprojections and
> interpolation. At the moment, the only things I've implemented are
> wrappers of (wrappers of...) Montage and some simple interpolation
> routines. The only difference between this package and python-montage
> is that it includes some capability to interpolate while resampling.

Hi Adam,

In Kapteyn there’s also a nice reprojection method (BSD license, OK to take for astropy or affiliated packages):
http://www.astro.rug.nl/software/kapteyn/maputils.html#maputils.FITSimage.reproject_to
I briefly looked at it and your method, both seem very similar (both based on scipy.ndimage.map_coordinates).

Tom Robitaille has started https://github.com/astrofrog/python-reprojection/, which I think should end up in astropy or an affiliated package as well.

I’ve also written a few image manipulation functions, some of which are listed here: https://gammapy.readthedocs.org/en/latest/image/index.html

Maybe we can discuss how to proceed with these tools at the developer hangout tomorrow?

A general comment: wouldn’t it be better for us to contribute most image manipulation functionality to scikit-image (http://scikit-image.org) and only put astronomy-specific things (like reprojection that needs WCS) in astropy or affiliated packages?
E.g. I guess they would accept your image registration code (as long as it doesn’t need WCS info):
http://scikit-image.org/docs/dev/auto_examples/plot_template.html#example-plot-template-py
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/fm/10001
If it’s just about transforming pixel to world coordinates for the input or output there could always be a WCS-aware wrapper around that image processing function in astropy or an affiliated package?

Christoph

[Christoph Deil]

On 12 Dec 2013, at 10:49, Adam Ginsburg <adam.g....@gmail.com> wrote:

I renamed the repository to https://github.com/keflavich/FITS_tools in
case anyone goes looking (just changed the case).

But on a related note, is there presently any way to find the
transformation between two arbitrary WCS?  i.e., given an image with
Galactic WCS, to find the coordinates of each pixel in RA/Dec?  I know
this is intended to be a function of the "generalized wcs" at some
point, but does anything exist to do that right now?  It could be done
by going through astropy.coordinates as an intermediate step, I think,
but that is likely to be slow and difficult.

I’ve written these utility functions, but it would be really nice if such things became easily available in astropy core soon:

https://gammapy.readthedocs.org/en/latest/_modules/gammapy/image/utils.html#coordinates

https://gammapy.readthedocs.org/en/latest/_modules/gammapy/utils/coordinates/celestial.html#sky_to_sky

But in any case such a function would use `astropy.coordinates`, I think.

Should it be slow or difficult now in should be improved there instead of duplicating coordinate conversion functionality elsewhere, no?

Christoph

[Adam Ginsburg]

Re: AST - I'd like to use it if I can figure it out. The example will
help. It's nice that the reprojection is happening at a C-level (I
think).

Thanks for pointing me to python_reprojection; it's really what I'm
looking for so I'll try to contribute.

But re:scikit-image - I don't think it's really an appropriate place
for anything I've written. Certainly FITS tools is already just a
light wrapper around scipy functions that keep track of FITS header /
wcs information. You're right, though, the fundamental algorithm in
image_registration could fit into scikit-image.

I agree that those gammapy utils should be in astropy-core. Is there
an outstanding PR for those?

[Christoph Deil]

On 12 Dec 2013, at 12:15, Adam Ginsburg <adam.g....@gmail.com> wrote:

> Re: AST - I'd like to use it if I can figure it out. The example will
> help. It's nice that the reprojection is happening at a C-level (I
> think).
>
> Thanks for pointing me to python_reprojection; it's really what I'm
> looking for so I'll try to contribute.
>
> But re:scikit-image - I don't think it's really an appropriate place
> for anything I've written. Certainly FITS tools is already just a
> light wrapper around scipy functions that keep track of FITS header /
> wcs information. You're right, though, the fundamental algorithm in
> image_registration could fit into scikit-image.

That’s what I meant.
Put such non-trivial image processing algorithms that only work on pixels and will probably be useful to non-astronomers in scikit-image.

Another example: a while back I asked about Richardson-Lucy deconvolution and wanted to implement it myself, but then someone else implemented it in scikit-image and started a `restoration` module:
https://github.com/scikit-image/scikit-image/pull/800
I think this would also be the right place to add other deconvolution methods that are commonly used in astronomy, e.g. I plan to clean up and add this one when I find some time:
https://gammapy.readthedocs.org/en/latest/api/gammapy.detect.cwt.CWT.html

>
> I agree that those gammapy utils should be in astropy-core. Is there
> an outstanding PR for those?

No, but this is a bit related:
https://github.com/astropy/astropy/issues/619

I think what is needed before we can start adding such functionality to astropy core is some guidance where it fits in.

Should we start writing utility functions that take `astropy.io.fits.ImageHDU` objects or `numpy.array` and `astropy.io.fits.Header` objects as inputs?

Or will classes like `NDData` be extended or new “generalised WCS” classes added soon that would be the appropriate place for such functionality?

[James Turner]

> A general comment: wouldn�t it be better for us to contribute most image manipulation functionality to scikit-image (http://scikit-image.org) and only put astronomy-specific things (like reprojection that needs WCS) in astropy or affiliated packages?

Isn't the question really whether people want to make scikits-image
(and therefore SciPy) a dependency or not? I believe it was decided
early on not to require SciPy. However, I do think there's a lot of
room for interaction between AstroPy and Scikit-image and it would
be good to figure out how to facilitate that.

Cheers,

James.

[Erik Tollerud]

That's right, we definitely can't make scipy and/or Scikit-image a
"hard" dependency, but it can be "soft", meaning not needed to
import/do basic stuff, but necessary for specific classes or
functions. Some of the current functionality fails (at run-time,
*not* import-time) if scipy is not present. So it would be acceptable
to do a similar thing with Scikit-image (as long as there's a very
prominent message about the dependency in the docs)... But that *is* a
significant cost to users. If it's instead in the astropy core, it
will be version-tied to Astropy, will be documented in the same way as
astropy, and more "discoverable" for our users.

Furthermore I disagree that it's as simple as "algorithms that only
work on pixels and will probably be useful to non-astronomers". Some
algorithms astronomers use are of general use, *but* certain
conventions are specific to astronomers. For example, this is why we
have a custom "sigma_clip" in scipy.stats: the sigma-clipping function
in scipy just didn't do all of the things some astronomers need.

So I think it's just a case-by-case question. As a random example, a
Radon Transform is indeed useful to lots of people, and doesn't really
have astronomy-specific quirks. And it's also not *too* commonly used
in astronomy, so contributing that to scikit-image and then using it
in an Astropy function would be reasonable. But, say, implementing
DAOPHOT's star-finding algorithms is something that belongs in
Astropy, not scikit-image, because it's really of specific use to
astronomers and not terribly generalizable. For everything in
between, I think there isn't a clear and definite answer.


On the original topic, I agree with what Erik B was saying: the
"ideal" is to have all this in NDData and generalized WCS classes, and
have them transparently update headers and such. But that's still got
quite a bit of development before its a reality, so I think
`FITS_tools` as an affiliated package is a great idea as a "stopgap"
way to just get stuff down now. Hopefully, after some use, it will
also help inform the API plans for NDData and gWCS.

And Adam, feel free to go ahead and create a PR on the
astropy.github.com repo to add it as an affiliated package. Further
discussion on the specifics of that can happen in the PR comments.



On Thu, Dec 12, 2013 at 9:19 AM, James Turner <jtu...@gemini.edu> wrote:
>> A general comment: wouldn’t it be better for us to contribute most image

Erik