C++ versus Python wcs2kml code

[Chris]

Question: What is the difference between the C++ and Python wcs2kml
code? Is the warping algorithm the same?

Chris

[Jeremy Brewer]

The Python version was basically the prototype of the C++ version
(technically a cleaned up prototype). The warping algorithms are (or
should be) identical, but there are some bug fixes that never got back-
ported to the Python code base and some other differences, namely:

- images that straddle the poles will not project properly in the
Python version (I will probably fix this tomorrow)
- images that have the same dimensions won't have the max_tile_size
set properly (there should be a '>=' instead of a '>' somewhere, also
to be fixed)
- my WCS code only handles J2000 TAN and TAN-SIPS projections (C++
version uses WCS Tools)
- Python version supports more than PNG and will auto-convert FITS
images for you
- Python version has had much less testing done on it
- C++ version is order of magnitude faster since there's no way to
vectorize the warping code
- probably other minor things I've probably forgotten

Jeremy

[Chris]

Will the Python code be maintained? Are there plans to integrate the
versions, say by wrapping the C++ code with a Python interface?

[Jeremy Brewer]

I don't have any plans to merge the two versions. Initially I
considered writing a C extension to perform the warping, but I decided
that it would be easier to just write it in C++ instead. As far as
maintenance, there's not much the Python version needs except for
speed.

Of course, if people step up and want to code a Python C extension
that handles the warping and bounding box calculations using wcstools,
I certainly won't object.

Jeremy

[Christopher Hanley]

I will look into it. A Python C extension would be easier to
distribute for the platforms I'm interested in supporting.

[Jeremy Brewer]

If you go the extension route you should probably look at SWIG and
boost since my code is C++ (I've only ever written C extensions
against the Python API, so I can't speak to their pros & cons). I
think the main thing to figure out would be how to replace my PngImage
class with an interface to PIL -- maybe you could try writing an Image
class that implements a the same API as PngImage but which calls the
appropriate PIL pixel access routines. Also, you should note that I
assume 8 bits per channel in a lot of places since I explicitly make
libpng convert to this on read.

I also forgot one major feature the Python version lacks, namely
regionation (or "super sky overlays" as it should probably be
called).

Jeremy