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.
Im trying to figure out what is a better result when it comes to Registration RMS graph. Maybe i'm missing something, but in my last two images, I've had fairly consistent low numbers. In the screen shot my first few are high, then the meridian flip happened and the for the most part it stayed fairly stable. Can you please help me understand this particular analytical data set.
Thanks
Zachary
I'm hoping that this got lost in the shuffle, I am still looking for insight into this.
Thanks
Zach
As you still appear to be awaiting a response I thought I would offer my two-penny worth in the hope it might help. I am only an amateur imager and it is a long time since I studied statistics ay school.
I don't know exactly the algorithm that Mabula has used in APP but by way of explanation you might want to do a little research on the statistical technique of Feature Scaling. This is a method of normalising a set data values, in this case the Registration RMS error, to make the data more accessible for further processing, in this case I would assume to contribute to the calculation of APP's Quality Score.
In this case the set of Registration RMS data values have been normalised to a scale between 0 and 1.
In the case of your data the frame with the least Registration RMS error is the frame selected as the Reference Frame, Frame 10 on your graph. There can clearly be no x, y positioning error between the calculated centroids of stars in a frame when compared with itself. As a result of this zero positionning error, this frame has attained the best possible normalisation score of 1. As we don't live in a perfect world (at least from the pespectve of an astrophotographer) all the other frames show minor deviations in the calculated centroid positions of the selected reference stars when compared against the reference stars. As a result of the normalisation processing the frames with the highest calculated Registration RMS values have normalised scores tending towards zero. Looking at your screen shot I do not see a frame with normalised error score of 0, so I guess Mabula has included a small pedestal value as the lowest scores are all around the 0.1 level.
An important point to note at this point is that the normalised data results only help to distinguish the 'best' values from the 'worst' values within the available set of results, scaled between 1 to 0. So if a set of frames showed a range of Registration RMS errors no greater than 0.20 in their absolute values (which I think owing to optical distortions would actually be a decent result), there would still be a frame (the reference frame) having a score of 1, and some other frame having actually a still-quite-low absolute Registration RMS value that would achieve a normalised score approaching the minimum value. I can only suggest that you take a close look at what existing data you have to confirm what I say above is broadly correct.
Hopefully the above goes someway to explain the results in your screen shot. Try Googling statistical data normalisation for a more detailled explanation.
So the real question now is are the low scoring frames in your data set actually that poor in absolute terms and when compared with your other results achieved prior to and since, with the same imaging set-up under similar seeing conditions.
If I read your original post correctly you indicate that the lowest scoring set of results (worst Registration RMS figures) were captured after a meridian flip, but amongst these (frames 25 and 26) you still have two frames with scores up with your pre-flip results. This may indicate that on this occasion you had a minor cable snag that affected guiding but that is something for you to decide.
So my suggestion would be to take a closer look at the absolute (as opposed to normalised) Registation RMS values that you achieved with your rig and decide if the your low scoring frames are signifcantly worse than average or not. From what I can see of the Quality scores they have not actually done that badly in comparison to the reference frame.
I have on occasions processed data from commercial sites and as best I recall absolute RMS registarion errors of circa 0.30 are not uncommon.
Lastly, while the normalised graphical results scaled 0-1 help in distiguishing 'good' from 'bad' they do not indicated in absolute terms the real difference between 'best' and 'worst'. Only a closer inspection of the actual results can do this.
Clear skies
Mike
@mestutters Thank you for the very detailed response, I will do as you suggested and I think one of the reasons I asked the question was that my guiding that night was pretty decent base on the numbers that PHD spit out, and so I was kind surprised by this graph. I'm working with my travel setup as I have just switched out my DSLR for a dedicated astronomy camera (ZWO 2600 MC pro) so Im trying to get everything dialed in but I think I might not have the best combination based on some research I've done thus far.
Zach
Thanks for the response.
You say that you have recently changed your astro camera.
It occurs to me that the Registration RMS is in units of 'pixels'. Therefore unless the new camera has identically sized pixels as the old you would (I think) naturally get a different range of Registration RMS results even if all other aspects of your imaging train's performance and the observing conditions were identical. For a like-for-like comparison you should I think convert your earlier and current results to microns or arc-secs to see if you are getting similar results.
What strikes me about your original graph is the lack of variability in the Registration RMS results from frame 12 onwards. This does not seem very natural to me. I can understand that a sequence of frames would show a dip in quality due to, say, seeing, but I would still expect to see a reasonable degree of randomness.
Incidentally I think I have found Mabula's remark that I recollect about a very good Registration RMS result. It is in the Release Notes for 2.0.0 Beta 20 - my italics. The remark is not exactly as I remembered it but since originally reading it I have always been very pleased if my RMS numbers were getting down towards this value. Converted to μm these are very small values.
Looking at your original screenshot you do indeed seem to be getting around this target level in the first dozen or so frames but subsequently, apart from the 2 exceptions noted earlier, something seems to have gone amiss.
- IMPROVED Sorting on Registration RMS
This is now shown more logical in the analytical plots by having adjusted the normalized registration RMS value for the plots. A registration RMS error of 0,10 pixel will now show much higher, which is logical since you can not register much better on monochrome data. And registration values larger than 1 pixel are shown much lower which is also logical because this causes visible problems in the integrations. The following 2 screenshots show the difference on typical registration RMS values on monochrome data:
Best of luck with your investigations.
Mike
Mike,
I may have not given the right impression, all of the frames in that screen shot where with the same camera, sorry for the confusion, I didn’t explain it very well. The straight line is what puzzles me as well, as I went back and had a look at a different project and the RMS graph was definitely better. I went out last night to image the same target to try and see what was going on and discovered an issue with my EAF that may or may not be the cause, I’ll work on getting that resolved first, and then see what happens
Thank you for the reminder about Mabul’s notes, I will need to go back and review those.
Zach
