Forums
Astro Pixel Process...
General
Unnecessarily long ...
 
Share:
Notifications
Clear all

2026-10-09 APP 2.0.0-beta48 has been released !

This is mainly a bug fix release for the reported bugs in beta47. In addition it has a significant User Interface performance improvement noticable when you need to process 1000s of images in APP.

2026-10-03 APP 2.0.0-beta47 has been released !

This is a very big release... many code optimizations/rewrites, many parts of APP are much faster and more precise, especially star analysis and registration are much faster ! Big mosaics will go much faster 🙂

And we introduce a new preview filter, which includes the new Adaptive Deep Sky Stretch and a General Levels Stretch, this has been long over due. The old preview filter (the panel on the right side to stretch and preview your data) has not been updated for a couple of years and it is a critical part of any APP session.

Adaptive Deep Sky Stretch or ADSS is a much more intuitive stretch algorithm. It is also color preserving (which is a great new addition in itself ! ) which means that the highlights are no longer bleached, color is maintained from the linear data while stretching. You can simply stretch your data using the sky background level and signal width sliders which work much easier and more intuitive. You no longer need to fiddle with the old complicated sliders with zoom buttons. All the zoom buttons for the sliders are made redundant. And you can enter slider values in the slider value fields yourself. I will make a youtube video in the coming days to explain and fully introduce ADSS. Once the video is ready, it will be highlighted on the forum.

RGB Combine upgrade !. The RGB Combine Tool has been rewritten mostly. The tool is faster and easier to use and most importantly, the Luminance slider to inject a luminance channel or channels into the RGB composite is now working correctly. It no longer bleaches the RGB colors. Combined with the new ADSS preview, you will get much better and easier great composites with great color! I will also explain this in a new youtube video.

Unnecessarily long registration time for many lights and deep exposures

 
General
Last Post by Peter 9 months ago
3 Posts
2 Users
1 Reactions
1,093 Views
RSS
 Peter
(@pete_xl)
Red Giant
Joined: 9 years ago
Posts: 53
Topic starter December 16, 2025 13:05  
 
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 11 months ago 2 times by Peter

   
ReplyQuote
 Mabula-Admin
(@mabula-admin)
Universe Admin
Joined: 10 years ago
Posts: 5468
January 4, 2026 21:08  

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
 Peter
(@pete_xl)
Red Giant
Joined: 9 years ago
Posts: 53
Topic starter February 8, 2026 17:16  

@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
Forum Jump:
  Previous Topic
Next Topic  

Currently viewing this topic 2 guests.

Share: