Author Topic: Blind Solver  (Read 43167 times)

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2129
    • View Profile
Re: Blind Solver
« Reply #30 on: 2010 April 23 13:59:16 »
Hi,
wow... I guess that I'll need a whole weekend for an image in my pentium 3 :D

I will not have the time to write about compilation of Blind Solver and the script tonight. Please be patient until tommorow. Just some hints to those already compiling the Blind Solver it:
- Fedora11 with Development profile had all tools required for compilation. No need to add additional packages.
- The netpbm fix in util/makefile.netpbm is also needed for Fedora11
- I got best results if I ran solve-field with the options
Code: [Select]
solve-field --downsample 2 -d 30 picture.jpg I did all of the examples and the small movie with these settings. See http://trac.astrometry.net/browser/trunk/src/astrometry/README for more options.
- Most images solve in well below 60 seconds on a Win7-x64 laptop running Fedora-x64 with 2 GBytes of RAM inside a VirtualBox virtual system.
- The limiting factor appears to be RAM during database access. I guess native Linux systems with more RAM should fly much faster than my setup (estimate: factor 3-10).

More tommorow,

Georg
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2129
    • View Profile
Re: Blind Solver
« Reply #31 on: 2010 April 24 03:59:30 »
Hello,

this article summarized what I learned during the installation of the Blind Solver. It does not have the goal to replace the directions you can find in Blind Solver's README files. It will also not (yet) explain how to install to PI module/script (that's my next article).

- Environment:
-- I did all of my experiments on a Fedora11-x64 system with 2 GB of RAM. This was running inside a VirtualBox environment running on a Window 7-x64 laptop with 4 GBytes of RAM. http://pixinsight.com/forum/index.php?topic=1052.msg10685#msg10685
-- If you want to try a similar setup: VirtualBox is free for private use http://www.virtualbox.org/. Installing Fedora on it is really not difficult if you remember to remove the install-CD after the first reboot. Don't forget to install the VirtualBox Guest Extensions in Fedora.
-- To exchange files between Linux and Windows, you can use the Virtual Box shared folders (there are also other options...)
---Create a permanent shared folder in the Devices Menue of your virtual machine.
---mkdir ~/host # the mount point
---su -
---mount -t vboxsf -o uid=500,gid=500 oeffentlich /home/georg/host
---you can add the mount line to /etc/rc.local so that it is executed on every boot
-- I chose the Development Profile when installing Fedora, and did not need to install additional packages for Blind Solver later. If you need to install packages: everything you need is available via System>Administration/Add-Remove Software.
-- As I see it, Blind Solver should be able to compile on most UNIX like platforms without much trouble, and even Windows seems possible http://pixinsight.com/forum/index.php?topic=1857.msg11350#msg11350.

- Blind Solver installation:
-- Your starting point is http://www.astrometry.net/use.html. Follow the instructions in the README file.
-- Currently, I am using the latest development version (Revision 14686) of Blind Solver, downloaded from the development repository as described in http://trac.astrometry.net/wiki/Subversion , using the http method (svn co -r 14686 http://astrometry.net/svn/trunk/src/astrometry astrometry) . The default 0.25 version available on http://www.astrometry.net/use.htm should work as well.
-- Compilation:
--- Patch util/makefile.netpbm to contain
Code: [Select]
NETPBM_INC ?= -I/usr/include/netpbm
NETPBM_LIB ?= -L. -lnetpbm
--- Patch the main Makefile to contain your desired installation directory, in my case
Code: [Select]
INSTALL_DIR ?= /home/georg/astrometry
--- compile with
Code: [Select]
make; make extra; make install--- add the PATH to the binaries to your PATH variable. In my case, I added this to ~/.bashrc:
Code: [Select]
# User specific aliases and functions
export ASTROMETRYDIR=$HOME/astrometry
export PATH=$ASTROMETRYDIR/bin:$PATH
--- "solve-field" should now answer with the help message.
-- Databases:
--- Blind solver uses "fingerprint" databases to identify stars. You can request access to them as described in http://trac.astrometry.net/browser/trunk/src/astrometry/GETTING-INDICES
--- The README http://trac.astrometry.net/browser/trunk/src/astrometry/README describes which databases make sense depending on the scale of your images, and how to install them (basically a copy to the data directory). In my case, I downloaded the databases including those in index-203*. In effect, all the images I tried solved with databases above and including index-205*, so I could have saved 3 GBytes of my 4 GBytes database download.
--- After downloading the databases into you source directory, it does not hurt to check their integrity using "md5sum -c md5sums.txt"
--- unpack them with with "make install-indexes"
-- All this may seem to be complicated. But compared to other Linux software, it is actually quite straight forward if you have some basic Linux experience.

