Affiliation
American Association of Variable Star Observers (AAVSO)
Wed, 07/01/2015 - 18:36
Can someone please help me understand why the images from most of two nights work won't plate solve. They are all images of the same target- about 30 images take on two nights about a week apart. Images of a different target from the first night (same scope, same area of sky, same calibration routine) about an hour later plate solved without a problem. Previously I've had no problems with plate solving images of this target.
I've deleted and reloaded the problem images (or samples from the same run) several times, and I keep getting the WCS red box.
Help!
Phil
Phil et al:
As you may remember from one of my recent posts to "Fellow VPhot Users", we now have an active team addressing some of the issues that occasionally impact the operation of VPhot. One of the problems relates to the failed processing (e.g., plate solving) of images. We have learned a lot from some new tracking/logging tools that have been created and made some recent changes (last day or two) to the plate-solving procedure.
We think/hope this will reduce the rate of failure BUT if your issue has just recently occurred, and not before, it may indicate that our changes are not quite successful?
Two things we have learned is that about 15% of all images fail to process successfully. This failure can be attributed mainly to two factors: (1) the absence of a valid VPhot used id in the observer fits header (8%), and (2) the lack of an image scale value or the fits header fields (e.g., focal length) that allow VPhot to calculate it (7%). The first item knocks the image out of the queue immediately (and so it should!) and the second item causes a failure of plate-solving (and so it must?). So I ask that you first check your image fits headers and confirm that your images have these fields and/or determine if your recent images are different than older successful images, in that regard?
I think George Silvis may also see your post and ask some other questions specific to your case and make other comments?
I hope this explains what is going on and perhaps indicates what might be the problem. Not that this observation makes you any happier. Thanks very much for bringing this up, not that we want to hear that the system is having problems! I can quite confidently indicate that I think we are making progress to address and correct past problems and users will be happy with the results. Our efforts may not be without hiccups but I am hopeful that things will be improved for all of us in the near future.
Ken.
Hello Phil et al:
I am also working with Ken who is doing most of the heavy lifting with George and Geir, but not only does the plate scale have to be there, it has to be within 25% for pinpoint to solve. "If its not within 25%, it will NOT solve" Quote Bob Denny--author of Pinpoint.
Not sure how this requirement would fit your situation. Another failure occurs for blank images when the dome/roof closes. Have you looked at these images to see what they look like? Perhaps you could post a good one and a bad one, along with the fits headers for us to look at.
Gary
Phil, here is what I found in the log:
Here is an example of an image that passed:
7/1/2015 3:45:56 PM - Found NSV_11154__V_120sec_minus20_200630--calibrated7stack.FIT.
- Size 789120 ...
- Moving/extracting to temp folder ...
- Waiting for write to complete ...
- username= SPP telescope= Occidental 14-8
- Updating header ...
- Trying to plate solve ... scale= 1.4099999666214
- Trying TYCHO2 ... There are too few catalog stars in the area for reliable matching. Increase the catalog star faint limit, or use a more dense catalog. 7.6652334 s
- Trying UCAC-3 ... 0.1219878 s
- Write header to database ...
- Plate solved. scale= -1.41356803637398
- Moving image to D:\images\635713623590192018.fts
- Performing photometry ... 0.1569843 s
- Cleaning up. 13.4376561 s
Your plate scale is good, confirmed by the solution in the UCAC3
Here's a failure:
7/1/2015 4:40:36 PM - Found AO_Her_120sec-Icminus20_binned2x2_stackfour_20150623-.00000001_calibrated.FIT.
- Size 789120 ...
- Moving/extracting to temp folder ...
- Waiting for write to complete ...
- username= SPP telescope= Occidental 14-8
- Updating header ...
- Trying to plate solve ... scale= 1.4099999666214
- Trying TYCHO2 ... There are too few catalog stars in the area for reliable matching. Increase the catalog star faint limit, or use a more dense catalog. 9.5980401 s
- Trying UCAC-3 ... No matching stars found. Check your estimated center-point RA/Dec, and your image scaling and quality. 0.3069693 s
- Trying GSC ... No matching stars found. Check your estimated center-point RA/Dec, and your image scaling and quality. 0.3119688 s
- Write header to database ...
- Failed to solve the image.
- Moving image to D:\images\635713656393361373.fts
- Cleaning up. 16.7713227 s
Here it failed on three catalogs. Pinpoint is suggesting that the image ra/dec are off. That would be the first thing to check.
Are you able to plate solve these files before they are sent to VPhot? That would by-pass this problem.
You can contact me offline to try to resolve this: SGEO@GASilvis.net
George
Thanks George for posting those two logs. Looks like they are from the same telescope. One was binned 2x2 and the other one did not say. Yet both start with a plate scale of 1.4.
Is the NSV 11154 image binned 2x2? If its not, and it plate solved, then the plate scale of 1.4 is near correct. However, the AO Her is binned 2x2, so it cannot have the same 1.4 plate scale.
Key question, is NSV 11154 binned?
Gary
Good point, Gary
I don't see where VPhot is correcting the platescale for binning. Though it could. There is some code there, commented out, showing how to do it.
If the images Phil is having a problem with are binned, he should try an experiment creating a second telescope profile for 2x binned images with platescale of 2.8
George
Thank you all for your quick responses.
All the images are binned 2X2, both the images that were plate solved without problems and the images that failed. The plate scale of 1.41 is based on the binned pixel size. (ST-8XME binned 2X2, C14 working at FL 2630mm, ~F7.4)
I'm going up to the observatory this evening with the intention, as advised, of plate solving the images that failed WCS.
I now remember a slight arguement between my dew shield and a roll-off roof rafter. I'll check the log for when that happened. That could well be the explanation for what now seems to be the likely problem, an inaccurate value for center of the field in the header.
Many thanks,
Phil
VPhot is really slow right now because 85% of the images are failing plate solve.
I investigated one image and ran it though astrometry.net. I found that not only was the plate scale off but the image center coordinates were degrees out.
So, if you are running into a string of WCS failures, check one or two images through http://nova.astrometry.net/ to test your assumptions about platescale and image center.
Note that you have to fix the platescale in your telescope profile in VPhot. But image center can be tweaked in the download page.
George
George,
I used AIP with USNO A2.0 (24 reference star per image) to plate solve four stacked images that failed WCS. The focal length is correct and the same in all the images within single digits of millimeters. The field centers didn't seem too far off as well, but I'll take a closer look at those numbers tomorrow.
I'd certainly be interested in knowing why these images failed WCS (maybe it was just that VPhot was having a bad day), but my main interest is getting these images solved in VPhot and the photometry done. To that end I have a question: In the "upload wizard" there is an option to enter the RA/Dec for the center of the field. If I were to enter the field centers I measured using the AIP plate solutions into the "upload wizard", would this supersede the RA/Dec values in the FITS header?
Phil
Hello Phil
I would certainly see what George or Ken has to say, but I think that VPHOT would take the new values under the Wizzard. I am not a power user of VPHOT, but what I would suggest one of two possibilities.
1. Edit the FITS headers so that no plate centers are there. Then the wizzard should bounce them and you can fill in the correct values. I think if wrong values are there, not sure the wizzard allows edits.
2. The second possibility is to edit the FITS headers to the new plate center values that you get. Then submit them to VPHOT--try the wizzard first, but it seems that either method would work.
Let us know how this works. We are learning as we go on this VPHOT/Pinpoint/Wizzard/? problem. There seems to be enough team knowledge of bits and pieces that we can solve these issues--most of which we did not know were problems when we started this effort.
Gary
EDIT THE HEADERS? How can you do that except a line at a time, and an image at a time? Sounds like a nightmare to me! Are you using a special type of software?
Lew
Lew:
My personal imaging software (CCDAutopilot/Maxim) is set up to put all the necessary headers into my images. iTelescope is set up to put in the necessary headers, at least all my iTelescope images work? Make sure you tell iTelescope what your VPhot id is (owner name in telescope setup).
Does this help? Doing it by hand would be a bear! I've never done that.
Gary's recommendation to Phil was just a one time effort to check out one the images that had failed.
Ken
EDIT THE HEADERS? How can you do that except a line at a time, and an image at a time? Sounds like a nightmare to me! Are you using a special type of software?
Lew
Phil,
Yes, I believe the values you input on the upload window supercede the image values. So give it a try!
If you continue to have an issue, please leave the file on VPhot and send me its name so I can investigate the log.
George
Yesterday I had a set of images sent to AAVSO and while most of them showed a green square in the WCS column, some did not. ALL of the images had the same coordinates: 00:00:00 and 00:00:00. So I downloaded the images from iTelescope and spent 2 hours unzipping and running them thru AIP4Win. So instead of 10 minutes, I spent 2 hours.
It is times like these when I really appreciate VPHOT (when it works, which is most of the time).
Lew
Lew,
Most of my iTelescope transfers to VPHOT work fine - except for iT21. Was that the scope you had problems with? Either way, on the failed WCS images, what is the telescope name in the VPHOT image list column? When it doesn't work for me, it looks like "ACP-->iT21" instead of just "iT21".
I sent a note to iTelescope last week and they are still working the issue.
I work around it by downloading the images to my computer, then uploading to VPHOT and selecting the correct scope in the submmission list. Then WCS is successful...
Gordon
The scope I had problems with was T17. It appears that I failed to check the box for solving plates on my images of FO Aqr, but that star was listed as the target.When I use the wizard, I put the coords in at the start, because my software (CCD Soft) does not have an entry for it.
The thing about downloading images from iTelescope and uploading to VPHOT adds time and a lot of work to the flow, so I hadn't considered it. You can "rename" the telescope and the filter in VPHOT, and then click "update wcs".. Or go to Astrometry.net and download a single image and upload it to vphot - after you delete that image.
Lew
The VPhot upload wizard let's you set the star name, RA/Dec and filter for all the files you are uploading. That should be a lot easier than editing headers!
George
George, et. al.,
There is still no resolution to my problem on getting two nights work to plate solve. To help the investigation of the WCS failure, I plate solved the images with AIP and edited the headers with the new plate center coordinates (which weren't much different from the original header coordinates). George got these to plate solve with astrometry.net, but they again failed WCS in VPhot.
I've uploaded dozens of images of this field (AO Her) in the last year using the same telescope, camera, mount, software, and calibration method. All these plate solved without a problem, but now images of the same field won't plate solve in VPhot.
I've left the (failed) stacked images and four (failed) subframe from one set of the stacked images in my images list in case someone has any ideas about why they won't work. I'm wondering if others are having similar problems.
Thank you George for trying to figure this out. Is there something else I can do to try to understand out why these images don't plate solve in VPhot?
Phil
George had reported that my (failed WCS) images plate solved in astrometry.net. This morning I ran both images through astrometry.net myself, then uploaded those two images (with the astrometry.net solution) to VPhot. Results- WCS green box!
Thanks George! I still don't know why they didn't solve in VPhot, but I least I now have a work around.
I'll leave the failed images in my list for a while is case someone wants to try to figure out why they didn't work in VPhot.
Phil
This is a reminder to heavy users of VPhot to use it fairly.
If you have 100+ images to push into VPhot please first load a 3 or 4 images to confirm that VPhot can plate solve them. If you push in 100's of images that can't be plate solved then the VPhot queue will be tied up for hours for no good result and frustrate the other users waiting in line.
There are number of things you can do to aid your cause:
- do you have the proper plate scale set in your telescope profile?
Use Astrometry.net to solve one of your images and put that plate scale value into your telescope profile.
- is the image RA/Dec properly set in the image?
If not, use the info you get from Astrometry.net to correct your files. The VPhot Upload screen let's you set the correct value and override the image value.
- Are they valid images? I've seen a lot of closed dome shots being submitted to the queue. They won't ever solve!
- And you can always pre-solve your images before you upload them to VPhot. They'll fly through with no delay.
- If you are still having problems, contact me ( SGEO@GASilvis.net ) and I'll review the VPhot logs and be able to tell you what VPhot is complaining about when it fails plate solve. Let me work with you to get this system working smoothly for all.
VPhot is a great resource, but it is a shared resource, so please use it wisely.
Onward and upward!
George
Seems like many posts are about VPHOT queues getting "stuck" and the system getting "hung". This just shouldn't happen in an important and heavily used system!
For example, plate solving, which is a tough problem for a computer (but a lot easier for humans!) hangs frequently, then its necessary to put a time-out in the software to allow it to continue. Lower that user's/submission's priority and move onto the next user/job. Stubbornly processing jobs in sequence until they complete guarantees hangups!
Also, providing more specific feedback to the user, a precise error code or message indicating exactly what fault in their submission causes it to fail. This would allow the user to make corrections and resubmit, without having to post on the forums and waiting for a sysadmin to hunt down error logs.
It would be a good idea, as the system usage increases, to start planning some scheduling or queuing algorithm to prioritize and handle jobs in the most efficient way possible. There's tons of such software and libraries already available out there in most programming languages to implement this very easily. (eg. STL in C++).
I plan on using VPHOT myself soon for DSLR, so I hope some of these useful suggestions can be incorporated!
Thanks,
Mike
Mike - you said: " plate solving, which is a tough problem for a computer (but a lot easier for humans!)"
This leaves me wondering how you can plate solve by looking at an image and know where North is, where in the sky the telescope is pointed, whether the image is reversed or not and what the scale is when the brightest star in the image is 12th magnitude and the image is 10 arc min square.
I use Astrometry.net and I marvel at the task they do. Are you doing something that the rest of us aren't? What info are you starting with?
Lew
[quote=Lew Cook]
This leaves me wondering how you can plate solve by looking at an image and know where North is, where in the sky the telescope is pointed, whether the image is reversed or not and what the scale is when the brightest star in the image is 12th magnitude and the image is 10 arc min square.
[/quote]
Hi Lew, I am referring to how the human mind/visual cortex is able to so effectively do pattern recognition of star fields, compared to the difficulties that computers (artificial intelligence) has in doing the same thing.
Of course visually, I know about where I am pointing, my telescope's field of view and limiting magnitude under various conditions, so that helps as a starting point. But direction of N is not always easily apparent with my "ball mount" ! Most of the time i can recognize star patterns (regardless of their orientation) and "star hop" to the object in a few seconds. vs. Plate solve on a computer can really hang up for a long while "crunching" to find out where it is.
If there are NO obvious star patterns around my object, it can take longer visually too! But, I think thats the key difference in human perception vs. machine perception. If a recognizable pattern of the stars (like mini constellations) are memorized for a field, the human easily beats the computer ;)
Mike
Hello Mike
You might not be aware that Vphot alread has a download Wizzard, that scans ones FITS headers and looks for problems. You can easily add info for blank fields. What the Wizzard cannot do is determine if 1.686 arc seconds per pixel is the correct value.
So folks who are early in the learning curve are suggested to use the Wizzard. It gives exact feedback.
Users should also scan their FITS headers pre submittal, to make sure the plate scale is correct and that the plate scale is within 25%. Make sure your observer code is present. Make sure the RA and Dec is correct. This goes for the remote telescope farms also. We found issues in their FITs Headers also, and asked them to correct them. We even found blank images, even astronmetry.net is going to struggle with blank images. A trap will be put into the que to attempt to find blank images.
In the past month, these have been the main offenders that the VPhot Team has uncovered as to why the Que hangs. A more detailed report is being prepared, as well as the Team is continuing to work the problem. They found lots of issues. VPhot seems to run much better now. Surprisingly, most of the issues were ones where the observer shot himself in the foot.
Gary
[quote=WGR]
You might not be aware that Vphot alread has a download Wizzard, that scans ones FITS headers and looks for problems. You can easily add info for blank fields. What the Wizzard cannot do is determine if 1.686 arc seconds per pixel is the correct value.
[/quote]
Thanks Gary, I didn't know abt Wizzard, sounds like it will do the job! It might get more use if it were inlined in the VPhot code, and accessed via a menu selection?
[quote=WGR]
In the past month, these have been the main offenders that the VPhot Team has uncovered as to why the Que hangs.
[/quote]
My other point was that an app should never "hang" from unexpected inputs. Novice and careless users will always exist, so the program needs to be able to handle all the "looneys" ;) ;)
Mike
Hello Mike
You wrote
"Thanks Gary, I didn't know abt Wizzard, sounds like it will do the job! It might get more use if it were inlined in the VPhot code, and accessed via a menu selection?
Actually it is a menu selection: Main Page>Upload>Upload Wizzard.
Gary
I have no doubt that George, Ken, and Gary are correct that the majority of plate solving failures are the result of simple errors such as incorrect (or lacking) image scale or plate center information in the VPhot telescope settings or FITS headers. That said, at least in my case, something new seems to have happened recently with plate solving in VPhot.
I have been uploading images to VPhot for over a year. Until about 2 weeks ago I had never had any problems with plate solving. Since then, despite no change at all in my system, procedures, or VPhot telescope settings, all my images now fail WCS. The images scale and plate centers in the failed images are correct.
Taking George's advice, I now plate solve my images before uploading them. For me, this has solved the problem, but I'm wondering if other VPhot users have had a similar experience.
Phil
Hello Phil
Plate solving locally on your own computer is definitely reccommended. Phil, are you using astrometry.net? I don't think anyone understands all the reasons why plate solves fail. As new conditions arise, new camera software with quirks in the FITs, we will probably always have this issue.
It does seem that astrometry.net is a much more powerfull service, which resides on the cloud. While I have used it twice, it worked both times. I have been told by those who use it all the time, that they almost never get a failure.
Should we use astrometry.net as part of Vphot? I don't remember the answer. Does astrometry.net do well with submittals of 100's of images. I seem to remember that it like to upload one image at a time. Perhaps other have tried 100's of images and can answer this.
Gary
Gary
Hi Gary,
When I first had this problem I used AIP for plate solving. It's pretty quick and easy when the header coordinates are close. Now I use astromenty.net. This has never failed to solve the image, including all the images that failed in VPhot. As far as I can tell it just loads images one at a time.
Phil
Hello Gary, you wrote:
[quote=WGR]
It does seem that astrometry.net is a much more powerfull service, which resides on the cloud. While I have used it twice, it worked both times. I have been told by those who use it all the time, that they almost never get a failure.
Should we use astrometry.net as part of Vphot? I don't remember the answer. Does astrometry.net do well with submittals of 100's of images. I seem to remember that it like to upload one image at a time. Perhaps other have tried 100's of images and can answer this.
[/quote]
I have quite a bit of experience with astrometry.net local version and some experience with web service. Typically PinPoint wins hands down in speed - when plate scale and field center are known well enough. I'm not sure about Pinpoint's blind solve capabilities. My experiments with MaximDL and PinPoint LE inside it have shown that it may take even longer to solve WCS compared to astrometry.net in the case of "semi-blind" solving - when e.g. 10'x10' field is off by 1 degree. I suspect, that Bob Denny did not designed PinPoint for such task (but I may be wrong) :-)
While I use occasionally astrometry.net web service, I mostly solve all my hundreds or thousands of science images using astrometry.net local version. I have to do that (and I feel myself very comfortable with that, too ;-) ), because PinPoint gives corrections to linear WCS in a proprietary and unpublished format - and most probably any of professional tools (I mean: tools typically used by professional astronomers) can not use them.
Solving one 37x37 arcmin field (2048x2048 pix) with approximately known center coordinates (e.g. solving variable name from WCS-solving script using Simbad), plate scale known within ~10%, and using search radius 1 degree, it takes typically about 10-15 seconds on 3 GHz Core2Duo processor to successfully solve the field. When plate scale is not known, it can take much longer. Typically, solving first image takes a bit more time, but when typically needed astrometry.net indexes are already loaded into the memory, searching inside them is lightning fast.
For comparison - solving 2000 images of one field from one observing night takes still couple of hours to solve, at least.
BUT. It should be possible to solve in parallel, using astrometry.net - just each frame should be solved separately but on different processor/core. That should be somewhat simple task to solve using either a scripting language or job control software. I don't know if PinPoint's is able to use multiple processors. It is possible to extract positions of stars using e.g. sextractor and feed those positions into "remote" astrometry.net solving engine, that could provide additional flexibility in distributing computational load. My personal opinion is that if AAVSO has resources to run 10 astrometry.net engines in parallel, that would give noticeable improvement in WCS solving performance.
BUT. Astrometry,net doesn't take care of sorting out any issues with FITS headers (missing or wrong field center coordinates, wrong or missing plate scale etc), it is a WCS solver that does fine job also when solving completely blindly. So, header checking functionality must be implemented. Maybe not from scratch but there would be certainly some work to do. Also, I can not estimate how much human resources would be needed to set all this up in the computing cloud environment... Maybe it would be easier to bug Bob Dennyfirst to ask his help with plate solving technical issues (I have extremely good experience in communicating with him, probably many people here have)?
Best wishes,
Tõnis
Thanks Tonis
Thanks for that valuable information and experience. I am sure that this will be valuble to the Vphot Team.
You wrote: "For comparison - solving 2000 images of one field from one observing night takes still couple of hours to solve, at least."
This at first blush sounds slow. But figure 3 hours, 180 minutes, call it 200 minutes and its 0.1 minute per image or 6 seconds per image. Thats pretty good. As you say, the initial conditions matter.
Gary
Ignore - wrong forum!