Transform master_finders delta coordinates.

[acviana]

The coordinates stored in the master_finders table are actually delta coordinates. They are the x and y separation in units of pixel from the ra_targ and dec_targ header keywords in the single_sci.fits files and the ra and dec of the ephemerides given by the JPL Horizons system.

The physical location of the ephemerides can be determined from 6 different header keywords.

Keyword	Meaning
CRVAL1	RA of reference pixel (deg)
CRVAL2	Dec of reference pixel (deg)
CRPIX1	X coordinate of reference pixel
CRPIX2	Y coordinate of reference pixel
RA_TARG	Right ascension of the target (deg) (J2000)
DEC_TARG	Declination of the target (deg) (J2000)

The deltas we don't are between crval1 and ra_targ and crval2 and dec_targ. We can calculate this using the existing class in coords.py. This will allow us to find detector pixel positions for the objects and their ephemerides. I think this should be stored as two new rows in the master_finders table for ease of inspection: chip_x and chip_y.

The final step is to transform those positions from the pixel positions on the detector into pixel positions in the master png images and finally the png subimages.

In terms of understanding the pointing errors the HST WFPC2 Handbook says:

The absolute accuracy of the positions obtained from WFPC2 images is typically 0."5 rms in each coordinate and is limited primarily by the accuracy of the guide star positions.

This isn't 100% relevant to this ticket, thought it will be useful in assessing the accuracy of our results and should be eventually included in the wiki's or papers.

References: http://www.stsci.edu/instruments/wfpc2/Wfpc2_dhb/WFPC2_longdhb.pdf

[acviana]

I added new columns to the master_finders table with the following commands:

ALTER TABLE mtpipeline.master_finders ADD COLUMN ephem_x int(11) DEFAULT NULL;
ALTER TABLE mtpipeline.master_finders ADD COLUMN ephem_y int(11) DEFAULT NULL;

[acviana]

This is the table of all the values that are obtained directly from a source.

Object	Value	Unit	Source
Ref Pix	crpix1	PIX	Header
Ref Pix	crpix2	PIX	Header
Ref Pix	crval1	DEG	Header
Ref Pix	crval2	DEG	Header
Target	ra_targ	DEG	Header
Target	dec_targ	DEG	Header
Moon	jpl_ra	DEG*	JPL
Moon	jpl_dec	DEG*	JPL

* Given in HMS and converted

These are the values that we have to calculate. The calculations are performed by finding the delta in degrees (this information is not saved), then converting to the delta in pixels (this is saved), and finally adding these deltas to the reference pixel detector position in pixels.

Object	Value	Unit	Source
Target	targ_x	PIX	Derived
Target	targ_y	PIX	Derived
Moon	ephem_x	PIX	Derived
Moon	ephem_y	PIX	Derived

[acviana]

A working draft of these changes is in commit 1d7fa1a1d276695910039e54f5524defa5c65545. Testing is still needed.

[acviana]