- Use:
-- solve-field --downsample 2 -d 30 image.jpg usually works best for me. Downsampling increases the success-rate with JPEG images quite a lot.
-- in one example, I had to reduce the brightness of an image using the PI HistogramTransform by moving the midtones slider to the left. Blind Solver sometimes appears to have problems with (near) saturated stars.
-- it worked without problems on unprocessed images
-- using --sextractor as an alternative star extraction tool did not give additional benefits (This tool can be installed via System>Administration/Add-Remove Software, just as many other Linux astronomy tools)
-- runtime is usually <1 minute for solving. It can get larger when it has to go into the index-205* and below databases, since these no longer fits into my RAM file cache (BTW: The Blind Solver web service appears to be running on a 48 GBytes box, so effectively all databases are held in RAM).
--using the --scale-low parameter can reduce runtime a lot, for example if you know that you are solving a widefield shot.

- More information:
-- See the different README/FAQ files in the source tree
-- http://trac.astrometry.net/wiki
-- http://pixinsight.com/forum/index.php?topic=1857.msg11317#msg11317

Cheers,
Georg
« Last Edit: 2010 May 09 14:43:17 by georg.viehoever »
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2129
    • View Profile
Re: Blind Solver
« Reply #32 on: 2010 April 24 04:54:43 »
Folks,

so finally here is the script. It is still not where I wanted it to be, but it is already a very useful tool. I used it (or previous versions) for all the images in this thread, and the Milky Way film.

- Installation:
-- Install the Blind Solver as described in http://pixinsight.com/forum/index.php?topic=1857.msg11360#msg11360
-- Install the SystemCommand module into PI as described in http://pixinsight.com/forum/index.php?topic=1791.msg11361#msg11361
-- Download the Script
-- Install it into PI using Script/Feature Scripts...
-- Done

- Use:
-- Apply it to the current image using the "Apply" button. The default settings work well for me.
-- The GUI (see attachment) is pretty self explaining, and has context help. I have added my most successful command line options to the "Additional Parameters" field, you may need different ones.
-- The "min. Field of View" setting is important to reduce runtime. But all my images also solved with the default setting.
-- "Load diagnostic images" displays the asterism use to solve the current image (plus matched stars during verification). For failed runs it displays the identified stars.
-- The "max compute time" parameter is important if Blind Solver is not successful. It terminates the solving process after the specified amount of seconds. The "Cancel" button does not work yet.
-- The script can be used as part of a process container, and with image containers. That's how I did the video (lazy me... :D )

- ToDo:
-- Cancel does not work. You'll just have to wait for maxTime seconds...
-- The text generated by "Location" sometimes does not have the right scale. Probably needs some fiddling with the text drawing code that I borrowed from the Draw Signature script
-- When used with ImageContainers, it seems to eat memory over time. After 178 images, my Linux systems became unresponsive due to PIs memory consumption. I think that is most likely a PI core problem, but I was not able to drill down to it.
-- The script -no doubt- has bugs...
-- I am sure there are many other creative uses of Blind Solver. One that immediately came to my mind was to help me navigate a non-goto telescope. This is probably something useful for the image aquisition module of PI 2.1.4 http://pixinsight.com/forum/index.php?topic=1809.msg11142#msg11142  ;) .
-- Creative Minds of PI: Unite!

