New web service & code update

[Crossley Jared]

Hello,

Two of us at the National Radio Astronomy Observatory are using
wcs2kml to perform web-based automated image importing into Google
Earth's Sky. Our service, "KML Now!", provides an interface to Simple
Image Access (SIA) servers that conform to the standards of the
International Virtual Observatory Alliance.

In a nutshell, KML Now lets the user search available SIA servers for
images at some location on the sky. Our service downloads the images,
converts them using wcs2kml and sends the user a KML document. The
warped PNG is cached on the server side.

You can try KML Now for yourself by going here:

go.nrao.edu/kmlnow

I also have a code change I would like to commit. I've modified
wcsprojection.cc to make the WCS conversion work with common radio
image data. Previously, wcs2kml would abort if it found more than 2
axes in the FITS header. My change allows more than 2 axes under the
condition that axes 3 and above are degenerate (the array length is
1). For radio images, it is common to store polarization and
frequency information in axes 3 and 4. If the image is total
intensity and continuum (one polarization plane and one frequency
plane), axes 3 and 4 still exist but are degenerate.

I can either email you the updated file, or you can add me as a member
of the wcs2kml Google Code project.

Jared Crossley (and Ron DuPlain)

[Jeremy]

Hi Jared,

Thanks for the info about the service and the radio imagery fix (I
only ever worked with optical imagery, so any radio keyword FITS help
is much appreciated). One question - are you using a tarball version
or the version from the SVN repository? I ask because I altered the
behavior of wcs2kml for CDELT3 and CDELT4 keywords because I
discovered that I erroneously assigned some bad behavior to them
previously, but this change isn't present in the tarball version.

Also, can you explain why you check for degeneracy in axes 3 and 4?
Is there a standard for what values are allowed there? We really only
care about checking for keyword errors that will cause the WCS library
to give bad transformations.

You can grab the SVN version at:

http://code.google.com/p/wcs2kml/source/checkout

You can try integrating your changes into the SVN version of the code
or just leave it up to me if you like. You can either email me your
change or post the altered files using the Google Groups files option.

Again, thanks for contributing.

Jeremy

[Crossley Jared]

Jeremy,

On Feb 12, 2009, at 5:41 PM, Jeremy wrote:
> Hi Jared,
>
> Thanks for the info about the service and the radio imagery fix (I
> only ever worked with optical imagery, so any radio keyword FITS help
> is much appreciated). One question - are you using a tarball version
> or the version from the SVN repository?

I was using the tarball version, or perhaps an old version from the
repository. I've checked out the new svn version. I see that it does
convert radio FITS data without any of my changes! This is good.

I diff-ed my wcsprojection.cc with the new file in svn. I see that
you removed the same lines of code that I also removed. Formerly,
there was some code that disallowed FITS keywords pertaining to the
3rd axis (i.e. CDELT3). After I removed that bit of code I added a
check that axes 3 and greater are degenerate.

> I ask because I altered the
> behavior of wcs2kml for CDELT3 and CDELT4 keywords because I
> discovered that I erroneously assigned some bad behavior to them
> previously, but this change isn't present in the tarball version.
>
> Also, can you explain why you check for degeneracy in axes 3 and 4?
> Is there a standard for what values are allowed there? We really only
> care about checking for keyword errors that will cause the WCS library
> to give bad transformations.

If axes 3 and 4 are not degenerate then there are multiple image
planes in the file. For example, some FITS files hold separate images
for each type of polarization or for each channel observed. You can
tell what the dimensions of the data are by looking at the NAXIS1,
NAXIS2, etc. keywords.

But you're right: this is irrelevant to the WCS transform. Thanks for
pointing this out! Actually, this is more relevant to the generation
of the PNG image. But that's not a concern for wcs2kml -- it assumes
the user already has a good PNG.

So, I'll retract my suggested code change.

For completeness, here's my thinking about the FITS -> PNG conversion:

In the FITS -> PNG conversion code, axes 3 and above are relevant. If
there are multiple image planes, we must decide how these will be
handled. Should all planes be added together in some fashion, or
should every plane generate a new PNG image?

For our Web service (KML Now) we use STIFF (link below), which has
proved to be an easy-to-use and rather robust program for converting
FITS to TIFF. ImageMagick then does the simple TIFF->PNG conversion.
(Initially we tried to use the python conversion script packaged with
wcs2kml, but it did not always work -- may have been confused by the
different keywords present in the radio FITS data.)

To be honest, I don't know how STIFF deals with multiple image planes,
but it does convert them to a single TIFF; and the TIFF appears
roughly accurate. The STIFF documentation does not explain this
detail, and I haven't yet bothered to dig into the code. STIFF may
simply take the 1st image plane and ignored the rest.

For our Web service we've decided not too worry about maximizing the
scientific return. We just want to keep things simple so amateur
astronomers can use the program. So, as long as a reasonably good
image comes out, we're happy. I may return to this issue some day and
try to properly handle all images planes. But for now, I think we'll
leave it as is.

Thanks for the insight! wcs2kml is a neat package.

-Jared Crossley


STIFF: http://terapix.iap.fr/rubrique.php?id_rubrique=178

[Jeremy Brewer]

I was using the tarball version, or perhaps an old version from the
repository.  I've checked out the new svn version.  I see that it does
convert radio FITS data without any of my changes!  This is good.

It sounds like I need to make a new tarball release soon... 

 

For completeness, here's my thinking about the FITS -> PNG conversion:

In the FITS -> PNG conversion code, axes 3 and above are relevant.  If
there are multiple image planes, we must decide how these will be
handled.  Should all planes be added together in some fashion, or
should every plane generate a new PNG image?

With multiple image planes, it's basically impossible to do "the right thing" in every case.  Presumably these multiple planes are from different filters, so you want to create some RGB images by assigning an RGB value to each image and adding them somehow.  But your suggestion of just outputting multiple gray scale PNGs is probably the best thing to do.
 

For our Web service (KML Now) we use STIFF (link below), which has
proved to be an easy-to-use and rather robust program for converting
FITS to TIFF.  ImageMagick then does the simple TIFF->PNG conversion.
(Initially we tried to use the python conversion script packaged with
wcs2kml, but it did not always work -- may have been confused by the
different keywords present in the radio FITS data.)

I'm not surprised the Python script gave you errors - ever since I "upgraded" from Numeric to numpy I keep finding weird behavior and bugs (if you check the SVN log you'll find many little commits related to numpy/PIL).  I'm going to move pretty much all of the Python code to C++ if I get a chance.

I had no idea that Bertin wrote a FITS to TIFF converter.  Thanks for pointing this out - I'll definitely mention his package in my README.  My code grew out of a webservice I wrote that needed to show FITS files after some processing, and I ended up reading the DS9 code to figure out how their 'zscale' option works.  Later I added some other processing options.  I glanced Bertin's code, and he has several ways of performing FITS to 8-bit image conversion that look like I should at least be aware of.  The manual also looks like a valuable source of information since he's appears to have put a lot more effort into his code than I ever did.

Jeremy