I have uploaded images to VPhot yesterday evening and this morning. All are of the same target (V1033 Cas). This field contains several variables of interest. The first batch went smoothly and quite quickly, while the second batch is being processed slowly, and the resultant identifications of the stars is off by ~11 arc sec. As a result, 5 of the 7 stars of interest in this field are shown with a red circle (indicating they aren't there) right beside the star that ought to be in the (green) circles. At the first pass, the WCS had a red square, which I got removed by clicking an image taken just prior to the set I uploaded today along with several of today's images. The difference between the 2 sets is that the set uploaded today had twice the exposure as the earlier set. The FWHM is ~ 4 pixels, but the background is 11,000 ADU (the same as it was in the earlier set at the start - the star rose higher and the sky brightness level was lower).
How can I solve this dilemma? Do I need to delete these incorrect WCS images and re-upload again? Is there another way? It has taken all day for VPhot to process the images before mine - spending maybe 3 minutes each.
Any suggestions?
Lew
Lew,
Did you try increasing the size of the default aperture under "settings" while viewing the image? If you increase the size of those the centroid algorithm might pull the apertures right over. After you increase that reload the image. I'm guessing since just some of the stars were missed that you shouldn't have to increase it that much.
The off-target error just worsened the further down my image list. By mid-list, the error was over 60 arc secs. Then there were 11 stars that your suggestion would have come up with for V1033 Cas. Most were brighter than V1033, and would have surely been selected.
I'll bite the bullet and process them in AIP4Win.
Thanks for your suggestion,
Lew
This morning I resolved the off-target issue. Here's how:
First, I deleted the 55 off-target WCS images.
Next, I uploaded the same 55 images that were off-target the first time VPhot tried solving them.
The upload and processing went quickly and -voila- PERFECT!
Lew
Lew:
It's good to hear that this worked BUT it certainly leaves one scratching his head? I assume some of your VPhot settings got changed? Otherwise it is not easy to determine the problem and resolve it in the future?
Ken
Unless I had the RA off by 6 minutes (a possibility, since I double click the input areas in the wizard and choose what I think is correct), all was the same. As a test, I have deleted two images and run them seperately with the 2 possible choices. Since the first image processed was off only by about ten arc-sec, I am uncertain the fault is mine.
I'll keep you posted. Thanks.
Lew
Lew:
What do you mean by "Since the first image processed was off only by about ten arc-sec,.."?
Did the two images give different RA/Dec for the target by 10 arcsecs? Not exactly the same RA/Dec?
I was not referring to the settings in the upload wizard but your centroid search settings in VPhot??
Ken
I figured out why 55 of my images were off target: V1033 Cas (the primary target) has coordinates RA= 00 22 57.6' Dec = +61o 41' 08". However in the upload wizard, I entered 00 28 56 for the RA. The Dec was correct.
GIGO.
I apologize for wasting the time of:
a) Those who were so kind as to read these notices
b) Those of you in a) who thought about the problem and were kind enough to respond, and
c) Those of you who had images in the queue behind mine while I wasted VPhot's valuable time (3 hours).
Henceforth, I will run the first of my images thru Astrometry.net (when it is running properly) and obtain the coordinates of the center of my first image to use in the VPhot upload Wizard to keep this mistake and subsequent delay from recurring. If Astrometry.net services are unavailable, I will match my image to an atlas and get the coordinates from there.
Again, I apologize,
Lew
Lew
Hello Lew,
actually, you can run astrometry.net in your own computer, too. It is kind of trivial under Linux and MacOSX but there are also binary packages for Windows. See e.g. AstroTortilla. Good tutorial about installing, configuring and using it is e.g. http://lightvortexastronomy.blogspot.com.ee/2013/08/tutorial-imaging-setting-up-and-using.html, searching for 'astrotortilla' gives enough pages to follow, too :-)
If you should have MaximDL that includes PinPoint Lite, you could use that one as well. Probably there are some scripts out there in the Internet that do that...
Best wishes,
Tõnis
I too seem to have trouble this time around with Vphot and Pinpoint.
Last April Vphot was plate solving my images without much trouble, missing one or two per batch. Last few days, however, I have had issues. Fortunately I have The Sky X that can plate solve and does it fairly quickly.
After bogging down the queue with Vphot struggling to add WCS to my images (sorry guys!), I have now started plate solving locally first and the uploading them. They fly trhough now.
Given the behavior difference (I was using the same software and system then and now), I wonder if an "improved" Pinpoint may be the culprit. Not that I know if it has changed or not, but it seem like a possibility.
Marco
Marco:
Plate-solving on your computer certainly resolves the issue. I have always plate-solved all my images on my own computer before uploading. However, we should try to figure out what the problem is so that others may be helped also. I know of no reason why you see a problem now versus in the past. Perhaps things are not quite as similar as you may think, or not??
Ken
Next sets of data (I
Hi Ken:
Next sets of data (I don't know when that will happens, as Cleardarksky shows white for the next three days....) I will upload a small set (10 or so) without plate solving and see what happens. I am literally using the same software to control the session (CCDcommander), the same software to control the mount (skyX), and the same routine to reduce the data (Bias, darks,flats, dark-flats and lights all aquired using SBIG camera) I used last April.
Curioser and curioser...
Marco
Hi All:
As noted in this thread and in other posts, sometimes VPhot fails to plate-solve an image when no obvious image problem exists. The two attached images seem to exhibit this problem. Pointing is off somewhat (perhaps by about 12 arcminutes). The plate scale is 1.24 " / pixel. The two images (RR Cet) are from opposite sides of the meridian. Other info is present in the fits header.
Both failed plate-solving in VPhot. However, one passed and one failed pin-pointing in Visual Pinpoint on my local machine. I uploaded them to Astrometry.net where both reportedly succeeded. However, the "successful" plate solution reported that the orientation of one image was 4 degrees E of N, while the other was 94 degrees E of N? Orientation was off by 90 rather than the expected 180 degrees?
Bragging rights go to anyone who can explain these discrepancies. I hope someone can help resolve this occasional problem. I recommend that you look for any obvious trivial issue first and then dig into the more obscure reasons. Pointing may be the only problem? Hopefully this is not a "duh" moment.
Thanks for your help!
Ken
I may be able to explain the 90 degree difference. those two sets of images were indeed with a different camera orientation (trying to correct the problem I mentioned to you with an adapter). So indeed one was with "north up", and the other a 90 deg from North.
Regardless, however, why these plate solve with the SkyX and with Astrometry.net, but not at all with Vphot is still a mistery.
Marco
Although it may be me being sensitive to terms, it is PinPoint failing and VPhot uses PinPoint! So is one of you a PinPoint expert who can identify what is going on? I have read the PinPoint help files. The most common failure is due to pointing errors which are a bit off for these images but not by enough to cause a problem?? The image scale is the other common failure reason but it is well defined for these images. ??
Ken
About six months ago I also started having plate solving problems with some of my images. Previously, all the images were solved by VPhot. Then, inexplicably, images of some targets failed every time while images of other targets solved every time as before. ... this, despite the fact that the images were taken, processed, and submitted in exactly the same way, and there were no changes in my equipment or software. For example, I know that all images of AO Her will fail WCS with VPhot, but all images of NSV 11154 will solve. It's very consistent.
After a week or so of trying to understanding what was happening I gave up. Now I just plate solve images locally which I know will fail WCS with VPhot. The images which I know will solve with VPhot I submit without local plate solving.
When I add a new target I first upload a test image. If that fails WCS, I know that in the future I'll have to plate solve all the images of that target before uploading. If the test images passes WCS with VPhot, I know that images of that target will almost always pass in the future.
Perhaps there is a clue in all this for the problem currently under discussion.
Phil
Phil et al:
One change that was made about 3 months ago, after George took over responsibility for programming, was to select the "best" catalogs for plate solving. George, Arne, and I selected three we thought were up to date and covered the full range of magnitudes from bright to faint comps. We reduced the wait time for each catalog to 60 seconds since metrics indicated that 40 sec was enough (usually just a few seconds).
Currently we use Tyco, UCAC4 and USNO in that order (I am almost sure about the last choice?). UCAC3 and GSC (plus 2 others) were used before. We have thought about using all sky plate-solving before (astrometry.net) but that may take quite a bit more programming effort?
It would be nice to determine what is sometimes wrong with the current procedure!
Ken
PS: I'm going to take an AO Her image myself to see what happens to my image? Curiouser!
Ken,
My problems with plate solving certain fields actually started about the last week of June of this year. I went back and found my VPhot forum post about this dated July 1, 2015.
I'll be very interested to hear about your results with VPhot pinpoint and the AO Her field.
BTW, don't be surprise if you don't detect AO Her itself without a long exposure. This RCB star has been very faint (18.5 - 19.0V) for the last few months.
Phil
Phil:
Interesting! After checking my emails, that was about the time of the change. Best laid plans?
Ken