Feel free to use, improve, modify the module as you would like. It is released under GPL 3.

Georg
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline Ioannis Ioannou

  • PixInsight Addict
  • ***
  • Posts: 202
    • View Profile
Re: Blind Solver
« Reply #33 on: 2010 April 24 06:53:15 »
Great job Georg, thank you.
I did not tested the script yet, I have to figure out the installation first, especially about the SystemCommand etc (remember I'm newbie in PI world).

Just a few information regarding the program itshelf:

You are right about the parameters and the time to solve - I did not used any parameters during my tests, thus the big times I reported. So, with the --downsample 2 -d 30 parameters I got 24secs on my Linux box (dualCore@1.6GHz+1GB RAM) instead of 12 minutes (!!!!). On the Cygwin port (DualCore@1.8GHz+3GB RAM,Vista) I got 14 minutes vs about 30 before. Both cases I have indexes from 203 to 219. Not sure why the Cygwin is so slow, and has nothing to do with the roles each machine has (the Linux box is a server running many-many things and has less RAM). I found some posts mentioning that Cygwin may be slow due to Antivirus/Firewall settings etc, but still I can not boost it more by disabling these services - anyway.

A tip about the VirtualBox+Linux image alternative: If somebody does not know/want to install the operating system in the box, you can find free ready Linux images for VirtualBox at http://virtualboxes.org/images/ . If the Cygwin compilation is indeed so slow, and it is not just my setup, then this is a better alternative under Windows.

John
« Last Edit: 2010 April 24 09:08:01 by Ioannis Ioannou »
Clear Skies
John (Ioannis)

FSQ106N+Robofocus+QHY-22+SX USB wheel+Baader filters
SX OAG+DSI Pro guiding a NEQ6
PI for the rest :)

Offline vicent_peris

  • PTeam Member
  • PixInsight Padawan
  • ****
  • Posts: 982
    • View Profile
    • http://www.astrofoto.es/
Re: Blind Solver
« Reply #34 on: 2010 April 24 08:53:02 »
-- Creative Minds of PI: Unite!

Hi Georg, very good work!

I think labeling is not the most important task this tool can do. If the blind solver is able to identify stars in the image, this can be the starting point of a bunch of new tools. Once we have identified all the catalogued stars in the image, we can output a star position list. And this list can be very useful; these are some applications that come to my mind now:

- Cross-identification of stars between Blind Solver and StarGenerator. StarAlignment cannot work properly if there are geometric distorsions between the SG synthetic map and the image. We can say SG to import a star list and force these stars to go to positions designed by the catalog and the defined projection. This can be a rigurous and, at the same time, automatic way to correct geometric distorsions in astronomical images.

- Photometric superflats. If we have brightness data of the stars of the image, we can compare their theoretical brightness with the one IN the image. In this way, we can correct multiplicative errors of flatfielding, or differential atmospheric extinction across the image (for wide fields). This could be a revolution in mosaicing techniques, because once you have corrected any multiplicative error, you really KNOW that any residual error is an additive one.

Other applications of blind solving can be for comets or asteroids. By solving a set of images you can know the center of each one. You can make a very precise track and stack of any comet or asteroid in the FOV. Interpolation algorithms are very good in PI, IMHO. And this could be a step forward repect to other software packages. Another possible use would be the process of an image set to alarm of any moving object in the FOV.


I'm an "idea guy"; now you must type code.  :P


Regards,
Vicent.

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2129
    • View Profile
Re: Blind Solver
« Reply #35 on: 2010 April 24 14:51:18 »
....Not sure why the Cygwin is so slow, and has nothing to do with the roles each machine has (the Linux box is a server running many-many things and has less RAM). I found some posts mentioning that Cygwin may be slow due to Antivirus/Firewall settings etc, but still I can not boost it more by disabling these services - anyway.

