Feature: navigation by looping.

[han-k59]

The app would allow navigation by solving. Suggest the following feature

Create a loop doing the follwing:

1) Enter a target position or target name 2) Take an image 3) Solve it and display the offset from the target position. Indicate by arrows how much the telescope has to move in Ra, DEC to reach the target. 4) Go to 2) unless a manual stop is given.

[artyom-beilis]

Actually I give the change in RA, DE and Alt, AZ. So if you have controls for manual movement by offset in your mount you can do it manually.

To do this automatically I need to start talking to mount. This feature exists in most AP/EAA software like SharpCap, NINA, Ekos. But this requires significant effort and adding something like indi or alpaca mount drivers for android and it may not be that easy.

It is lots of work to do.

[han-k59]

Good I haven't seen this. Does it loop? Looping would be helpful.

Manual control of the mount is fine for me.

[artyom-beilis]

Good I haven't seen this. Does it loop? Looping would be helpful.

What do you mean loop? You can press Restart and Solve again to rerun the sequence.

Biggest problem so far that in order to get a solution I need quite a lots of stars. With my 60mm/400mm under Bortle 8 and 224MC I frequently need to stack 5-6 images to get a data that is good enough for the solver.

[han-k59]

Looping by statement 4) Go to 2)

If you use the application with a Dobson telescope, your are pushing and pulling the Dobson manually. Then it will be convenient that the application run by itself and tell every 5 seconds where it is pointing to. Displaying the solved values and offset with a large font will be beneficial. It should be readable from maybe up to 2 meters distance

I'm using my current 100 mm APO, FL=560 mm I will also test it with a 50 mm lens. Solving of 1 seconds exposures or less should be easy with any telescope. It should also work with your 224MC. Maybe the 224MC sensor size, uncooled, colour version are handicaps. But the sensor should be good enough. If you can share some short single exposures, I can have a look why solving is problematic.

[han-k59]

Got is solving now :)

The arrow is good. Delta are not very understandable. See screenshot

I would expect something like this with a large font:

ΔRA 0.65° ΔDEC 0.25°

ΔAZ ?° ΔALT ?°

A visual indication with a small rectangle representing the FOV combined with an arrow would be also be nice. Something like this:

[han-k59]

Or this:

[han-k59]

I looked into the manual:

_Install/download astap_cli (or normal astap) and download one of the recommended databases:

D05 - smallest database (~100M) that fits cases when camera FOV is ~0.5 degree or larger
D20 - large database (~400) that fits smaller image sizes
V17 - older database format largest_

The V17 is now obsolete. I would suggest to add something like:

For astrometric solving download and install also one of the star databases based on your field-of-view (fov):

 D50      (10 > fov > 0.2 degrees)
 D20      (10 > fov > 0.3 degrees) 
 D05      (10 > fov > 0.6 degrees) 
 G05      (20 > fov > 1.0 degrees) 
 W08      (       fov > 20 degrees) 

[artyom-beilis]

Thanks. updated

[artyom-beilis]

Hi,

I'm trying to understand why plate-solving fails.

Attached a zip with 3 tiff files and command line I run it with. Each of the images are solvable by Astrometry.Net but not ASTAP. m1 and m82 sometimes I can solve if I do stacking of multiple frames. But it is highly unreliable.

All are ASI224MC, pixel size=3.75um, FL=400, I put the command lines with all the parameters I run with into the zip.

Can you please look into and see what and if something can be done?

astap.zip

[han-k59]

Sorry for the late response. I missed your last comment.

One of the problems is the conversion to colour. This tends to smear out the hot pixels. A single hot pixel is ignored but the debayer will spread it to several pixels making look like a star. It is better to feed ASTAP the raw image.

Solving with ASTAP will not work. I had the images solved in nova.astrometry.net and loaded the solved image in ASTAP. Then annotated the detected stars (red square) and annotated the stars based on the database (yellow circles). You see then some detection's are false. Feeding the raw image to the solver will work better (as cooling). So:

