Unnecessarily long ...
 
Share:
Notifications
Clear all

June 24 2026 APP 2.0.0-beta46 has been released !

Improved internal memory configuration (lower ! memory usage), fixed beta45 startup issue, fixed Set Save Directory & 2-panel mosaics.

May 27 2026 APP 2.0.0-beta45 has been released !

Fully Multi-Threaded LNC, many improvements for the registration engine, platform upgrade, and further tuning of internal memory consumption and memory release back to OS.

Apr 14 2026: Google Pay, Apple Pay & WeChat Pay added as payment options

Update on the 2.0.0 release & the full manual

We are getting close to the 2.0.0 stable release and the full manual. The manual will soon become available on the website and also in PDF format. Both versions will be identical and once released, will start to follow the APP release cycle and thus will stay up-to-date to the latest APP version.

Once 2.0.0 is released, the price for APP will increase. Owner's license holders will not need to pay an upgrade fee to use 2.0.0, neither do Renter's license holders.

 

Unnecessarily long registration time for many lights and deep exposures

3 Posts
2 Users
1 Reactions
734 Views
(@pete_xl)
Red Giant
Joined: 9 years ago
Posts: 52
Topic starter  
 
I often take deep exposures over several nights. This frequently results in data sets with several hundred lights and very dense star fields.
 
The number of stars is very important to me for assessing the quality of the individual lights. I would like to use the “Quality” parameter, which is apparently determined from the number of stars and the geometry of the star image, as a weight for the integration. To do this, however, I would have to specify values far greater than 5000 stars in the Star Analysis. But then the registration takes an extremely long time with many lights. If I enter smaller values instead, e.g. 500 stars instead of 5000, the quality factor is flattened, loses its significance and sense. 
 
For this reason, I am therefore currently using SNR as a weighting parameter, which is, however, not ideal.
 
My question: Wouldn't it make much more sense to differentiate between the number of stars for registration and the number of stars for assessing the quality of the images, i.e., to query two values? Then, for example, you could enter 500 stars for star analysis and 8000 stars as the upper limit for the quality parameter.
 
Pete
 
P.S. In order to understand the flattening of the quality factor that goes along with the star count, I saved the plots as CSV files. It is a significant disadvantage that you end up with a large amount of data that you cannot work with because numbers and text are combined as text in one single column, or two numerical values are separated by a hyphen in one column etc. I think it would be very benefical and easy to fixthat numbers and text are stored separately in columns so that they can be evaluated.
 
 

This topic was modified 6 months ago 2 times by Peter

   
ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 9 years ago
Posts: 5357
 

Hi Peter, @pete_xl

Thank you very much for your interesting question.

I fully understand your point here and I have made a note our our issue list, to indeed make this better.  It is very true that with more stars, the registration will slow down much but you want that data for quailty assessment, I fully agree on that.

I need to think about the most robust way to handle this properly. It is now on my list 😉 Thank you very much for your thoughts !

Mabula



   
Stefan Rang reacted
ReplyQuote
(@pete_xl)
Red Giant
Joined: 9 years ago
Posts: 52
Topic starter  

@mabula-admin 
Thank you very much for taking this into account, Mabula and sorry for the late reply!

This topic is really important to me. Also, in my current project, a collaboration on an SNR with a colleague and > 1500 Lights, it is very difficult to find a representative weighting parameter, if the stars fall out.

Over the past two years, while working on very faint supernova remnants, I have also found that the “dispersion” parameter should actually be an essential weighting factor in many cases. Wouldn't it be an option to introduce a custom weighting factor in which the customer can combine factors and take more responsibility for their own data?

Best regards,

Peter



   
ReplyQuote
Share: