astrometry.net y-axis reversal

fredvanner

Well-known member
When I submit a PI-exported FITS file to astrometry.net, the solved file, when re-imported, has the WCS solution y-axis reversed ("upside down") - e.g. the "annotate image" script displays the annotation in the wrong place. What is the correct workflow for submitting a PI image to astrometry.net and re-importing the result?
 
is your FITS handler set up like this? also the tooltip explains a bit about what is going on.
 

Attachments

  • Screen Shot 2020-06-12 at 6.38.16 AM.png
    Screen Shot 2020-06-12 at 6.38.16 AM.png
    97 KB · Views: 75
Yes, that is how I'm configured (because I think that's how APT writes the files from my ASI camera). If astrometry.net expects the alternative, is there a workflow such that I can change this just while I export / reimport to from a..net - or what? In the short term I used the vertical mirror function on a clone (which overwrites the WCS solution) then used Pixelmath to write the inverted image over the original - which keeps the WCS and give the required result; surely there's a better way!
 
... note: I do all my processing in xisf format - I'm only dropping into fits for compatibility with astrometry.net.
 
well there are "format hints" available in the PI processes that read images from disk. the relevant hints for fits are up-bottom and bottom-up. if you provide a format hint, it will override the setting in the file handler. so one possibility is to flip the setting in the FITS file handler and then always use the opposite format hint when reading in FITS files from your camera. WBPP and BPP also support these format hints via the "up-bottom FITS" checkbox in the UI.

it's too bad you can't override this when saving a fits file, as for your purposes that would be the right solution.

anyway as roundabout as your method is, clearly it works.

the meta question here is - have you tried ImageSolver?

rob
 
And the mesa question would be: why are you using astrometry.net if our astrometric solutions are much more accurate and versatile? The only valid reason I can figure out is that you really need a blind solver, which should never be true if you are solving your own images, or any image where you know one of the objects represented, or any image with acquisition metadata.
 
City centre backyard images at this time of year have high background, so only a few fat, soft stars. I can't make ImageSolver forgiving enough - even with very accurate initial position estimate, but astrometry.net usually manages, eventually. I try to solve because I like to keep an "AnnotateImage" jpg with my images as a quick referene. Are the images really worth it? The M97 image attached is one of the images I has problems with.
 

Attachments

  • M97_WCS_Annotated_lo.jpg
    M97_WCS_Annotated_lo.jpg
    322.8 KB · Views: 48
I have actually found a way to use ImageSolve - but it's more trouble than it's worth:
- use CatalogStarGenerator to generate a synthetic image of the field;
- manually align to my image
- crop to my image
- solve the synthetic image
- overwrite the synthetic image with my image.
... have a large cup of coffee...
 
... don't get me wrong - most of my images solve fine with ImageSolver. It just the soft summer night images that are a problem!
 
Hi Fred,

Could you please upload one of these problematic images, so I can try to reproduce this problem? I doubt the only way to solve these images is by aligning them to a synthetic star field; I've never seen this before. For example, ImageSolver is at the core of our AstroBin+PixInsight collaboration project, where it is working remarkably well even under very strange and borderline situations.
 
How / where can I upload images (the "attach files" option in this forum only accepts highly compressed images, which rather defeats the object)?
 
The attached image is an example. 10 x 240s on M63 (SkyMax 150, f=1800; ASI183MC Pro - but not cooled this time). A typical soft summer night with high background drowning out most of the smaller stars. ImageSolve seems to find the right stars, but fails to solve.
console output:
run --execute-mode=auto "C:/Program Files/PixInsight/src/scripts/AdP/ImageSolver.js"



Processing script file: C:/Program Files/PixInsight/src/scripts/AdP/ImageSolver.js

* Using an automatically calculated limit magnitude of 17.15.



MultiscaleLinearTransform: Processing view: integration_working

Starlet transform: done

Multiscale reconstruction: done

Normalizing sample values: done

575.802 ms

Seed parameters for plate solving:

Image coordinates: RA = 13 14 46.000, Dec = +41 48 24.00

Resolution: 0.272 as/px

Starting StarAlignment iteration



Downloading Vizier data:

http://vizier.u-strasbg.fr/viz-bin/asu-tsv?-source=I/315/out&-c=198.691667 41.806667&-c.r=0.469649&-c.u=deg&-out.form=|&-out.max=200000&-out=3UC&-out=RAJ2000&-out=DEJ2000&-out=pmRA&-out=pmDE&-out=f.mag&-out=a.mag&-out=Jmag&-out=Hmag&-out=Kmag&-out=Bmag&-out=R2mag&-out=Imag&f.mag=<17.15

28574 bytes transferred in 0.94 s @ 29.78 KiB/s

FOV:0.470 actual:0.469

Catalog UCAC3 size: 238 objects





StarAlignment: Processing view: integration

integration:

Structure map: done

Detecting stars: done

45 stars found.

2.737 s

Using the polygon star matching algorithm with 5 sides.



StarAlignment: Processing view: integration

C:/Users/fred/AppData/Local/Temp/stars.csv:

Scanning star data: done

56 stars.

integration:

Structure map: done

Detecting stars: done

45 stars found.

Matching stars: done

21 putative star pair matches.

Performing RANSAC: done

* Previous attempt failed - this is try #2

useScaleDifferences=true

Matching stars: done

9 putative star pair matches.

Performing RANSAC: done

* Previous attempt failed - this is try #3

useScaleDifferences=false

* Reference image: Limiting to 30 brightest stars.

* Target image: Limiting to 30 brightest stars.

Matching stars: done

8 putative star pair matches.

Performing RANSAC: done

* Previous attempt failed - this is try #4

