OK thanks. I’m interested to hear what the ds9 people have to say.
Got a response late last week from ds9 expert Bill Joye at the Chandra X-ray Center. It’s pasted below. I intend to reply and suggest they document some of this so others don’t try to do what I did and naively expect it to work. But the gist is that ds9 was never intended to handle a wide field, non-linear WCS situation well.
One takeaway I got is, updating to ds9v8 is a good idea if you want “approximately correct” astrometry for a quick look at a small portion of a focal plane!
Thanks for your patience. I’ve had time to take a look at your issue. I’ve followed the discussion on the forum you listed and downloaded your sample files. The discussions on how DS9 handles mosaics are more or less correct.
To generate a mosaic visualization, DS9 will read the first fits file, and then for each additional file, orient, scale, and rotate to match the WCS of the first file.
This functionality is only meant as a quick look capability. Back in the days when DS9 was first written, re-projection of mosaics took hours. The field of view was typically small and the WCS used were a simple linear system, such as TAN. In these cases, a simple matrix could generate a reasonable representation of the mosaic. The size or number of mosaic segments really did not matter.
In fact, most mosaics at the time did not use a WCS, but instead used IRAF DETSEC, DETSIZE keywords to define a simple linear system. (and we will not talk about WFPC2
In your case, you have a very wide field of view and a non-linear instrument projection plane. Re-projection is the best method to properly visualize your data.
Aside, up until version 7.6, the DS9 code tried to create a simple matrix by reading the CRVAL, CRPIX, CD, CDELT, and CROT keywords directly from the headers. Now, version 8.0 uses AST’s support to build a proper mapping between 2 defined WCS. Hence, the scrambled mess of version 7.6 vs the more or less correct placement of version 8.0.
Down the road DS9 might support some form of re-projection directly, but thats another major research endeavor.
3 Likes
One final comment from Bill Joye. They’re going to explore on-the-fly reprojections for future ds9 releases for rendering mosaics thanks to this discussion, so thank you, all!
Just to followup up on the discussion. One item I did not truly appreciate is the fact that LSST is using a non-linear WCS for each chip, valid for only that chip. Up until now, all mosaics data products from other projects used a linear WCS, which was valid for all of the chips. (actually, there is a WCS defined per chip, but the WCS was linear and superimposed nicely on top of the other WCSs)
Unique to your case at LSST, now you have a non-linear WCS per chip, and very important, that WCS is only valid for that chip, as the WCS solution falls apart as you leave the chip. Therefore, the strategy used by DS9 for rendering the mosaic no longer is valid.
For the next major release of DS9, I will explore the possibility of “on the fly re-projection” for rendering mosaics, as I’m sure LSST will not be the last project to take this approach.
2 Likes
Thanks for following up on this.
It might be worth letting them know that any large (tens to hundreds of chips) mosaic camera is going to have the same problems (non linear WCS for every chip outside the middle), because of optical distortions. For example, the same is true for the DECam astrometry solution of Bernstein et al.