Affiliation
American Association of Variable Star Observers (AAVSO)
Wed, 07/24/2019 - 17:59
The stacking tool doesn't seem to work this morning. "Stack" accepts the checked images and presents the average/median option and the Comments box as usual. There are no error messages, but the stacked image just doesn't appear in the images list.
Phil
Phil:
I just stacked two images without problems. I did open an image before I did stacking. Could you try again?
I will ask George to reboot just in case.
Ken
Ken,
Yes, I did open an unstacked image after the first failure of "Stack". I just tried it again, and it still doesn't work even after opening a single image first.
I just shared with you five V images of ASAS J190640-1623.9 from BSM_S . These are only one of the sets of images that failed to stack today.
These are part of a backlog of images that I'm working on. I have lots of BSM_S and BSM_Berry images of this star in B,V, I from around the same time that I stacked previously without a problem.
Phil
Phil:
I was able to stack two of them and then all five of them without problems. George did reboot VPhot this afternoon.
Images are trailed slightly and give poor errors. This sometimes happens with BSM-S mount at a certain position. One of them trailed in an opposite direction. :-(
So not sure what the issue is that prevents you from stacking? Were the ones that stacked, better images, i.e. not trailed?
Ken
Ken,
I think I have found the problem. I can't say I completely understand it, but at least I can now use the images that didn't stack normally. The problem seems to be caused by issues with the star name, "Object" in VPhot.
I have been getting BSM images of this star since Oct. 2018. The images have come from two, or maybe three, different BSM systems.
VSP, LCGv2, and VPhot use the designations ASAS J190640-1623.9 or ASAS-RCB-8 for this star. At some point I was also getting BSM data for this star with "Object" name ASAS J190640-16239, i.e. the correct ASAS designation, but without the decimal point in the declination. This was treated by VPhot as a different Object (put in a different list), but LCGv2 and the AID recognized these points as ASAS J190640-1623.9.
In order to simplify keeping track of the images I "renamed" (in VPhot) all the images without the decimal point to the name with the decimal point.
I'm now doing the photometry on a backlog of images of this star, and I think I've gotten to the images which I had renamed. Now, when I attempt to stack these images, the stacked image does not appear in the star list with the Object name containing the decimal point. I discovered last night that the stacked images have been appearing in separate VPhot list with the orginal name (the name without the decimal point).
The FITS header OBJECT value for the stars in my main ASAS J190640-1623.9 list (with the decimal point) is given as ASAS-RCB-8. The stacked images which now appear in the new ASAS J190640-16239 list (without the decimal point) have the OBJECT value of ASAS J190640-16239.
I think sometime during period in which I have been observing this star the VSP or VSX or VPhot changed the name of this variable shown when loading the VSX catalog from ASAS J190640-1623.9 to ASAS-RCB-8, but still associated this with ASAS J190640-1623.9 (with the decimal point), but not ASAS J190640-16239 (without the decimal point). As a result when the images are stacked, the stacked images with the original header OBJECT name (without the decimal point) are sent to a different list.
It is interesting that when I submit the data for the new stacked images for "ASAS J190640-16239" (without the decimal point) they show up in the LCGv2 plot and WebObs as ASAS J190640-1623.9 data. In other words, it seems that WebObs and LCGv2 recognize ASAS J190640-16239 OBJECTS as ASAS J190640-1623.9, but VPhot doesn't. This is the part of the story where I get confused.
Phil
Phil:
Glad you found a solution. VPhot uses the name in VSX when it matches targets on the image. The default name may have been changed recently? Did you use a saved sequence in some cases and the VSX Index in other cases? Might explain what happened???
Ken
Ken,
Your questions:
Yes, the VSX default name did change during the course of these observations, and I think this was at least part of the problem.
I always used my saved squence (with the original default VSX variable name) rather than reloading the VSX variables from the Catalogs menu.
I believe I've learned enough about this problem to keep from tripping over it again, but I'm still a bit confused.
You wrote that VPhot uses the default VSX name when it matches targets on the images. Suppose the VSX default name for the variable changes, and the saved user defined sequence still has the original VSX name. Which name will appear in the available images list and in the Photometry Report? Does the value of the header's OBJECT keyword play any role in this.
Phil
Hi Phil:
A little investigation will help but I would assume that if you used the original VSX name in the saved sequence and then the default VSX name changed, if you then used the VSX catalog rather than the old saved sequence, the target on the image would have the new name on the image and in the report. Easy for you to confirm that here since you have the original saved sequence with the "original" name and can also click on the VSX catalog link?
Based on one of my old images, the fits header object name does not alter the name inserted on the image by VPhot/VSX. so I think the answer to that last question is no. The target on the image and in the report is based on the VSX name collected from the sequence OR the VSX catalog depending on which you used. Make some sense? Does your check, confirm that?
Ken
stacking 5, 10, 24 and 30 images.
been stacking all afternoon and just now.