This is an image of mtpipeline/archive/05329_neptune/png/u2j30506t_cr_c0m_wide_single_sci_linear.png generated using the new `ephem_viewer.py' tool in the 0c447c3ee5db6dac2c8e741c84302317fdab79ba commit.

Not so much.

[acviana]

Running the following query on the database:

SELECT * 
FROM mtpipeline.master_finders 
JOIN mtpipeline.master_images 
ON master_finders.master_images_id = master_images.id
WHERE master_images.name = 'u2j30506t_cr_c0m_wide_single_sci_linear.png';

Gives 13 records (as expected), looking at just the coordinate information:

id	object_name	ephem_x	ephem_y
4662	triton	1290	1046
4663	nereid	-4958	-843
4664	psamathe	-29141	38086
4665	sao	10332	11432
4666	thalassa	1296	824
4667	laomedeia	-8939	-6919
4668	naiad	1260	812
4669	halimede	20265	1946
4670	despina	1281	824
4671	neso	46260	47422
4672	proteus	1299	758
4673	galatea	1260	792
4674	larissa	1296	776

Looking at this, all the moons are displayed correctly according to the ephem_x, ephem_y coordinates. So the issue isn't in ephem_viewer.py. Even the x/y axis are correct.

[acviana]

Susana thinks this could be the result of a rotation in the drizzled FITS files. If you look at the astrodrizzle configuration files I added in commit 3f10c12940ea0a64395884fdead6e3add75bebb6 you'l see:

final_rot = None# "Position Angle of drizzled image's Y-axis w.r.t. North (degrees)"

After talking to Roberto he confirmed that this setting will maintain the telescope roll angle. I never noticed this because I always work with the matplotlib plot of the array and not the original FITS imge through ds9. This means I never see the orientation of the image which I assumed to be north-up.

Max and Susana both confirmed that turning this on and reprocessing would be an acceptable solution if this turns out to be the issue. Before I do this I also want to plot the position of the planet (which should be on the refpix) and see if there is a rotational translation around that point.

After doing a little testing with Susana yesterday we verified that the difference between the JPL target position and the header target position was negligible. This is encouraging and suggests that the issue really is in the rotation correction.

[acviana]

So my previous comment was incorrect. From the AstroDrizzle handbook [1] entry for the final_rot keyword:

Position Angle of drizzled image’s Y-axis w.r.t. North (degrees). The default of 0.0 (None) would orient the final output image so north is at the top of the image. A value of INDEF would specify that the images will not be rotated, but will instead be drizzled in the default orientation for the camera, with the x and y axes of the drizzled image corresponding approximately to the detector axes.

So this is already being performed and we need to look elsewhere. The solution is still to plot the position of the planet as well as the moons.

[1] http://documents.stsci.edu/hst/HST_overview/documents/DrizzlePac/ch43.html#593004

[acviana]

So after adding the location of the planet this is what things look like.

The planet should be well aligned so I'll have to start by looking into that first.

[acviana]

Adding the CRPIX position information doesn't seem help much. It also doesn't look like an row/column switch either at this point (thought that might be part of the issue).

[acviana]

Looking at wikipedia the distances and masses do agree with what I'm seeing in my images. Specifically I am seeing the correct moons, at the correct distances relative to Neptune. so I'm not too far off.

Order	Name	Diameter(km)	Mass (×1016 kg)	Semi-major axis (km)	Eccentricity [27]
1	Naiad	66 (96 × 60 × 52)	19	48,227	0.0003
2	Thalassa	82 (108 × 100 × 52)	35	50,074	0.0002
3	Despina	150 (180 × 148 × 128)	210	52,526	0.0002
4	Galatea	176 (204 × 184 × 144)	375	61,953	0.0001
5	Larissa	194 (216 × 204 × 168)	495	73,548	0.0014
6	Proteus	420 (436 × 416 × 402)	5,035	117,646	0.0005
7	Triton	2,705.2 ± 4.8 (2,709 × 2,706 × 2,705)	2,140,800 ± 5200	354,759	0.0000
8	Nereid	340 ± 50	2,700	5,513,818	0.7507
9	Halimede	~62	16	16,611,000	0.2646
10	Sao‡	~44	6	22,228,000	0.1365
11	Laomedeia	~42	5	23,567,000	0.3969
12	Psamathe	~40	4	48,096,000	0.3809
13	Neso	~60	15	49,285,000	0.5714

Sources: http://en.wikipedia.org/wiki/Moons_of_Neptune

[acviana]

I ran a test of the rotation correction in astrodrizzle. I used u2j30506t_cr_c0m.fits in a clean directory. Making sure I also ran updatewcs and had a local copy for the c1m file I changed the cfg file so it read:

driz_sep_rot = 0.0# "Position Angle of drizzled image's Y-axis w.r.t. North (degrees)"

This produced the same output as the file I had created in the archive which leads me to believe that None is correctly interpreted as 0 degrees of rotation w.r.t North and that INDEF would turn off the rotational correction.

[acviana]

After commit e7f8614 this is how the image looks:

I was subtracting things in the wrong order for the delta. I was also taking the delta from the ra_targ and dec_targ keywords when really I should go right for the CRVAL1 and CRVAL2 keywords. I think I removed some other mistake by changing this.

So things seem to be aligned in the y direction but not in the x.

[acviana]

The issue was the RA increases to the East, which is the left when oriented North-up. Damn coordinate systems.