Affiliation
American Association of Variable Star Observers (AAVSO)
Tue, 11/07/2023 - 22:49
When I stack images with Vphot I see no option to shift the images (hopefully slightly) to account for drift of the stars across the sensor using WCS. By looking at the results this does not appear to happen by default.
Am I missing something?
Cliff
Cliff:
AFAIK and based on my experience, VPhot stacks images on the basis of RA/DEC not pixel xy.
What do you mean by: << "By looking at the results this does not appear to happen by default.".>>
Ken
Ken,
I shared an example stacked image with you of WR25. I also shared the two individual images that were combined. I realized this is a contrived example since the images were captured many days apart.
Let me know what you think,
Cliff
Any reason you stacked images from different filters?
Ken
I must have shared the wrong unshacked images with you.
Cliff:
That stack is NOT at all normal. Multiple identical stars with shifts. Circular pattern.
I have seen this a few times where apparently SkyX/mount do something 'bonkers'? Great scientific term! ;-)
My recommendation is that you IGNORE this weird finding. IMHO, it is not VPhot stacking that does this??!!
So rare, that it is difficult to identify the cause?
Ken
Perhaps the algorithm can shift up/down and left/right, but cannot rotate?
Cliff
It is my understanding that VPHOT will stack by shifting based on WCS, but not rotating. I'm not sure whether the pixel shifts are only integer pixels or whether VPHOT will do sub-pixel shifts. It would be valuable to document the method used for stacking.
I've used VPHOT for stacking quite a bit, but only in cases where the issue is tracking and not rotation.
Arne
Looking at the code it appears VPhot shifts images in x and y to line up with the first image in the stack.
It does this by working with the pixel to ra/dec relation documented by the WCS solution.
There is no rotation correction.
And the move is by whole pixel.
George
George/Arne:
I'm happy that I saw the update in your post. You added the significant sentence <<It does this by working with the pixel to ra/dec relation documented by the WCS solution.>>. But, I still need clarification?
IF VPhot only lined up xy pixels of the images in the stack, targets would routinely end up smeared across the stack as tracking fails to keep the target on the same xy pixel location on the sensor/chip?
So, your update implies that the RA/DEC of each xy pixel in each image in the stack (time series) is calculated independently and then the RA/DEC is matched in each image and they are aligned on the basis of this RA/DEC?
PinPoint WCS calculations must determine the center of each pixel in RA/DEC at some fraction of a second/degree based on the known target coordinates? What is the pinpoint resolution?
So, are not images in the stack aligned based on this pixel RA/DEC? I understand that this alignment may only move images in the x or y direction. But if the image rotated would that not ultimately also lead to some movement in the y direction as well as x direction, similar to simple translation?
I can understand that xy pixel centers in subsequent images in a time series have different RA/DEC positions due to imperfect tracking. In most cases, we are not guiding to pixel or subpixel accuracy/resolution!
What can PinPoint do or not do to calculate the RA/DEC position of each pixel on an image and align the xy pixels among images that are not calculated with infinite resolution? I accept the fact that VPhot may only align pixels at whole pixel resolution (+-1 pixel per jump), so you can't align better than the image scale? And some small amount of smearing will occur during alignment?
Does this make sense/is it correct? Arne, please clarify?
Ken
Cliff;
Please share the images to Arne and George, as you did with me? They can then see what you are actually talking about! It is not a simple failure to shift/align two images.
Ken
I have shared three images with you three. The oldest and youngest being the individual and the middle aged one being the stack. These are different from what I shared with Ken since I deleted that one.
At this point I should probably confess. As I was looking through the various python libraries during last Friday’s workshop I spotted a very simple routine that reprojects an image to a new WCS. Since I had that stacking program for the BSM observatories I decided I would use my new python toy to create a version that aligns the images being stacked. Once it was working I wanted a way to test it. So I picked a couple of my WR25 images from BSM_S, widely spaced in time, and stacked them with VPhot and with my stacking program. To my surprise, I got the sort of result I just shared with you from Vphot. This resulted in my posting here.
Sorry to have raised so much rabble.
Cliff
I'd like to add a post to this discussion. I've just shared three images in V of Z UMi on the same night a few minutes apart and the stacked image. I ran Update WCS on these images to get the WCS coordinates. When I saw the triple image in the stacked image the first time, I deleted it, re-ran Update WCS, and got the same result. When I look at the RA/Dec on the three images, I get three different values for both coordinates:
RA Dec
15 01 57.22. +83 03 43.1
15 02 01.78. +83 03 55.4
15 02 06.61. +83 04 07.4
I'm working my way through using Astrometry.net to see if I can get a correct plate solve (read, the same RA and Dec for these images), but maybe I'm not understanding something about how WCS is supposed to work.
George (LGEB)
My best guess:
These 3 images have identical WCS solutions.
Was the "Update WCS" function applied? Understand that this does not re-run the pinpoint process on the images. What it does is take a good solution from the set of images specified and writes that into the other files. You should do this only if you are positive the images are pointing to the same spot.
If you stack you will see how much drift happened between images, as we see here.
George
Thanks, George.
Is it possible that images with the same WCS solution would have different RA/Dec in the FITS header? How would I tell that the WCS solutions are identical?
Yes, the Update WCS function was applied, twice in succession. The first time, only one of the three had a WCS solution, so I guessed that it was supposed to be copied to the other two images, but the differences in RA/Dec gave me pause. Good to know that Update WCS does not re-run Pinpoint on any of the images. I guessed that because if I chose only images without a WCS solution to run Update WCS, it fails with an error message that at least one image needs a WCS solution.
I feel OK running Update WCS in this situation because I know that we were pointing at Z UMi in all cases, and can verify that visually.
I took three sample images (the same ones I shared earlier) and processed them through astrometry.net, and then Uploaded them to VPhot. I just shared them with the three of you along with the stacked image, which now is a good image (only one star image, not three). In this set of three images, the RA/Dec are again not identical in the images. This makes me think that the Stack software is finding a way to correctly register the three images, but I don't understand why it does not do so with the images that got WCS from VPhot.
Thanks for being interested in solving this mystery.
George (LGEB)
I wanted to let you know that I was able to get stacking to work using images that were first processed through Astrometry.net and then the new FITS files uploaded to VPHOT. I uploaded 46 images of Z UMi taken over the last few months with our RFO RC20 and was able to stack sets of three (mostly) that were taken at nearly the same times with no problem.
Processing the time series I found that the SNR on our images is really not good - it doesn't even try to figure out the SNR on about half a dozen of the 16 stacked images, and the others are mostly SNR < 10 (!). I wonder if the problem with stacking the images without individual WCS solutions from astrometry.net is caused by the very poor SNR. I won't be submitting this data, but rather using it to troubleshoot our imaging process.
George