I heard that file operations in Cygwin are particularly slow. I did not measure that myself, and I dont know if it is related to Antivirus, just rumors I heard.

Georg
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2129
    • View Profile
Re: Blind Solver
« Reply #36 on: 2010 April 25 08:47:39 »
Hi Vincent,

-- Creative Minds of PI: Unite!
...
I'm an "idea guy"; now you must type code.  :P
...

these ideas sound interesting, although I am not always sure about the details behind them.  I am also not sure how much of catalog information one could/should use to improve images while still claiming they are real photos (ultimately, a BlindSolver++ could just download the best available Hubble shot of the identified region, elliminating problems with light polution and haze once and for all  ;) ). I already felt slightly uncomfortable with the star generator module helping me to stitch mosaics.

Lets see what ideas come up from the other creative minds....

Georg
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline Carlos Milovic

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2169
  • Join the dark side... we have cookies
    • View Profile
    • http://www.astrophoto.cl
Re: Blind Solver
« Reply #37 on: 2010 April 25 10:58:49 »
[creative mode on]... ... beer ... [creative mode off]

:D

Seriously, first I wanna know what kind of information may be outputed by the blind solver. Then we can think on ways to use it. If we have star positions, identified (and their RA/Dec coordinates) there are lots of things we can do. From distortion maps, to intensity correlations. It may be a way to calibrate the flux in photometry calculations, using a few standard stars in the image.

From a less professional point of view, we might create a database of amateur shots, like the DSS, or create spherical charts like google sky... Or, create a tag system that contains all the objects in an image, so an online system may search for other pics with the one you are looking for. Other applications: create automatic crops of the object of interest (and rotations), etc. Draw a orientation compass on the image...
Regards,

Carlos Milovic F.
--------------------------------
PixInsight Project Developer
http://www.pixinsight.com

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 6612
    • View Profile
    • http://pixinsight.com/
Re: Blind Solver
« Reply #38 on: 2010 April 27 02:48:59 »
Hi Georg, John et al,

- The Blind Solver software itself is published under GPL v2, see http://www.astrometry.net/use.html. As I understand GPL, it would not be ok to link this (or derived work) with a close sourced product. And PI is closed source...

I don't see this in the same way. I may be wrong —interpretation of the GPL is always a complex matter—, but let me explain how I understand open-source development on the PixInsight platform, in relation to GPL.

As you know, PixInsight is a modular system. The PixInsight Core application provides just the infrastructure to build an image-processing platform: three user interfaces (command-line, graphical and scripting interfaces) plus an application programming interface to communicate with external modules. The whole processing capabilities are implemented by installable modules in PixInsight. A PixInsight module is a dynamically linked shared object (a .so, .dylib or .dll file on UNIX/Linux, Mac OS X and Windows, respectively) that communicates with the PixInsight Core application through a free, publicly released and fully documented API: the PixInsight Class Library (PCL). A PixInsight module works following the client-server paradigm: the modules are clients and the PixInsight Core application is a server with a known set of resources, which are publicly accessible and can be used by its clients. The PixInsight Core application never works as a client of any PixInsight module.

You can release an open-source software product on the PixInsight platform, just as you can do the same on Windows, Mac OS X or commercial UNIX systems, which are —to greater or lesser extents— closed-source, proprietary operating systems. This is possible thanks to dynamic linkage.

What the GPL license prohibits explicitly is a closed-source software product utilizing a GPL'ed library to implement some part of its own functionality. In other words, a closed-source software product cannot depend on an open-source product released under the GPL. A software product P depends on a software product Q if by removing Q, P ceases to work as P has been defined initially (that is, before the existence of Q). This basically prohibits static linkage against a GPL'ed library, as in such case there is no way to demonstrate that the closed-source product could continue working exactly in the same way after suppression of the GPL'ed library. For example, linking astrometry.net code statically to the PixInsight Core application would force me to release the whole source code of PixInsight under the GPL, for that reason.

