Feature request: add a North/East arrow to annotated images

[han-k59]

Maybe not the correct place for nova.astrometry.net. If not please delete this issue:

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

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-k59]

See https://groups.google.com/forum/#!topic/astrometry/0mOt13k-MW0

[han-k59]

The AVM standard 1.2 rc1 at https://www.virtualastronomy.org/avm_metadata.php has documented the orientation convention. See attached screenshot

[dstndstn]

If I recall correctly, FITS says nothing about how images are displayed. (1,1) is the first pixel in the file, but the standard says nothing about how images should be shown to the user. We do the simplest conversion of other image formats to FITS, ie, no flip. It is quite possible that the reported orientation is backwards in some cases; it's not totally trivial to compute.

[dstndstn]

PS, near as I can tell, AVM is a dead project.

[davidwhogg]

AVM was never agreed to by the community. And indeed the FITS standard has no display advice. So let's change the title of this issue.

[han-k59]

No problem, I will try to close the issue.

[han-k59]

I'm sorry but I have to reopen this. The same file uploaded to nova.astrometry.net as PNG or FITS (with 1,1 origin left top) gives same annotated result but with a totally different angle reported! This clearly indicates the original problem. Please have a look to the two screenshots:

[dstndstn]

yeah, like I said, it's just an error in the reporting.

It comes from here
https://github.com/dstndstn/astrometry.net/blob/master/net/templates/user_image/view.html#L182

which calls
https://github.com/dstndstn/astrometry.net/blob/master/net/models.py#L685

which calls
https://github.com/dstndstn/astrometry.net/blob/master/net/models.py#L647

Where, I suppose, we are assuming some display convention for FITS images when we say "up".

Your claim is that we should remove the different handling of PNG vs FITS?

[han-k59]

I think an numerical angle indication will always lead to confusion since as you said ,,displaying is a convention and not a standard". For me the best approach would be to show the orientation with a North-East arrow pointer. East will indicate flipped. Like the small red north-east arrow in this screenshot:

[han-k59]

If you would add a north-east pointer to the annotation routine it would be beneficial for both nova.astrometry.net and the program itself. Something like this:

[davidwhogg]

I think this should close and re-open as a feature request for a N-E arrow.

[han-k59]

David, it's a BUG issue, not a feature request!

Note that yesterday by the two screen shots it was proven that there is a bug in the orientation reporting of nova.astrometry.net. It reports for the same image with identical annotations different numerical orientations for FITS and PNG/TIFF/JPEG.

A quick fix would be to change the code as Dustin indicated yesterday.

In my humble opinion, after the fix the orientation reporting will still be unclear and undefined. The proposed North/East arrow is just one way to fix both the bug and improve reporting.

p.s. the cause of the bug was indicated by the previous title. There is an inconsistency in handling vertical orientation for two different images types :)

Han

[dstndstn]

It's a bug report (orientation is ill-defined), with a proposed fix of removing the orientation report --- which people will complain about --- and replacing it with a N/E arrow.

If you want to do something useful you can look at implementing this -- it would get added to the blind/plotannotations.c file, similar to plot_targets. I'm not saying it will be easy.

[han-k59]

I would have no problem to add something, but unfortunately I'm not familiar with C. But attached my code in Object Pascal for a N/E pointer which could give some ideas and shows the math:

N_E pointer.zip

Showing this:

Han

[davidwhogg]

Yes I agree it is a bug if we refer to "up" or "left" in our reporting, since there is no "up" in a FITS image.

[mgreter]

I'm currently facing this issue (I think) as I'm trying to integrate some pictures of messier objects into a stellarium like web-application. So in order to do this more efficiently I'm using astrometry to create the data to position these correctly. During my tests I found out that I only need to flip the y axis of the texture to get correct results for flipped images (the stars match up very nicely).

I didn't really fully grasp the previous discussions. It looks to me that astrometry can match flipped and non-flipped images (I suspect it tries both renditions?). So for me it would be ideal if astrometry would tell me which one actually matched. For the time being I have to visually check each one to see if I need to apply the y-axis inversion (I will probably end up to just flip the actual images as needed).

I've used M17 and M18 to verify this. AFAICS rotation is not enough to get these two aligned and one actually has to do the flip to match up these two images with background stars.

[han-k59]

mgreter,

