Star analysis is run again and again - Why?

Good question, especially since it takes forever.

DSS does it in about one third of the time (tested it yesterday) and saves the analysis in txt files.

Hi Stephan @schurig,

Good question. this is a feature that isn't implemented yet. But I fully agree with you, we should save the star analysis information in external files. Using header data is not an option, since the amound of information can be huge... especially for mosaic data where you need to detect much more stars usually for good registration.

What I would propose to implement:

• Save star analysis information in a file that has the same name as the light, but with a certain postfix like -SA (Star Analysis).
• Save the file in the same folder as the light, or in a subfolder called SA.
• Add option in 3) Analyse Stars to use the previously found analysis data, or to disregard the data and thus re-analyze the frames. (needed if registration fails for instance)

Would you agree to these additions?

Furthermore, in regsitration, there is already the option to do no registration (no registration mode).

For normalization, we actually need to do the same as for star analysis. We need to store location, scale, noise & SNR in the nromalized frames. This can be done simply in the Fits Header off course. Also we need to add the option to use previously found normalization data or to disregard it.

All these additions combined should really help speed things up if you process step by step in different sessions on different days.

Kind regads,

Mabula

Posted by: gdwats@comcast.net

Good question, especially since it takes forever.

@gregwrca, do you adjust star analysis parameters perhaps or do you use defaults?

I don't find/think that it takes forever and it actually is a very vital step for thorough image analysis and registration.

Mabula

Posted by: schurig

DSS does it in about one third of the time (tested it yesterday) and saves the analysis in txt files.

Hi Stefan, (@schurig),

valid point, although not entirely I think....

DSS star detection and subpixel star location calculation is by far inferior to APP's detection and analysis. (at least I think, you can qoute me on this as well 😉 )  

Comparing APP's capabilities in star analysis (and registration) to the capabilities of DSS is a bit like comparing apples and oranges I honestly feel.

And I can totally back that up with a clear example as well since just saying that is off no use, off course.

I invite everyone that reads this to try this themselves in both APP and DSS 😉 (I used DSS version 3.3.4)

Bear in mind, to illustrate the huge difference in capability I present an extreme case, a case that DSS can't handle by a very long shot... it should help to illustrate that the time that APP takes to star analyse your frames, is because it's star analysis engine is simply far more advanced 😉 than the engine/modules of DSS :

Please download these 2 images of high quality data of the NASA WISE infrared telescope to test this yourself:

image 1 : https://s3.eu-central-1.amazonaws.com/apastropixelprocessordl/WISE/0711m697_ac51-w3-int-3.fits

image 2: https://s3.eu-central-1.amazonaws.com/apastropixelprocessordl/WISE/0712m682_ac51-w3-int-3.fits

A comparison of star detection and registration in APP versus DSS:

DSS screenshot showing that star detection is set at the lowest threshold 2%, DSS finds in these frames:

only 59 & 119 stars.

Registration is by far not possible from these results for this data.

APP screenshot, showing that APP detects much more stars if we set star detection at the lowest thresholds:

3264 & 3303 stars.

Thats about 25-50x times as much ! That's a huge difference. And APP is actually detecting real stars, not structures in the extensive nebulosity here 😉

The image in the image viewer is the 2 images registered to each other as well. You can see, that there is little overlap between the images (less than 10%), but because the star detection count is soo high registration becomes possible. In the area of overlap 80 starpairs are found for registration. And this is enough to actually do proper optical distortion correction as well. If only 10 pairs are found, proper optical distortion corrections isn't really possible I might add.

To conclude: if you donwload these 2 frames and test star detection and registration in both APP and DSS you can perfectly conclude yourselves how these 2 applications can be compared I think.

My conclusion is that it is a bit like comparing apples and oranges.

Kind regards,

Mabula

Hi Mabula,

I agree with each of the three proposals, that would be fine. 🙂

What I would propose to implement:

• Save star analysis information in a file that has the same name as the light, but with a certain postfix like -SA (Star Analysis).
• Save the file in the same folder as the light, or in a subfolder called SA.
• Add option in 3) Analyse Stars to use the previously found analysis data, or to disregard the data and thus re-analyze the frames. (needed if registration fails for instance)

I order to speed things up, again the urgent request - I think not only from me, but from many users - to be able to save the state of APP in a project file. If you'd like to, I could write down in detail what a project iile should store in my opinion.

Thanks, Stephan

Hi,

I know what you mean - and it is quite clear that DSS and APP are two different programs with different algorithms and approaches, as well as it depends on the image itsself.

I can only describe my personal experiences. I do not take (at least at the moment) wide area panorama panels with thousands of stars that have to be perfectly registered and normalized, delight-polluted and then combined to a seamless final pic - one of the unique features of APP. My frames typically contain one object (e.g. a small galaxy) with some 100 stars that can be registered. They are taken in one night, I have many short-integrated frames, and I have them for each channel. So my personal focus is also on "how can I process my huge amount of data very comfortably in a short time without having to do e.g. processing steps again. So as you might have recognized, my proposals strongly focus on usability ;-). I want to help to make APP more competitive seen under this point o view.

Stephan

Hi Stephan @schurig,

Yes I understand, so I would in 3) set the amount of stars to be detected to a minimum, or even a fixed high value detect above noise kappa value to have that work fast. That will make registration also faster.

I am really glad that you assist in your proposals for usability and speed of APP. Storing the star analyis data in separate files (so you only have to do it once) will be implemented soon and I also think that implementing project load/save can be done more quickly than I previously thought. So I am moving that up on my list as priority as well.

Thanks 😉

Mabula