Vertical swap problem for JPG, TIF,PNG images

[Han K]

Following a long discussion at the Cloudynights forum, I have to report that there is a vertical swap in the astrometry.net  JPG, PNG TIF input.routine. This is not a solver problem but a conversion problem which finally results in wrong reported PA angles for the solved JPG, PNG, TIF images. The produced .NEW file is solved correctly but is upside down compared with the JPG, PNG, TIF input file. Note that for FITS files the convention is that pixel position [1,1] is left bottom. The problem doesn't occur for FITS files as input.

A second vertical swap at the display routine of nova.astrometry.net is hiding the problem for JPG, TIF, PNG input files. This problem occurs in version 0.38 and also the latest version. Using FITS file as input avoids the problem. A sketch for clarification is available at:

https://www.cloudynights.com/topic/638573-astrometrynet-orientation-180-degrees-off/page-2#entry9051312

and attached.

Here two examples on an image -9.4 degrees rotated E of N uploaded as PNG and FITS file:

PNG image upload:

http://nova.astrometry.net/user_images/2586917#annotated

Image is show with the correct orientation as original. Angle is reported as 351 which is correct.  The new-image.fits output is flipped and has orientation -170.6 degrees

FITS image upload:

http://nova.astrometry.net/user_images/2586918#annotated

Image is shown flipped vertical. Angle is reported as +9.4 which is wrong.  The new-image.fits output is equivalent as original with orientation -9.4 degrees

Above is strongly related to the convention that for FITS files, the pixel position [1,1] is left bottom. This is the case in programs as DS9 and AstroimageJ.

[Han K]

No reply up to now. Three people have confirmed the problem, see link to forum Cloudynights. I still think this problem should be addressed.

Han

[Dustin Lang]

It's an open-source project -- please feel free to send a PR at https://github.com/dstndstn/astrometry.net !

My memory is that the FITS standard does not say anything about how the image should be displayed on screen.  In practice it is true that ds9 and other viewers show them with (1,1) the bottom-left corner, unlike JPEG, etc where (1,1) is the top-left corner.

cheers,

--dustin

[Leonardo Parisi]

hi all,

I see that the nova server use the Tycho-2 index.
where it is possibile to download it?

thanks in advance

lenny

[Dustin Lang]

http://data.astrometry.net/4100/

[Leonardo Parisi]

thanks!

so the one in your link are the same used by the nova server.

what about this?

http://broiler.astrometry.net/~dstn/4200/

On Sat, Jan 19, 2019 at 4:12 PM Dustin Lang <dstn...@gmail.com> wrote:

http://data.astrometry.net/4100/

--
You received this message because you are subscribed to the Google Groups "astrometry" group.
Visit this group at https://groups.google.com/group/astrometry.

[Dustin Lang]

The 4200 series are based on the 2MASS reference catalog.

The 5000 series are built from Gaia-DR2.

[Leonardo Parisi]

cool

thanks

 

:)

On Sat, Jan 19, 2019 at 4:57 PM Dustin Lang <dstn...@gmail.com> wrote:

The 4200 series are based on the 2MASS reference catalog.

The 5000 series are built from Gaia-DR2.

[Eric SIBERT]

Please note that I also made a special version of Tycho-2 index using
the "green" band that is more adapted to DSLR:

https://groups.google.com/forum/#!searchin/astrometry/tycho$20green%7Csort:date/astrometry/hGa74stffzE/FpS8EX-sAQAJ

Eric

[Han K]

I checked the latest FITS standard, yes I agree it is not written down in the standard. The problem is that the convention "left bottom is pixel [1,1]" is universal applied for any FITS software program I'm familiar with. If you change it to "left top is [1,1]"  then the Astrometry.net behaviour is mostly explainable but there are still two problems:

1) Have a look to the small east/north arrow drawn in image at: http://nova.astrometry.net/user_images/2586918#annotated It is near IC643

webpage is reporting "Up is +9.42 degrees E of N". However the correct description should be "VERTICAL FLIPPED, up -9.42 degrees E of N" or "HORIZONTAL FLIPPED, up is +170.6 degrees E of N" 

So an angle can not fully describe the image. Flipped should be added if required. Flipped could be distilled out of CD1_1, CD1_2, CD2_1, CD2_2. 

2) A FITS file uploaded is displayed in nova.astrometry.net up-side down compared with any other astrometry program. DS9, AstroimageJ, FV,  and so on.

Regards, Han

[Dustin Lang]

(1) we call this "parity"

[Han K]

For 2), with respect to upside down it is not so black and white as a initially thought. Today I tested "FITS liberator which seems supported by ESA, ESO and NASA. It default shows the FITS bottom/left äs position [1,1] and the "flip image" is default on.

MaximDL and Pixinsight seems to set position [1,1] top left. I assume it depends all on your background. Mathematicians/astronomers seems to prefer bottom/left for [1,1]. Programmers tend to use the convention used by the operating systems.

The FITS standard is not helping.either.

[John Murrell]

Aladin also displays Astrometry.net images as North down - East left and fails when you try to invert the image using the North up - East Left Button.

The North down - East Left Astrometry.Net images are decoded correctly as you can overlay Simbad or other catalogue objects in the correct place.

I have reported this Bug to CDS/Aladin and have an initial partial response but that did not cover the whole problem.

There appears to be something odd in Aladin reading the CTYPE variables in the header as well as the CUNIT variables - I am not sure if this is related or not. Aladin shows the whole line of the header as a variable including the comments.

For people's information CTYPE & CUNIT are related to the projection of the image.

Regards

John Murrell

[Han K]

John, my problem is only with presentation at nova.astrometry.net, not the solver. The solver is fine.

Nevertheless, the format of the keys CTYPE and CUNIT is wrong. The slash "/"  is too early in the 80 bytes key. see red marked up screenshot attached. Maybe some FITS readers have a problem with that.

[John Murrell]

Han,

My problem is with the FITS files produced by nova.astrometry.net. Aladin, DS6 and AstroImage J all show them with North down when loaded.

In terms of the CTYPEn & CUNITn comments looking at the FITS standard at https://fits.gsfc.nasa.gov/standard40/fits_standard40aa-le.pdf all I can find is that the / indicating the start of a comment can be any position after byte 10 (If there is a value field in the row). The examples in the standard have all the comments neatly aligned - most files seem to start with the comment / at Byte 32.

I have tried testing the Astrometry.net fits files with the online Fits format tester and they pass with no problems so either the non-aligned comment / is Ok or they do not test that.

I will let the group know when I get a response from Aladin that indicates what is going wrong. However this is number 4 in my list of outstanding bugs.

John Murrell

[Han K]

Hello John,

I think you have the same problem as I have for JPG, PNG TIF images. See my sketch, problem 1)  The JPG pixel [1,1] top/left ends up in your FITS viewer at the left bottom pixel [1.1]   The argument of Dustin is that there is no definition where FITS pixel [1,1] should be plotted in the viewer. Most viewers plot [1,1] at the left bottom but it is not in the FITS standard.

I still think since the convention is left/bottom is pixel [1,1], so astrometry.net should adapt but that is debatable. There is no standard defined.  Note that you will have no problems for FITS files uploaded to nova.astrometry.net. For FITS files uploaded the output new-image.fit will have the same orientation for you. Only the webpage preview will be swapped (problem 2)).

Thanks for pointing me to the slash(/) indicator position in the FITS standard. I have checked my software and it can handle any position of the slash(/) indicator.

Han