There is absolutely no problem with the astrometry.net solution in the FITS file. So the FITS header values cd1_1, cd1_2, cd2_1, cd2_2 values are always correct. There is only an undefined up or down related to the angle reporting in the web interface at nova.astrometry.net. It depends if you upload FITS or PNG, TIFF,JPEG. The behavior is consistent so once you now how to flip your fine.

If the images have a rotation angle other then 0 or 180 degrees, you have to use the cd1_1, cd1_2, cd2_1, cd2_2 values.

Han

[dstndstn]

Hi, Independent of the FITS/JPEG vertical flip that Han is talking about, there is "parity". If you flip an image (swap x/y axes, or flip horizontally or vertically), that flips the parity. You can compute that as the sign(det(CD matrix)), and that should match your by-eye determination of whether you need to flip or not. Eg, this code, https://github.com/dstndstn/astrometry.net/blob/777f7928479dc15e11912bee0f24930609bc1268/net/wcs.py#L73 where you can also see how we compute the orientation angle that is reported. cheers, --dustin

…

On Sat, Dec 7, 2019 at 7:48 PM Marcel Greter ***@***.***> wrote: I'm currently facing this issue (I think) as I'm trying to integrate some pictures of messier objects into a stellarium like web-application. So in order to do this more efficiently I'm using astrometry to create the data to position these correctly. During my tests I found out that I only need to flip the y axis of the texture to get correct results for flipped images (the stars match up very nicely). I didn't really fully grasp the previous discussions. It looks to me that astrometry can match flipped and non-flipped images (I suspect it tries both renditions?). So for me it would be ideal if astrometry would tell me which one actually matched. For the time being I have to visually check each one to see if I need to apply the y-axis inversion (I will probably end up to just flip the actual images as needed). I've used M17 <https://en.wikipedia.org/wiki/Messier_17> and M18 <https://en.wikipedia.org/wiki/Messier_18> to verify this. AFAICS rotation is not enough to get these two aligned and one actually has to do the flip to match up these two images with background stars. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#151?email_source=notifications&email_token=AAIEH7NKYJIO7LVL5YT7HBDQXQ75ZA5CNFSM4GRFJDK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGS7BI#issuecomment-562900869>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIEH7IKQ6Z473Y2RGOQOF3QXQ75ZANCNFSM4GRFJDKQ> .

[sebagr]

I'm joining this thread from https://groups.google.com/g/astrometry/c/glVFictwNV4/m/2qAIP4frAgAJ - thanks Dustin for pointing me in the right direction!

Since the Position Angle is useless without knowing the image parity, I think instead of removing the reported PA (which I agree would cause complaints) a better idea would be to also display the parity on the website.

Of course this doesn't fix the bug that JPG-ish images have a different PA than FITs as shown in han-k59's comment. Just for future reference, I uploaded this annotated image then flipped it vertically and horizontally to see the results, and in all of them the PA seems to be West of North.

http://nova.astrometry.net/user_images/3946751#original
http://nova.astrometry.net/user_images/3946752#original
http://nova.astrometry.net/user_images/3946753#original

[han-k59]

A north east pointer placed as an annotation is in my opinion the best and clearest solution. I already provided an example code in Pascal showing the math. Attached two more screenshots showing the implementation in Aladin and PlateSolve2

[sebagr]

I agree, adding a North-East annotation would be definitely clearer than the PA + parity alone. Then again, I don't see any value in hiding those numeric values if they are available.

[alexw-im]

I'm struggling right now to figure out how my issue relates to this one, since they certainly seem the same but there are lots of mentions of FITS files which fundamentally I haven't been using.

Take this sample image. It's an export of a star map from Cartes du Ceil with Beta Persei dead center, in equatorial mode so north is perfectly up. For the sake of disambiguation, I've rotated it 14.59* CW, i.e. image-up is 14.59* WEST of north, or 345.41* E of N.

Solved with nova.astrometry.net, these aspects are all reported spot-on. Interestingly, if I download new-image.fits, it's 1) flipped 2) blank 3) indicated north is ~180deg off.

HOWEVER: When solved offline, with astrometry running locally on my machine, I get the following stdout:

Field 1 solved: writing to file ./beta perseus +14.59.solved to indicate this.
Field: beta perseus +14.59.png
Field center: (RA,Dec) = (47.045647, 40.958294) deg.
Field center: (RA H:M:S, Dec D:M:S) = (03:08:10.955, +40:57:29.857).
Field size: 9.15707 x 7.13041 degrees
Field rotation angle: up is -167.126 degrees E of N
Field parity: neg

