Jump to content

SkySurveyBanner.jpg.21855908fce40597655603b6c9af720d.jpg

Nightmare!

Demonperformer

Recommended Posts

Demonperformer

Demonperformer

Posted
  • Author
Posted
23 hours ago, coatesg said:

It makes a lot of sense from a linux point of view (remember Cygwin is used by AT, but is not maintained by the AT developers). Packages have inter-dependencies due to references against required libraries and the way that packages are built requiring certain versions - many of these libraries change on a regular basis due to bug/security fixes, or feature updates. It avoids the need for the AT guys to keep (essentially) their own copy of the cygwin distribution and to have to repackage it with their own software on a regular basis when there are security releases. There are also many instances where cygwin is already present on a client PC - you wouldn't want to force conflicts with any pre-existing Cygwin install, but rather let the relevant cygwin installer sort out itself what is needed.

Hi Graeme. I have been thinking about this, and, although I can see what you are saying, I don't think it addresses the point I am trying to make.

My AT installer is a 'fixed' piece of software - it does not alter with the changes made to cygwin. Somwhere within it is an instruction that equates to "go get cygwin", or more specifically "go get cygwin bits a, b, c, d, x, y & z". Now the content of these individual bits may alter as the program develops, but  presumably there are cygwin protocols in place such that getting these bits will always produce the desired result. The AT installer certainly doesn't know that the contents of a, b, etc have changed.

Now, when AT says "I am going to install cygwin", to me that tells me absolutely nothing useful - ok, it's telling me that I need cygwin (or some unspecified bits of it) and it's going to do it, but nothing more than that. And it restricts the machines upon which it can be installed. Whereas the comment "I am going to install cygwin bits a, b, c, d, x, y & z" would now make the package truly useable on any machine - connected to the internet or not. I could now go to the cygwin download site and know that I needed bits a, b, etc.

But this is the very information that is withheld, even in the case of so-called open source programs. And that is what I find so irritating.

Or am I still missing something?

Thanks.

Link to comment
Share on other sites
  • Replies 189
  • Created
  • Last Reply
stash_old

stash_old

Posted
Posted

I have noticed that AT is very slow with TIFF files but if you convert the TIFF to JPG(8bit) it speeds up (and solves where the TIFF image fails) -  a lot - so Tiff image solved in 250 secs converted Tiff to JPG image solves in 29-40secs Blind. As I pointed out doing it manually you can alter the fields and "Down Scaling" does help - AT or Astrometry Software does not seem to like too many stars and that is what the Downscaler effect does - it reduces the number of stars used to build its solving algorithm(it seems) - so for example  my Tiff image produced 1200 reference stars, changing the "Down Scaler" reduces this to say 20 (depending of the DownScaler factor input) which then reduces the time and actually ,in some cases, goes from a negative to positive solve.  ASPS doesn't allow TIFF - only fit/jpg

Now I don't know if this reduces the accuracy (my AT setting was 1 arcmin for testing) but it works for me.

Be careful installing more  than one Cygwin as it can get confusing especially if you load the indexes manually - LOL - I admit it I put them in the wrong place and wondered why ASPS didn't use them!

 

Link to comment
Share on other sites
coatesg

coatesg

Posted
Posted

Well - this may indicate more about the last tiem I installed AT, but the recommended method is now moving (with AT 0.8) to install the astrometry.net solver as a standalone from http://adgsoftware.com/ansvr/ - see FAQ at:

https://sourceforge.net/p/astrotortilla/home/FAQ/

ANSVR is a standalone installer so it looks like the cygwin portion will become redundant.

4 hours ago, Demonperformer said:

Now, when AT says "I am going to install cygwin", to me that tells me absolutely nothing useful - ok, it's telling me that I need cygwin (or some unspecified bits of it) and it's going to do it, but nothing more than that. And it restricts the machines upon which it can be installed. Whereas the comment "I am going to install cygwin bits a, b, c, d, x, y & z" would now make the package truly useable on any machine - connected to the internet or not. I could now go to the cygwin download site and know that I needed bits a, b, etc.

But this is the very information that is withheld, even in the case of so-called open source programs. And that is what I find so irritating.

But it's not really "withheld": A brief look in the AT source code gives me this file: https://sourceforge.net/p/astrotortilla/code/HEAD/tree/trunk/AstrometryNetPackages.txt - I presume that's enough to get astrometry.net running locally (and to build - so you might get away without the dev packages to just run it). However, a lot of people may see the code behind the project and then have a bit of a meltdown, and so providing an installer that does it all for you is a very friendly way of doing it.

(It also avoids dependency issues etc - it's not just that you need a, b, c and d, but you need versions of a,b,c and d that are all self consistent - packaging/automated dependency management ensures that; asking a human to download them manually doesn't. I've been into "dependency hell" before in administering Redhat and Debian based systems - albeit more complex than simply a cygwin install, but it's not a pleasant place to try and work your way out of sometimes :-/). 

 

Link to comment
Share on other sites
Demonperformer

Demonperformer

Posted
  • Author
Posted

Have received a reply from Andy at ansvr and things look good.

