PIER-14 First results from pier 14 since the visit

Hi Ray. 

I checked quickly the data few days ago. If i remember well, some of them are a bit out of focus and some others with small traking issues

Nicolas

Just used it. Seemed OK to me. I have posted the processed version as a separate thread.

Let me know re tracking on P14 please, that I can sort if its an issue :)

~Re focus, its an FSQ so cool down means we always get some that can be soft, just resubmit if needed

Steve

Apologies for my late response. Firstly, I am in agreement with what Paul said. I'm not consistent with terminology, so I interchange the words 'frame'. 'image' and 'sub' frequently.

Focus issues have occasionally occurred in the past and throughout a short imaging run until the periodic refocus is initiated, and is therefore not always due to the cooling down of the scope. The loss of focus during cool down is a problem primarily during the summer. There is historical data still available that shows on the night that this data was collected the cool down rate was extremely low, just a few degrees between the high and low of that day. Besides, the fact that the first frame was out of focus and remained that way until the next forced refocusing occurred, also points to a focusing issue. This is just something to keep an eye on as Steve said, and resubmit.

For those not yet familiar with the behaviour of the mount, something you might like to consider when submitting a job.

When the mount initially slews to the object, and after a refocus, it will be off target. The first sub captured in a session and immediately after a refocus within a session will capture a slightly different area of the sky. You may have noticed this if you used 'Blink' after registering the frames. Those subs will be about 3 minutes in RA and 25 minutes in DEC out of alignment. This amount may likely be slightly different depending upon the declination. I can only assume that the polar alignment is out. 

What will that mean? If you include the misaligned subs during image integration then the portion of the fov cropped during registration will not be in the stack. If you use pixinsight and look at the 'rejection_low' image generated during integration then you will see what area was cropped. (Warning: this has happened to me twice when using WBPP and allowing it to choose the reference frame, it may select one of the misaligned subs. I tend to choose one myself these days.)

The 2 attached screenshots are illustrations of the Veil job in question, showing one of the misaligned subs and the 'rejection_low' image after integration. In the final stack only the cropped area of the fov will contain data from all of the subs that were selected, the area shown in black on the 'rejection_low' image will contain only data from the aligned subs. It depends on how fussy you are as to whether you need to take this into consideration, and as a result discard all the cropped ones during integration.

However, this will very unlikely be a problem where short exposure times are involved, certainly 2 minutes or less, when the vast majority will be properly aligned. When using 4 or 5 minutes then a relatively high number of subs will end up being cropped, perhaps 1 in 6 or 1 in 7. 

Lastly, and I can hear a collective sigh of relief, on extremely rare occasions the mount slews to a more random part of the sky for a few frames. The fov of those are far removed from the object, despite the fitsheader stating otherwise. I only mention this because i see it in the most recent job, submission 1888, the red filter subs.

None of these things have put me off of using this setup.

 

...When the mount initially slews to the object, and after a refocus, it will be off target. The first sub captured in a session and immediately after a refocus within a session will capture a slightly different area of the sky. You may have noticed this if you used 'Blink' after registering the frames. Those subs will be about 3 minutes in RA and 25 minutes in DEC out of alignment. This amount may likely be slightly different depending upon the declination. I can only assume that the polar alignment is out...

 

None of these things have put me off of using this setup.

On the pointing errors. I have noticed this for some time, and don't understand where it is coming from. On my own rig at home, I refocus between filters and never have this problem. It is almost as if the mount does not immediately repoint after a focus on a specific star. The 'error pointing' will be consistent across different nights and filters.

I have a solution, which is that I Blink everything and have become used to just junking these defective subs.

A different issue is the remaining lack of flatness and errors that can occur with alignment across the frame with different filters.

Attached are two 1:1 images from the recent California Nebula project (Job 1893).

These are from the 60 sec RGB subs, as I wanted to add RGB stars to the narrowband nebula.

I checked and stacked the individual filters, did a DynamicBackgroundExtraction, ChannelCombination, PhotometricColorCalibration and ArcsinhStretch to preserve colours.

You can see that in the centre of the image, the stars are reasonable, but in this example top-right corner image, the stars are elongated and colour separated. The same thing is seen in each corner (to different amounts). So there must be either field curvature, sensor tilt or both.

At normal viewing distances for widefield images, these errors are not really noticeable (at least to my tired old eyes), so I am not going to worry about it too much. But if you want to really zoom in on some details, you will have problems.

 

 

 

...When the mount initially slews to the object, and after a refocus, it will be off target. The first sub captured in a session and immediately after a refocus within a session will capture a slightly different area of the sky. You may have noticed this if you used 'Blink' after registering the frames. Those subs will be about 3 minutes in RA and 25 minutes in DEC out of alignment. This amount may likely be slightly different depending upon the declination. I can only assume that the polar alignment is out...

 

None of these things have put me off of using this setup.

On the pointing errors. I have noticed this for some time, and don't understand where it is coming from. On my own rig at home, I refocus between filters and never have this problem. It is almost as if the mount does not immediately repoint after a focus on a specific star. The 'error pointing' will be consistent across different nights and filters.

I have a solution, which is that I Blink everything and have become used to just junking these defective subs.

A different issue is the remaining lack of flatness and errors that can occur with alignment across the frame with different filters.

Attached are two 1:1 images from the recent California Nebula project (Job 1893).

These are from the 60 sec RGB subs, as I wanted to add RGB stars to the narrowband nebula.

I checked and stacked the individual filters, did a DynamicBackgroundExtraction, ChannelCombination, PhotometricColorCalibration and ArcsinhStretch to preserve colours.

You can see that in the centre of the image, the stars are reasonable, but in this example top-right corner image, the stars are elongated and colour separated. The same thing is seen in each corner (to different amounts). So there must be either field curvature, sensor tilt or both.

At normal viewing distances for widefield images, these errors are not really noticeable (at least to my tired old eyes), so I am not going to worry about it too much. But if you want to really zoom in on some details, you will have problems.

 

 

 

Sorry I screwed up the formatting of my reply. Ray's Comment I was supposed to be quoting ends with "None of these things have put me off of using this setup". The rest is mine.