Now that we have the collection "export" concept, the tiler can work
with ImageCollections rather than its own lists of FITS paths and HDU
indices. This positions us to use a much more object-oriented approach
where the tiler maintains more state and provides a more streamlined API
to callers.
Once that's done, the toplevel `toasty.tile_fits` function can become a
lot simpler.
These provide a simple, uniform interface for creating an
ImageCollection, in analogy to the ImageLoader and Image interfaces. The
load() function provides a "just do what I want" interface intended for
interactive and scripting usage.
In an ideal world, we'd just automatically detect AVM and Do The Right
Thing, but not a lot of people are necessarily going to have pyavm
installed and we don't necessarily want to require it.
Part of this is making the decision to just unilaterally invert the
parity of the WCS that pyavm hands us based on the AVM data. From the
files that I've seen in the wild, this looks to be the correct thing to
do.
Haven't touched this code in a while, but WWT can now display tiled FITS
so we're about to use it a lot more! The new code has to be careful
about the parities of FITS vs. tilings but I believe that we're doing
that all correctly now. We now also emit WTML using the standard
framework and otherwise modernize this code.
No parallel implementation yet, just trying to tidy up the serial
approach first.
To render tiled FITS, things are a bit awkward because the individual
FITS files are rendered by WWT assuming a bottoms-up (positive parity)
data layout, but the overall tiling coordinate system is still top-down.
If you work through the geometry, the cascade process can be nearly
identical for both this case and the case where the tiles are also
top-down: all you need to change is to reorder the vertical stacking in
the cascade process. So, do that. In order for this to work, we need to
add some infrastructure to "know" the expected vertical data layout of
the pyramid tiles.
We had a mechanism to have certain images be marked as ignored, but
there wasn't a way for users to do any marking! This new command can
mark all rejected images to be ignored in the future.
It turns out that the eso.org installation of Djangoplicity has some
differences from the NOIRLab one that mean that we have to add a few
more bells and whistles:
- Make TLS-no-verify optional (not strictly required, but good to do)
- The search pagination URLs are different
- Handle gzipped content from the server
We centralize the request-making code a bit to make it easier to support
all of these consistently.
Peter Williams
Henrik Norman
A. David Weigel