useScaleDifferences=true

* Reference image: Limiting to 30 brightest stars.

* Target image: Limiting to 30 brightest stars.

Matching stars: done

*** 0 star pair matches found - need at least six matched stars.

* Previous attempt failed - this is try #5

useScaleDifferences=false

* Reference image: Limiting to 15 brightest stars.

* Target image: Limiting to 15 brightest stars.

Matching stars: done

*** 0 star pair matches found - need at least six matched stars.

* Previous attempt failed - this is try #6

useScaleDifferences=true

* Reference image: Limiting to 15 brightest stars.

* Target image: Limiting to 15 brightest stars.

Matching stars: done

*** 0 star pair matches found - need at least six matched stars.

* Previous attempt failed - this is try #7

useScaleDifferences=false

* Reference image: Limiting to 8 brightest stars.

* Target image: Limiting to 8 brightest stars.

Matching stars: done

*** 0 star pair matches found - need at least six matched stars.

* Previous attempt failed - this is try #8

useScaleDifferences=true

* Reference image: Limiting to 8 brightest stars.

* Target image: Limiting to 8 brightest stars.

Matching stars: done

*** 0 star pair matches found - need at least six matched stars.

*** Error: Unable to find an initial set of putative star pair matches.

<* failed *>

*** Error: The image could not be aligned with the reference star field

Please check the following items:

  • The initial coordinates should be inside the image.
  • The initial resolution should be within a factor of 2 from the correct value.
  • Adjust the star detection sensitivity parameter, so that the script can detect most of the stars in the image without mistaking noise for stars.
  • The catalog should be matched to the image. Choose the appropriate catalog and magnitude filter, so that the number of stars extracted from the catalog can be similar to the number of stars detected in the image.

*** Error: Unable to plate solve image: Alignment failed

This usually happens because the initial parameters are too far from the actual metadata of the image.
 

Attachments

  • M63_int.jpg
    M63_int.jpg
    700.9 KB · Views: 43
you need to upload your xisf to google drive or onedrive or similar, set the file to shared, and post the link here.

rob
 
Hi guys

I'm new with PixInsight so not shure if this helps in any way, but I've had some problems with PixInsight's internal solver as well. What I've experienced is that PixInsight has no trouble solving my linear images. But after stretching, the very same image could not be solved. So I try to remember solving the Image just before I stretch it :)

Greetings, Roland
 
While I usually have an STF enabled during solving, the image itself is (virtually always) still linear.
 
I am (uncomfortably) aware that the images that cause problems are of poor quality. Really, it would be sensible to give up astrophotography from an urban backyard site a month either side of the solstice, but...
... as an enthusiastic beginner astrophotographer, the past winter in the UK was so abysmal that we have tended to put a telescope up any evening we can see enough stars for an alignment. Since astrometry.net often (but not always) resolves images that fail in ImageSolver (IS), I suspect that some slight relaxation of the IS "give up" criteria would make the difference. Perhaps giving some configurability of the Ransack parameters selected in the script would help (I've found that I often need this with the StarAlign process when stacking these "weak" images).
 
Yesterday I released version 5.4.6 of the ImageSolver script, which you should have received as an update. The new version implements a few changes that make solving these low-SNR images much easier.

This M63 image can now be solved without problems in PixInsight. However, the RA/OBJCTRA and DEC/OBJCTDEC keywords in your original image are wrong by about 15 arcminutes in both axes. Normally this would be no problem at all, but since there are so few detectable stars in this image, these errors prevent calculation of the astrometric solution.

This problem can be solved if you simply search for M63, by clicking the Search button on ImageSolver, to replace image center coordinates with more accurate values. I have used the Gaia DR2 catalog up to 18 magnitude. The rest are default parameters:

m63-solver.jpg


The computed astrometric solution is as follows (geodetic coordinates removed for privacy):

Code:
Image Plate Solver script version 5.4.6
===============================================================================
Referentiation matrix (world[ra,dec] = matrix * image[x,y]):
 -4.22580435e-06  -7.05937739e-05  +1.30949996e-01
 +7.05863333e-05  -4.22845234e-06  -1.75622258e-01
WCS transformation ....... Linear
Projection ............... Gnomonic
Projection origin ........ [2589.883808 1699.946710] px -> [RA: 13 15 49.370  Dec: +42 02 37.98]
Resolution ............... 0.255 arcsec/px
Rotation ................. 86.570 deg
Observation start time ... 2020-04-21 21:25:48 UTC
Observation end time ..... 2020-04-21 22:10:21 UTC
Geodetic coordinates .....   * ** ** W  ** ** ** N
Focal distance ........... 1944.52 mm
Pixel size ............... 2.40 um
Field of view ............ 21' 58.7" x 14' 25.6"
Image center ............. RA: 13 15 49.369  Dec: +42 02 38.01
Image bounds:
   top-left .............. RA: 13 16 31.573  Dec: +41 52 05.26
   top-right ............. RA: 13 16 24.721  Dec: +42 14 01.70
   bottom-left ........... RA: 13 15 14.227  Dec: +41 51 13.66
   bottom-right .......... RA: 13 15 06.930  Dec: +42 13 09.79

You probably know this already, but your telescope's focal length is larger (1944.52 mm) than it is supposed to be (1800 mm).

All of our astrometry tools have been designed and are being developed with accuracy as their main goal. Other implementations aim at 'solving everything', even if the computed astrometric solutions are of poor quality or non-robust, but this is not our philosophy. With its new version 5.4.6, our ImageSolver script is now able to work with the same constraints under even more difficult conditions. More improvements will be implemented in the next 1.8.8-6 PixInsight version.
 
Back
Top