1) Feed the solver with a raw image 2) Expose longer.

See attached annotated image of M1

The uncooled camera an poor skies do not help either but that is not changeable.

p.s. I mentioned your program (still waiting for moderator) for navigation usage in this discussion . https://hackaday.com/2023/03/16/dobsonian-telescope-adds-plate-solver/

[artyom-beilis]

Feed the solver with a raw image

You mean before de-bayer? Would it manage to handle pixels with non-uniform "checkers" pattern?

[artyom-beilis]

Is there a way to provide "bayer pattern" information in tiff or you aren't going to use it anyway?

[han-k59]

Yes I expect it will work better with raw image before de-bayer. If the checker pattern is strong, I could apply the a special filter. This is not yet implemented because in most cases binning is better and most camera have a larger resolution then yours. But your camera resolution is only 1305x975 so low. Then binning of your 1305x975 images will make solving work less well. Send me one or two raw files to test.

Battern pattern is written in the header as:

BAYERPAT= 'RGGB' / Bayer color pattern
or BAYERPAT= 'RGGB'

For solving it is not required but I could activated a checker pattern filter if it helps. I would add it to the header anyhow. Then debayering could be done later on the single "debug"images with a better debayer algorithm.

[han-k59]

Applying a dark will also help greatly with solving. Then hot pixels will be mostly gone and the background noise will be much more clean.

[han-k59]

Dark applying will be only required for uncooled cameras. But lets see how your camera images look with and without a dark. ASTAP will report the number of stars used for solving. After applying a dark the solver reports more matches then it will be an improvement. The number of matches is a quality indication of the image.

[artyom-beilis]

p.s. I mentioned your program (still waiting for moderator) for navigation usage in this discussion. https://hackaday.com/2023/03/16/dobsonian-telescope-adds-plate-solver/

BTW, for visual only I have another project called AstroHopper - it does not use plate solving but greatly helps finding targets with ease. It is my "push-to" tool for everyday visual observation.

[han-k59]

I have looked to your other program but using the gyro sensors of the phone could greatly help. The practical problem is that they are typical a few degrees off. A combination of sensors and solving would work best.

I could not find a ASI224MC raw file in my archive. But I cropped an other OSC camera image to about the same size. I get these indicative results

RAW: 45 quad matches RAW->normalized (checker filter): 48 quad matches RAW->colour: 32 matches RAW->colour->mono: 28 matches.

So normalised (checker filter) is a little better. But it depend much on the sensitivity of RGGB pixels. Some cameras show a stronger checker pattern then others. If the normalized (checker filter) gives always an improvement, I could consider an automatic checker filter if Bayer pattern is present and binning is one.

Anyhow if you could provide some ASI224MC raw's for testing that would be nice.

[artyom-beilis]

Ok, I'll try to collect some raw images tonight (hopefully there will be no clouds)

I can also convert images to raw, since same color pixels are unchanged during de-bayer processing - but this is something I need to check for %100.

[artyom-beilis]

I converted the images to raw format and validated that they are reconstructed bit accurately to same images.

Is is indeed clear that there are much less stars detected, for example for M82 it was 100 starts and it went down to 9 stars only, for M1 it went from 20 to 13, and ngc2024 from 20 to 5 stars.

I'm attaching files with rgb, raw, and raw normalised per R/G1/G2/B channes.

I'll also try removing darks to see if it helps.

astap.zip

[artyom-beilis]

The practical problem is that they are typical a few degrees off. A combination of sensors and solving would work best.

That exactly the point - once you visually align on a star nearby the target (i.e. plate solve visually) you eliminate the error. And the object goes into FOV most of the time. It is very good for visual 1 to 2 degreess FOV, but not for narrow FOV photography.

[han-k59]

I would not expect that it is possible to return the image to RAW. You combine several red, green and blue pixels. The information so flux of each individual pixel is lost after de-bayering. Anyhow I looked to the raw's. They look good but the focus it not very good make detection of faint stars difficult. When to focus is good many more stars will be detected.

