Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Astrometry.net orientation 180 degrees off?

  • Please log in to reply
28 replies to this topic

#26 catalogman

catalogman

    Viking 1

  • *****
  • Posts: 969
  • Joined: 25 Nov 2014

Posted 02 January 2019 - 03:21 PM

Your sample image goes too deep to solve with the smaller indices that I've built. But it's easy to show the OP's problem with Astrometry.net by using another image.

 

The attached screenshots show a sample image of mine solved by AstroImageJ/ansvr (top) and a Linux build of Astrometry.net (bottom). The solved .fits files are then displayed in ASTAP.

 

The second screenshot shows the problem reported by the OP: the Astrometry.net solution flips the image in the x-axis (not a rotation of 180 degrees). This is why alternative plate-solving apps like ASTAP and ASCfit are needed.

 

--catalogman

Attached Thumbnails

  • AstroImageJ_ansvr.JPG
  • astrometry_dot_net.JPG


#27 han59

han59

    Mariner 2

  • *****
  • Posts: 223
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 03 January 2019 - 04:33 AM

Now it becomes clear. The problem (1) lies in the astrometry.net JPG, PNG, TIF conversion routine, not in the solver. Strange enough there is a second vertical swap (2) in the display routine of the web-page nova.astrometry.net resulting in no visual swap and hiding the problem for JPG, PNG TIF only. Working in FITS avoids the problem. I made a sketch for clarification. I will report it.

 

solver swap.png

 

Han

 

Later:

Problem posted at https://groups.googl...try/0mOt13k-MW0


Edited by han59, 03 January 2019 - 04:55 AM.

  • jdupton, Michael Covington and catalogman like this

#28 catalogman

catalogman

    Viking 1

  • *****
  • Posts: 969
  • Joined: 25 Nov 2014

Posted 04 May 2019 - 12:42 AM

In the most recent version (v0.78), this problem has not been fixed.

 

As a test, I installed v0.78 in Debian 9.8.0 and applied solve-field to the same .jpg image used in Post #26 above.

 

Then I opened the solved image in GIMP -- the extension is .new but GIMP knows it is a .fits and imports it. The view is upside-down and backwards, exactly as in Post #26.

 

Next, I copied the solved .new image to .fits and opened it in QFitsView. The result was the same: an upside-down, backwards image.

 

For you, the observer, this means that even in the most recent version you cannot pass a simple .jpg to solve-field -- you must be careful to always pass a .fits. This bug has existed since at least v0.38 (the version used by Astrotortilla) and about seven years later it remains uncorrected.

 

The question is: does anyone know where to report this? (And please don't suggest Google Groups -- Han's report and careful analysis there have been completely ignored.)

 

--catalogman


Edited by catalogman, 04 May 2019 - 12:43 AM.

  • Michael Covington likes this

#29 han59

han59

    Mariner 2

  • *****
  • Posts: 223
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 04 May 2019 - 01:57 PM

Catalogman,

 

I also opened an issue at GitHub:

 

https://github.com/d....net/issues/151

 

 

It is still open, but maybe it helps if you add your thoughts. The debate could stall since the orientation of FITS files is a convention not a standard so Dustin may do nothing.

 

Note there are many other issues open. Not much happening.

 

Han




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics