different plate solving methods give different results

[pascal]

Hello,

on last nightly build version (14), it seems that platesolve 2 give different results compared to the other plate solving methods, angle is different (can be problematic) and frame seems also to be uncorrect. Astrometry local and ASTAP produce both same results.

ASPS doesn’t work with my fits files but this seems to be due to ASPS itself.

Regards.

Pascal

[pascal]

Hello,

sorry for the late answer (work away from Internet), no I uploaded the good images, you can see that the angle and the frame found by PS2 are different, I have not yet tested the result on the sky (wrong rotation value can be dangerous for the equipment), it seems that astap and astrometry give the good result (339deg) while ps2 found 200deg, but I may be wrong.

Thanks.

Pascal

[pascal]

just a question, is the image processed by PS2 down scaled? I find that the stars detecting time is a bit long.

[pascal]

Hi,

here are three annotated screenshots, may be there is something that I do not understand but the plate solving results are different depending on the solver used. Frame and angles are different. May be it would be useful to have the possibility to zoom forward a bit in the image to see the frame after solving (in my case the frame is far bigger than the image size (I saw that trying to translate the frame). All help will be welcome. Thanks. Pascal

‌

[Stefan B]

Hi,

the framing from a file issue where the rectangle is sized incorrectly was already identified and fixed for the next nightly build.

The orientation is a different issue that needs further investigation.

[pascal]

ok, thank you, if you need more test do not hesitate to ask me.

Regards.

Pascal

[Han K]

An angle of 200 degrees is compatible with an angle of 339=340. 200 is 20 degrees from 180. 340 is 20 degrees from 360. My guess the problem is that the FITS format is solved vertical swapped. PS2 angle reporting is not effect by a vertical swap (strange but true). Only the reported x/y ratio becomes negative.

Local Astrometry.net and the online version give both the same vertical swap error. So Astrometry.net sees also pixel 1,1 at left bottom. So the solution angle has to be swapped vertical or two of solution matrix factors CD1_1, CD1_2, CD2_1, CD2_2.

Han

‌

[Han K]

To flip the solution vertical, you have to negative CD1_2 and CD2_2 values.

To experiment, you could use ASTAP to flip FITS files vertical and horizontal. See viewer, tools, rotate. The solution in the header is adapted to the flip.

[pascal]

Hello Han,

thank you for these explanations, after testing, I confirm that vertically flipping the image (and re-saving it ) with astap does not change anything in Nina (same image aspect and same solved angle), horizontal flipping gives an angle of 20° (and flipping is visible in Nina). I don’t know what to think about these results … only that I would like to know what method is reliable in the real conditions just to avoid important problem with cable if rotating in wrong direction ….

Thanks.

Pascal

[Han K]

Hello Pascal, flipping the input file will not help. The vertical swapped solution will still be created. My suggestion was more for the programmers to create several test files. Somebody has to look into the code. but C# is not for me.

Han

[pascal]

ok, thank you, I hope a programmer will read your answer … C# is not for me too

Pascal

[Stefan B]

Hopefully most orientation issues are fixed in nightly 26

[pascal]

Hello,

thank you it seems to be working now, all the plate solver give the same result (same as PS2 before the bug was corrected).

Now I have to test it in the sky…

Regards.

Pascal

[Han K]

Good news!

Regards, Han

‌

[pascal]

Thank you Han,

just a question, is there a way to say to Nina to use the coordinates from the fits header as first approach to solve the image? I use stellarium as planetarium to get the coordinate befor solving but it would be more quick and easy to use the data from the fits header.

Regards.

Pascal

[Han K]

That’s what ASTAP is doing. It looks to the mount position as recorded in the FITS header. From that position it is search in a square spiral around it. So the solve time is roughly the square (=surface) of the offset. If it would do a full blind search the solution could take minutes.

‌

[pascal]

ok, as Nina display empty reference coordinates (“no coordinates available”) when I load an existing image, I though that the fits header information was not used. May be the coordinates field should be populated with the fits header information from the loaded image?.

Thanks.

Rgards.

Pascal

[Han K]

Yes populating the reference coordinates with the position from the loaded fits is what I would expect from Nina. I don’t use Nina, maybe Stefan could comment on this.

[Ross Walker]

Whenever I load a Fits file that contains RA and Dec info, NINA ignores those “hints” and uses whatever happens to be entered in the UI at that time (usually the coordinates of a previously searched target). Thus the hints are way off, PS2 fails as expected, and Astap takes many minutes to solve (but it does correctly solve though). So I agree that hints from a loaded image file should be used over those entered in the UI. Another, perhaps better, alternative would be to allow the user to choose which hints to use in the pop-up, i.e, the file hints, the UI hints, or none at all.

‌

PS this issue is market “resolved” so a new ticket may need to b opened.

[Stefan B]

Currently No Meta Data is read at all. This will be enhanced in the Future and there is already an issue for it available. Until then the reference coordinates need to be entered manually prior to loading the file

[Ross Walker]

This will be enhanced in the Future

This is good news. Thanks for the update Stefan.

[pascal]

Hello, Ross, for the moment you can use the button ‘get the coordinates from the planetarium software’ (after having selected the good object), this populates the coordinates fields and also starts the Nasa sky survey search, you stop it and switch again to the ‘file’ image source and load the corresponding image, and then it should be work quickly after validation of the coordinates.

A bit long but usable waiting for the improvements to come.

Regards.

Pascal

‌