That is, the true rotation is (180-reported).

If I flip my input image about X or Y before processing, I get the approximately-correct angle, but negated. So it seems not quite as straightforward as "it gets flipped somewhere in the pipeline."

Did something change since 2020, like the nova.astrometry.net presentation code was just changed to say "up is 180-calculated" as I've done?

Edit:
I also should have remembered to upload the actual sample!

[dstndstn]

About the new-image.fits file -- when converting JPEG or PNG to FITS, there is a choice of whether to flip it vertically or not -- because JPEG defines the first pixel to be the top-left pixel, while FITS does not specify a display order, but DS9 and other programs often show the first pixel in the bottom-left. The Astrometry.net code does not do that flip -- first pixel stars first pixel -- so that can introduce a flip in the orientation.

As for it being blank ... what program are you using to display it? It might be scaling the image in a funny way.

And yeah, I think the web version has some special handling to report things correctly for JPEG images vs FITS.

The reason this feature request is to add a North/East arrow to the image is because all this "degrees east of north" business is so fraught.

[alexw-im]

Ahh yes apologies, I should have specified that - ASTAP to view the FITS file. And in fact you're right, it was just a display issue - Astrometry's output seems to threshold/bin the color outputs into very sharp spikes in the histogram, and ASTAP's min/max weren't inclusive of them before some sliding.

Anyway what's REALLY curious now that I see the image is that:

• ASTAP's view isn't mirrored or flipped or rotated compared to the input .png and Nova's rendering
• ASTAP's 'north' arrow is pointed quite correctly
• ASTAP claims the image is flipped (it certainly doesn't seem to be!)
• ASTAP's degrees of rotation is off by a negation AND 180deg. Specifically it indicates 167.15 deg E of N. Maybe because it thinks the image is flipped when it's not?

Thank you for helping me wrap my head around what's going on! I certainly agree that there's lots of logical room for error with the "degrees east of north" thing but it still feels like the most intuitive way to present that information to a user trying to orient themselves in the celestial sphere. An overlay compass would certainly be a good cross-reference for what that angle MEANS.

[han-k59]

• ASTAP claims the image is flipped (it certainly doesn't seem to be!)
• ASTAP's degrees of rotation is off by a negation AND 180deg. Specifically it indicates 167.15 deg E of N. Maybe because it thinks the image is flipped when it's not?

If the F is indicated near the north-east arrow then it is flipped according the convention first pixel left bottom. You most likely have in ASTAP the "view flipped". Look to settings under pull down menu "View". A flipped image combined with flipped view is not flipped.

• logical room for error with the "degrees east of north"

Just draw a north/east arrow on a piece of transparant paper/folie or glas. Then flip it horizontal or vertical and record the angle.

East is the direction where RA increases. North is the direction where the declination increases. A solid definition for a north-east indicator

Han

[alexw-im]

Yep, you're right, ASTAP was previously set to display flipped. So the .FITS I downloaded from nova is, in fact, flipped compared to the input.

East is the direction where RA increases. North is the direction where the declination increases. A solid definition for a north-east indicator

This was actually super helpful for me conceptualizing my orientation, thank you! I think that distinction is counterintuitive if you're used to looking down at a map vs looking up at the sky.

[sebagr]

This was actually super helpful for me conceptualizing my orientation,

thank you! I think that distinction is counterintuitive if you're used to looking down at a map vs looking up at the sky. It is so counterintuitive indeed! What helped me fully grasp this concept a few years ago is visualizing that we look down at a map (Earth) from the outside, but we look at the sky from the inside of the "celestial sphere". I hope this outside/inside perspective can help somebody else too :)

…

On Fri, Jul 28, 2023 at 3:25 PM alexw-im ***@***.***> wrote: Yep, you're right, ASTAP was previously set to display flipped. So the .FITS I downloaded from nova is, in fact, flipped compared to the input. East is the direction where RA increases. North is the direction where the declination increases. A solid definition for a north-east indicator This was actually super helpful for me conceptualizing my orientation, thank you! I think that distinction is counterintuitive if you're used to looking down at a map vs looking up at the sky. — Reply to this email directly, view it on GitHub <#151 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARGRFYZGIQYCE5ZUGPS3VTXSP72FANCNFSM4GRFJDKQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>