I assume you trying to "apply" the dark. So subtract the dark from the light. That could help.

For your setup probably exposing at around 10 seconds or more would be better for solving. But since the setup unguided you maybe don't want to expose longer then 5 seconds.

The problem with APO telescopes is that focus is drifting due to the air temperature. This also happens to the most expensive APO telescopes. The diffraction factor glass->air changes. Normally you have to turn the focuser in when it gets colder. I refocus normally after each 0.5 degrees temperature drop. So the auto focus could be activated typically 20 times during a night.

[artyom-beilis]

I would not expect that it is possible to return the image to RAW. You combine several red, green and blue pixels. The information so flux of each individual pixel is lost after de-bayering.

de-bayer algorithm is complex in may ways. But what is important that every algorithm reconstructs missing R/G/B values from environment, however when the value is present - it is just not-modified.

I assume you trying to "apply" the dark. So subtract the dark from the light. That could help.

Yes - subtract

For your setup probably exposing at around 10 seconds or more would be better for solving

Yes it isn't likely going to work. The accuracy of the tracking isn't very good sometimes even 5s is too much for AZ GTi.

The problem with APO telescopes is that focus is drifting due to the air temperature. This also happens to the most expensive APO telescopes.

It is actually achromat - not APO :-)

But in any case, is there a way to provide a list of stars instead of an image to ASTAP? I wonder if I can try different star detection algorithms. (I come from background of computer vision)

[han-k59]

even 5s is too much for AZ GTi. Yes, AZ, Alt mount doesn't help.

But in any case, is there a way to provide a list of stars instead of an image to ASTAP? I wonder if I can try different star detection algorithms. (I come from background of computer vision)

That is interesting. Some new ideas are always good. I the past I briefly provided an input for use with Sextractor (horrible name) using a X, Y table. I removed that option to clean up the code. Sextractor can be found here: https://www.astromatic.net/software/sextractor/ This package was developed for galaxies detection and can also be used as an star extractor for Astromentry.net solver but I guess nobody is using that since the internal star extractor of Astrometry.net is also pretty good. You can send a X, Y star list to nova.astrometry.net to solve.

I assume the star extraction of ASTAP is at a simular level as Sextractor and Astrometry.net internal star detection. The main difference is that Astrometry.net can work with less stars. Probably 4 or 5 stars could be sufficient. So for very poor image Astrometry.net will work better. Astap will work well with 30 stars or more. Since stars are normally abundant available there was not need to improve it. The only thing I added to the Astap GUI version is an option to use triples (3 stars) instead of quads (4 stars) but I may remove it again because in practise there is no need to use it and improvement is marginal.

Here I can easily solve most images made with 0.01 seconds exposure. Your images are less solvable for the following reasons:

1. Uncooled sensor. (more hot pixels/fake star will be detected)
2. Small field-of-view => less stars
3. No mono sensor, less sensitive
4. Converted to colour so loosing resolution by the de-Bayer algorithm
5. Focus not optimal.
6. Brighter sky background.

Anyhow as an experiment you could try to detect stars yourself and feed them to Astrometry.Net to solve the image and compared them with the X, Y list you can extract out of ASTAP. The problem is false detections. If there are too many false detection, the solver will not find a solution. For this reason I often compare the detections with the star database by annotation.

An even better an easier experiment is to try to detect stars in an artificial image. In the standard ASTAP (GUI) you can create artificial star image using the tool in tab pixelmath 2. See screenshot. Artificial stars will be generated at all signal-to-noise levels at fixed places for testing.

[artyom-beilis]

Thanks you gave me lots of inputs. In any case it seems more issue with my rig. Finally ASTAP is de-facto standard plugin for most Astrophotography tools (like Sharpcap, NINA and others) so.

At this point I'll do your suggested improvements with giving raw images and sub-stracting dark to improve image quality.

I may play with star detection and maybe feed ASTAP with artificial images to test if any star detection algorithm can give an improvement!

Thanks a lot for a great support!

[artyom-beilis]

I implemented looping. Will be in in next release