Sky Coyote, 28 Mar 2007

This month I've been working on the Mercator projection changes to FITSMap and FITSFlow. This has turned out to be a more complicated process than one would initially imagine. I've added support for multiple {x, y} <--> {lat, lon} projections, and a help image describing each projection:

Here is the full image for the Mercator projection, which is a combination of stuff from the USGS and Wikipedia sites:

Here are the actual functions that map y --> lat (top) and lat --> y (bottom). Note that in addition to these, the results must be scaled for the desired latMin and latMax:

To test the projection, I used an image from Blue Marble:

The simple cylindrical projection worked OK, but the Mercator projection gave latitudes that were not correct (e.g. northern Florida at 40 deg N):

I thought that Eliot's disk to cylinder routines might not be working properly, so I wrote my own based on a different approach, but got exactly the same results. I then tried another image of Earth, as seen from the Sun, which did give the correct projected latitudes. Apparently the Blue Marble image is not from a high enough altitude:

Here are two composite Venus images using the Mercator projection:

FITSMap saves the projection parameters in the header of the output map file. These parameters are then read by FITSFlow in order to generate the lat/lon grid and compensate for the nonlinear projection. Here is a flow generated from these images, displayed using constant vector length, but still no compensation for the projection:

Here is a comparison of the uncompensated flow (left) and the flow compensated for vector magnitudes (right):

To perform the compensation, vectors at high/low latitudes have their lengths shortened based on the increasing area of the projection at that latitude. Specifically, their lengths are divided by the derivative of the lat --> y curve shown above, at their latitude, and then multiplied by the derivative of the lat --> y curve for lat = 0, so that all lengths are normalized to those at the equator. Note that this process must be performed after cross-correlation, but before any iterations are performed on the flow, as the distortion in vector lengths will affect the iteration calculations. Thus, projection compensation cannot be performed simply as a post-processing step, but must be an integral part of the FITSFlow program

In addition to shortening vectors at high/low latitudes, the area of each domain and range used to calculate the initial cross-correlation must also be adjusted prior to flow estimation, in order to compensate for the difference in areas at different latitudes. This results in domain and range sizes increasing away from the equator:

This increase in domain/range size away from the equator significantly slows down the program. To compensate for this, a smaller equatorial domain and range size can be selected, although this affects the size of cloud features detected:

I am currently working on performing the flow calculations using degrees of lat/lon, rather than pixels. This results in a constant number of flow vectors per lat/lon area, rather than an increasing flow density away from the equator (and speeds up the program). However, this is tricky, since it affects all the iteration calculations and the post processing by virtue of changing neighborhood size. I am now working on a way to generalize the concept of distance between any two flow elements, so that either pixels or degrees can be used:

I expect to have updates of both FITSMap and FITSFlow available this weekend.

İSky Coyote 2007