Blind Solving

In blind solves we have little to no idea where the field center is, and so we must search the entire sky to find out the coordinates. This is what makes it so much slower than nearby solves.

Blind parameters

Minimum parameters example:

watney-solve blind --image andromeda.png --min-radius 0.5 --max-radius 8

You may also just run watney-solve blind to get the list of available parameters.

For reference, the parameters available in blind solve are:

Parameter	Description
--min-radius	Required. The minimum field radius (in degrees) the solver may use in search. Must be > 0.
--max-radius	Required. The maximum field radius (in degrees) the solver may use in search. Must be <= 30. Search starts at max radius, and radius is divided by 2 until min-radius is reached.
--east-first	(Default: true) Scan Eastern side of the sky first.
--west-first	(Default: false) Scan Western side of the sky first (overrides east-first).
--north-first	(Default: true) Scan Northern side of the sky first.
--south-first	(Default: false) Scan Southern side of the sky first (overrides north-first).
-p, --use-parallelism	(Default: true) Use parallelism, search multiple areas simultaneously.
-i, --image	Required. The image file to solve.
--sampling	(Default: 1) Use a preliminary search run with sampled quads. With sampling, we will not get all the potential quads from the database, we only get 1/ quads for which we run the first search round. This means less quads to compare to, which means less time spent in comparisons. If no solution is found with sampling, then all best candidate areas with any quads found will get searched without sampling. Finally if the best candidates give no solutions, we search the rest of the areas without sampling. In best case scenario, this can significantly shorten the blind solve times. In worst case scenario, it will extend it by a margin. Best reliably faster results are achieved with values 4..8.
--out-format	(Default: json) Output format. Valid values are 'json', 'tsv'.
-o, --out	Output file. If not set, output will be printed to stdout.
-x, --lower-density-offset	(Default: 1) Include this many lower quad density passes in search (compared to image quad density).
-z, --higher-density-offset	(Default: 1) Include this many higher quad density passes in search (compared to image quad density).
--extended	(Default: false) Produce extended output. This will print out a lot of additional detail about the solve.
--log-stdout	(Default: false) Verbose logging. If true, will log a lot of additional lines to stdout.
--log-file	(Default: ) Verbose logging. Give a filename to print verbose log lines into a file.
--use-config	Path to configuration file. By default tries to load watney-solve-config.yml in the same directory where the solver is.

By setting --south-first and --west-first you can prioritize west and/or south over the default north/east first behavior.

The output

The standard output (non-extended) as JSON looks like:

{
  "success": true,
  "ra": 10.723095695998863,
  "dec": 41.25033946510212,
  "ra_hms": "0 42 53.54",
  "dec_dms": "41 15 1.32",
  "fieldRadius": 1.8673415850842443,
  "orientation": -61.81787691614857,
  "pixScale": 2.397351285596479,
  "parity": "flipped"
}

Where:

• success: true or false
• ra: the RA coordinate as decimal degrees
• dec: the Dec coordinate as decimal degrees
• ra_hms: the RA coordinate as Hours Minutes Seconds
• dec_dms: the Dec coordinate as Degrees Minutes Seconds
• fieldRadius: the field radius in degrees (imagine a circle drawn around the image's widest corners)
• orientation: the field orientation in degrees
• pixScale: pixel scale, in arc seconds per pixel
• parity: whether the image is flipped (mirrored, value "flipped") or not (value "normal")

The TSV output is plain key-value strings, with key and value separated by a tab character ('\t'):

success true
ra      10.723095695998865
dec     41.25033946510212
ra_hms  0 42 53.54
dec_dms 41 15 1.32
fieldRadius     1.8673415850842499
orientation     -61.81787691614857
pixScale        2.397351285596486
parity  flipped

The extended output (--extended flag) gives out some more information:

{
  "success": true,
  "ra": 10.723095695998865,
  "dec": 41.25033946510212,
  "ra_hms": "0 42 53.54",
  "dec_dms": "41 15 1.32",
  "fieldRadius": 1.8673415850842419,
  "orientation": -61.81787691614857,
  "pixScale": 2.397351285596476,
  "parity": "flipped",
  "timeSpent": "00:00:00.4559659",
  "searchIterations": 2,
  "searchRunCenter": "[10.7, 41]",
  "searchRunRadius": 3.0,
  "quadMatches": 168,
  "fieldWidth": 2.9827045578296154,
  "fieldHeight": 2.247516830246696,
  "fits_cd1_1": 0.0003144047999479153,
  "fits_cd1_2": -0.0005871847097447616,
  "fits_cd2_1": 0.0005869984562423269,
  "fits_cd2_2": 0.0003146098369413153,
  "fits_cdelt1": 0.0006658960623559533,
  "fits_cdelt2": 0.0006661570632052782,
  "fits_crota1": -61.81787691614857,
  "fits_crota2": -61.825858880383215,
  "fits_crpix1": 2238.9011931383843,
  "fits_crpix2": 1686.9827798740419,
  "fits_crval1": 10.723067825946227,
  "fits_crval2": 41.25027604788231
}

• timeSpent: time spent on the solve
• searchIterations: how many areas were searched
• searchRunCenter: the center coordinate of the search run that produced the result
• searchRunRadius: the field radius that was used in the above search run
• quadMatches: how many star quads matched
• fieldWidth: the width of the field, in degrees
• fieldHeight: the height of the field, in degrees
• fits_cd1_1 .. fits_cd2_2: for FITS, rotation and scale matrix
• fits_cdelt1..2: for FITS, coordinate increment along axis n
• fits_crota1..2: for FITS, coordinate system rotation angle
• fits_crpix1..2: for FITS, pixel coordinates of the reference point to which the projection and the rotation refer
• fits_crval1..2: for FITS, the center coordinate as right ascension and declination or longitude and latitude in decimal degrees

Additionally, the WCS file (an empty FITS file) that contains the WCS headers can be saved using the --wcs <filename> parameter.

Performance considerations

The performance of the blind solve stems from the three main factors:

• How many searches needs to be performed
• How many quads need to be compared when finding matches
• How fast your CPU is

When you divide the sky sphere to search areas, the larger the areas, the less areas we have to search. So blind solves with large min-max radius are naturally faster. The tinier the field radius gets, the more searches we need to perform.

When finding matches, we have the option of picking the closest available quad density pass (compared to the image's quad density) from our quad database and trying to find matches from that - or to not limit ourselves to just one pass, and instead include one or more lower or higher density passes to potentially find more matches. While this will increase our chances of finding matches, at the same time it increases the number of quad comparisons we have to make, slowing down our search. So it's a tradeoff, perhaps with just one pass we may not find a solution, but with 2-3 passes we find it.

Finally, what kind of CPU we have available makes a big difference. A modern desktop PC with a good multi-core processor performs significantly better than an old PC or a SOC device like Raspberry Pi. The difference can be literally 1000% between a new PC and Pi4B for example.

How it works

The technicality is described in more detail in BlindSearchStrategy.