However, building a PixInsight module that follows a publicly released, fully documented API (PCL in this case), and releasing it under the GPL, is no problem at all IMO. This is because (i) the PixInsight module uses exclusively dynamic linkage to access the services offered by the PixInsight Core application, and (ii) the PixInsight Core application does not depend on the PixInsight module. You can uninstall a PixInsight module and PixInsight Core can continue working exactly in the same way. Of course, if you uninstall a module, the PixInsight platform, as a whole, ceases to offer the functionality implemented by the module in question, but this does not alter or limit the functionality inherent in PixInsight Core. PixInsight Core is an image processing application, with and without, before and after, the module in question.

From the user's perspective, the GPL says that the user must have the freedom to modify the source code of a GPL'ed software product, to adapt it to his/her own needs, or just to inspect it. The user must also have the freedom to replace a GPL'ed software product with his/her own version without limitations, in the same context as the original product. Both conditions are perfectly fulfilled with a PixInsight module released under the GPL. The question here is the definition of "product": the product covered by the GPL is the PixInsight module in this case, not the PixInsight Core application.

For open-source purists, the only problem could perhaps be static linkage to the PCL. Actually, there should be no legal problem here as the PCL does not depend on the GPL'ed code, and linking statically against the PCL does not change the fact that it is exclusively the GPL'ed module what is using PCL code to implement its own functionality. Anyway, I can release a new version of the PCL with an open-source part and a small proprietary part. The open-source part would be released under a dual GPL/LGPL license (in Qt's fashion), and would implement the whole low-level API for communication between PixInsight Core and PixInsight modules. In this way, open-source modules could be linked statically against an open-source PCL library. In fact, I plan on doing exactly this with PCL 1.1; this would only accelerate a bit what I already want to do.

Having said all this (sorry for the lenghty story), I must say that I would never start a project like this one without the author's blessings.

Quote
The pre-build databases provided by astrometry.net are based on a cleaned version of the USNO-B catalog. The astrometry team apparently gives non-commercial users access if you ask them. The use conditions are formulated in http://trac.astrometry.net/browser/trunk/src/astrometry/GETTING-INDICES. The key sentence here is: ...

As I understand this, it is unlikely that those databases can be redistributed with PI.

Indeed. A hypothetical astrometry.net PixInsight module could not distribute these databases, unless the authors provide explicit permission to do so.

In my opinion, everybody would benefit if some astrometry.net functionality were implemented as a PixInsight module. astrometry.net is the best astrometry engine, which could be used by all present and future PixInsight users. You and Vicent have pointed out some of the many and exciting possibilities that this integration could give rise to. I honestly think that we offer an excellent infrastructure, where astrometry.net would benefit from direct portability to Linux/UNIX, Mac OS X and Windows, a rich and modern user interface, and integration with a solid and evolving platform. Georg's excellent script clearly shows this.

A completely different thing is how difficult this integration could be, in strictly technical terms. It surely wouldn't be the easiest task but, well, we already have done quite a few difficult things with PixInsight...
Juan Conejero
PixInsight Development Team
http://pixinsight.com/

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2129
    • View Profile
Re: Blind Solver
« Reply #39 on: 2010 April 27 10:39:52 »
Juan,

...
However, building a PixInsight module that follows a publicly released, fully documented API (PCL in this case), and releasing it under the GPL, is no problem at all IMO. This is because (i) the PixInsight module uses exclusively dynamic linkage to access the services offered by the PixInsight Core application, and (ii) the PixInsight Core application does not depend on the PixInsight module. You can uninstall a PixInsight module and PixInsight Core can continue working exactly in the same way. Of course, if you uninstall a module, the PixInsight platform, as a whole, ceases to offer the functionality implemented by the module in question, but this does not alter or limit the functionality inherent in PixInsight Core. PixInsight Core is an image processing application, with and without, before and after, the module in question.
...

as we are talking legaleese here, a disclaimer first: I am not a legal counsel, and I am not trained to interpret this kind of stuff correctly. So I may be entirely wrong  :(

I don't think that dynamic linking, the intermediate layer of the GPLed PCL module, the direction of calls or the level of dependency between the software pieces make any difference: There is a close interaction between the PI core and the module. And this appears to be the primary criterium here. See http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins for a discussion of similar cases.

...
Having said all this (sorry for the lenghty story), I must say that I would never start a project like this one without the author's blessings.
...

I think that's the best way to go. The copyright holder of a software can give you any permission he likes, even if he distributes the software under GPL for "ordinary" users.

Georg

Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2129
    • View Profile
Re: Blind Solver
« Reply #40 on: 2010 April 27 11:41:38 »
Carlos,

...
Seriously, first I wanna know what kind of information may be outputed by the blind solver
....

See the attached screenshot for the type of information generated by the Blind Solver. This looks like a pretty complete set of WCS information. It should allow for the use of all those WCS tools (for example http://tdc-www.harvard.edu/wcstools or http://www.atnf.csiro.au/people/mcalabre/WCS/wcslib/index.html) that are available on the web (and pre-build in the Fedora software repository). I am not sure about the Blind Solver's accuracy, its main purpose seems to be to provide a rough solution. But for labeling image it is certainly sufficient. And you can always add a more accurate post-processor.

Georg

PS: My current script throws away most of this information, so there is room for a version 2...
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline vicent_peris

  • PTeam Member
  • PixInsight Padawan
  • ****
  • Posts: 982
    • View Profile
    • http://www.astrofoto.es/
Re: Blind Solver
« Reply #41 on: 2010 April 29 09:18:38 »
Hi,

it would be great if the script outputs a text file with the equatorial coordinates of the center of the images. This would be, through an image container, a valuable tool to make a telescope pointing model.

At my Univ's observatory, we have an altazimuth telescope that can generate a pointing model from offsets measurements. Knowing the altazimuth coordinates of each of the pointing images, we can calculate the altazimuth offsets from the equatorial offsets. So, in case of ouputting a text file with the eq coordinates of each image, we only need an spreadsheet to transform those offsets.

OTOH, if we further develop this tool in the future to completely calculate the pointing model, would make this tool the first direct link between PI and observational instruments. IMO this is a very interesting new way to go.


Could be added, for the moment, the text file output?

Regards,
Vicent.

Offline Carlos Milovic

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2169
  • Join the dark side... we have cookies
    • View Profile
    • http://www.astrophoto.cl
Re: Blind Solver
« Reply #42 on: 2010 April 29 09:25:04 »
IMHO, going into the "instrument operation" field should be "off-limits" for the 1.x series... there is just too much work to do right now :D
Regards,

Carlos Milovic F.
--------------------------------
PixInsight Project Developer
http://www.pixinsight.com

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2129
    • View Profile
Re: Blind Solver
« Reply #43 on: 2010 April 29 09:42:11 »
...
it would be great if the script outputs a text file with the equatorial coordinates of the center of the images. This would be, through an image container, a valuable tool to make a telescope pointing model.
...

Yes, indeed an interesting idea. Only I dont know how I can generate a filename while processing an image container. The image view that the script sees has a more or less random name, if I remember correctly. Is there a way to find the original file name of a view while being called from an image container? Juan?

Georg
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline Carlos Milovic

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2169
  • Join the dark side... we have cookies
    • View Profile
    • http://www.astrophoto.cl
Re: Blind Solver
« Reply #44 on: 2010 April 29 10:02:49 »
Don't have PI here, so I cannot check the PSJR classes... but take a look into something like ImageWindow. The PCL class has the "String  FilePath () const" function, that may do what you want.
Regards,

Carlos Milovic F.
--------------------------------
PixInsight Project Developer
http://www.pixinsight.com