Level 0, Level 1, and alignment of orders have been completed but are not in final form. Level 0 is nearly complete, but lacks a flat field for m = +1, and all the flat fields are being improved. The digital filtering step at the end of Level 1 also needs review. The order alignment is not yet satisfactory, but the inconsistencies have been whittled down to sub-pixel precision.
Since provisional alignments of Level 1 data exist, it will soon be possible to begin scientific analysis.
Working on a program to make binned, full-field movies in all 3 orders: MOVIE2x2.
IDL 5.x (on Wind or Fire, for example) has at least one bug in handling format codes. This slightly complicates running MOVIE2x2 because the image filenames don't come out as anticipated. Quoting the IDL Building Applications manual:
For numeric format codes, if the first digit of the width parameter is a zero, IDL will pad the value with zeroes rather than blanks. For example
PRINT, FORMAT='(I08)', 300produces the following output:
00000300
Well, here is what really happens with our three 4-way Sun machines, each running a different version of IDL::
Fire, running IDL 5.3, Solaris (sunos sparc):
IDL> PRINT, FORMAT='(I08)', 300
300
Wind, running IDL 5.5, Solaris (sunos sparc):
IDL> PRINT, FORMAT='(I08)', 300
300
Earth, running IDL 6.2, Solaris (sunos sparc m64):
IDL> PRINT, FORMAT='(I08)', 300 00000300
First run (on Earth, since it has IDL 6.2): movie2x2.log060622.222834. Contrary the log file, it did not take 643 minutes to run! Probably 643 seconds; this is close to the difference between the filename date stamp and the file modification time. Problems with this run:
The first two are problems with MOSES_ALIGN_FINAL and its subroutines. The second two are problems in MOVIE2x2 and its subroutines.
Problems 1 and 2 are solved. movie2x2.log060623.082426. (The fix for 2 is probably not reliable because of the IDL POLY_2D bug, but I am not too concerned about this.)
Problem 3 is solved. I just subtracted 1b from the results of DISPLAYSCALE, so that 0 maps to 255. movie2x2.log060623.103142
I think I understand problem 4. Because I've replaced the saturated pixels with NaN, the median doesn't include them. So Longer exposures are missing pixels at the top end of the histogram, and the median is systematically lower. When I divide out the median, the renormalized image is therefore too bright in proportion to the number of saturated pixels. Best solution would be to use Inf instead of NaN. But that requires going through the whole darned data reduction from scratch, treating Inf (for saturated) and NaN (for missing data at the edges) differently. What to do? Idea: make a map of always-good pixels, and use the median or mean of those pixels for normalization.
Wrote RENORMALIZE to solve problem 4, and now MOVIE2x2 uses this as its normalization standard. RENORMALIZE batch job: renormalize.log060623.120839
Ran MOVIE2x2 again, movie2x2.log060623.131825. Still didn't work. I see a simpler problem now, I am running DISPLAYSCALE individually on each image (d'oh!).
Aha, problem with DISPLAYSCALE:
IDL> foo = findgen(10,20,30) IDL> help,foo FOO FLOAT = Array[10, 20, 30] IDL> help,displayscale(foo) % Compiled module: DISPLAYSCALE.BYTE = Array[10, 20]
Note, by the way, that displayscale.pro is now located in /home/kankel/idl/cck/. I am presently keeping copies both there and in /disk/data/kankel/MOSESflight/ so that docs will always mirror a current copy to the web directory. Should come up with a better system.
Problem 4 is now solved: movie2x2.log060623.142210. Scaling is a bit dark... works better if I just histogram equalize. That will do for now. Movies below.
Just wrote MOVIE_DIFF. The inter-order normalization from RENORMALIZE is evidently not good enough to make a movie of the difference between orders.
Wrote RENORMALIZE2. This is a different strategy, taking advantage of more pixels. Run log: renormalize2.log060623.170244.
Modified MOVIE2x2 and MOVIE_DIFF to use results of renormalize2. Now running MOVIE_DIFF, movie_diff.log060623.171521.
The two versions of RENORMALIZE result in identical problems: the difference images look just like negative images. Why?
I found the bug. It was not in RENORMALIZE.
had this ---> snrunk = rebin(cube_zero[*,*,0], Nx/2, Ny/2) should be ---> shrunk = rebin(cube_zero[*,*,0], Nx/2, Ny/2)
First movies in all 3 orders: m = -1, m = 0, m = +1.
I now have a good full-FOV, 2x2 binned difference movie (plus - zero). At the front and back of the movie I put extra copies of the first and last frames, with a coordinate grid superimposed. The divisions are 50 pixels in the 2x2 binned movie, corresponding to 100 pixels at native resolution, about 1 arc minute on the sky, or 43 Mm on the Sun.
Looking at the above difference movie, I saw two events that look especially interesting:
Here is an attempt at setting down the right relationship between solar directions, payload / focal plane coordinates, and increasing or decreasing wavelength due to dispersion. The following table summarizes, for each spectral order, the apparent displacement in solar coordinates associated with redshift, blueshift, focal plane y, and focal plane z.
| m = -1 | m = 0 | m = +1 | |
|---|---|---|---|
| Redshift | E | n/a | W |
| Blueshift | W | n/a | E |
| Focal plane y | W | W | W |
| Focal plane z | S | S | S |
Wrote MOVIE_DIFF_FOV. Required some bug fixes in DISPLAYSCALE.
Used MOVIE_DIFF_FOV for feature 3 from the above list. The movie has three panels (plus, minus, plus - minus). Filename indicates FOV center coordinates: feature-1690-0800.mov.
Two more 3-panel feature movies: feature-1530-0780.mov, feature-1880-0950.mov
I have redone the above feature movies with better scaling, using MOVIE_DIFF_FOV2. This is more than an updated version of MOVIE_DIFF_FOV; it also produces plots (feature*.eps) and estimates doppler shifts of features.
Today Lewis and I carefully worked through the image coordinates and dispersion directions for the MOSES data. The conclusions are OPPOSITE what I came up with on 2006-Jun-23 (see the above table for the WRONG ANSWERS!). The main point is that all the doppler shift measurements made last year for the SPD presentation and the project final report to NASA had a sign error. An independent test of this result is the Si XI feature on the SE limb. Since the Si XI line is 0.5 Angstrom shorter than the He II line, and since it has a dark-bright bipole signature in the difference movie (plus - zero), it makes sense that blue shifts are to the right (solar W) and red shifts to the left (solar E) in the m=+1 image. This had been bothering me for some time.