I can confirm that ansvr installs its own cygwin package from the installer and does not require an extra download. The solution for the index files is:

Open the index file downloader from the start menu and click the folder button. Select the directory where the index files reside and it then displays a message that it has found the files and you can close the dialog box.

The good news is that when I went into Sharpcap, it had automatically detected the ansvr presence. Solved the standard M42 pic, with a full set of index files, in just over 2 minutes. Currently trying my NAN pic (which has over 5000 sources found - so don't expect miracle times!) again with all the index files. At this stage, I will be happy if it does not place it in Gemini!

Link to comment
Share on other sites
Demonperformer

Demonperformer

Posted
  • Author
Posted

Well, after over an hour it was still chuntering. Probably a combination of too many sources and too many index files. 

First change, increase to sigma to reduce sources to 218 and use only 41xx index files. It promptly failed due to "Too few sources". Don't really understand that.

Anyway, reduced sigma to generate just over 1000 sources. Currently chuntering using the 41xx files - objects 51-60.

Link to comment
Share on other sites
cuivenion

cuivenion

Posted
Posted
35 minutes ago, Demonperformer said:

OK, that totally failed as well :hmh:

It did work with astrometry.net, so it can be done.

Can I ask anyone who has SC set up to platesolve, to give this image a go and upload the log file if it works so I can compare and see where things are diverging?

Thanks.

NAN.fits

Hi, what's your focal length and pixel size? I only have the index files I need installed, so if your resolution is vastly different from mine it wouldn't solve.

Link to comment
Share on other sites
stash_old

stash_old

Posted
Posted

Without setting anything in Sharpcap - and just using the Test Controls for the Test Camera your file solved on my PC see attached log

new 2.txt

Now I haven't checked the DEC/RA results but it took about 12mins - it needs the Scaling factor IMHO to speed up but I can't find a way in sharpcap to alter that. Might try manual run of Astrotorilla

Link to comment
Share on other sites
Demonperformer

Demonperformer

Posted
  • Author
Posted
20 minutes ago, stash_old said:

Without setting anything in Sharpcap - and just using the Test Controls for the Test Camera your file solved on my PC see attached log

Thanks,  that's brilliant. I will go through it when I am back on the desktop and see if it gives me any hints. 

Link to comment
Share on other sites
Demonperformer

Demonperformer

Posted
  • Author
Posted
2 hours ago, stash_old said:

Ran your image against Astronometry.net and Ra,Dec not the same so looks like a bum hit !!

On 13/04/2018 at 09:04, Demonperformer said:

AT has started not performing as required ... it has placed NAN in the middle of Gemini, with a field size about 1/8 of the actual image.

Interesting - your run has placed NAN slap bang where my version of AT (through Sharpcap) placed it - in the middle of Gemini with field of 2.5 x 2 degrees, instead of about 20x15 deg - that has got to be more than just a coincidence. And it suggests to me that the problem lies more with the image than with the setup.

As I mentioned above, the M42 pic in SC solved perfectly. Think the next step is to find a different image and see if I can solve that.

 

Link to comment
Share on other sites
Demonperformer

Demonperformer

Posted
  • Author
Posted
3 minutes ago, stash_old said:

Converted image to JPG(see attached) then using ASPS it solved (using your 50mm and 3.75um) in 74secs and gave this as the solved image and the dec/ra match Astrometry.net - result

Hmm ... I will have to give that a try on my system. Back in a bit ....

Link to comment
Share on other sites
Demonperformer

Demonperformer

Posted
  • Author
Posted

Well, this looks a little more promising.

Using the complete set of 41xx index files, SC found 49 sources at 15:25:25.8 and solved it at 15:25:28.4 (2.6s). Checked the coordinates and they are right over NAN.

So I guess the problem lies in using a FITS file instead of a JPG file.

Link to comment
Share on other sites
Demonperformer

Demonperformer

Posted
  • Author
Posted

Just for fun, I ran it through with the selection of 42xx index files for this size field: 15:35:19.9 to 15:35:22.9 (3.0s - a whole 0.4s longer).

Next step, run some tests with some other subs. Now I know that the system does work and just how long it should take, I won't go waiting around for hours any more.

Link to comment
Share on other sites
stash_old

stash_old

Posted
Posted
54 minutes ago, Demonperformer said:

Well, this looks a little more promising.

Using the complete set of 41xx index files, SC found 49 sources at 15:25:25.8 and solved it at 15:25:28.4 (2.6s). Checked the coordinates and they are right over NAN.

So I guess the problem lies in using a FITS file instead of a JPG file.

Maybe a case of "cant see the wood for the tree's" when using fits. Still could do with SC letting users change some more paramters - Downscaling as I have said does seem to make a difference. Only glad I dont use "Blind" solving very often.

Link to comment
Share on other sites
Demonperformer

Demonperformer

Posted
  • Author
Posted

Thanks. That was the first one I tried yesterday, but it keeps returning "error during conversion process". Which, considering you got it to work, makes absolutely no sense to me whatsoever. But then, why should this bit be any different??

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Go to topic listing
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.