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.
Hi,
What do the values of the Integrated FITS represent. What would be better/worse in relation to those values. E.g. I assume NOISE being a small figure is better, and SNR increasing is better? I'd like to use these values to help determine different calibration/settings to get better integrations.
HDU1 - LOK-1 = ' 2.4281E-01' / lokation of channel 1
HDU1 - SCALE-1 = ' 2.8129E-03' / dispersion of channel 1
HDU1 - NOISE-1 = ' 2.4179E-03' / noise level of channel 1
HDU1 - SNR-1 = ' 1.1106E+00' / Signal to Noise Ratio of channel 1
HDU1 - medNR-1 = ' 3.2801E+00' / median noise reduction, channel 1
HDU1 - medENR-1= ' 1.1181E+00' / effective median noise reduction, channel 1
HDU1 - refNR-1 = ' 3.2972E+00' / reference noise reduction, channel 1
HDU1 - refENR-1= ' 1.2574E+00' / effective reference noise reduction, channel 1
Cheers,
Kev
Yes, the S/N ratio being higher is the preferred direction for that and the noise level to be low. It totally depends on the data, the camera, etc. so I don't think there's a general number to compare it to. Experimenting with different integrations is a nice way to check out these values, but things like the star shape etc. also contribute to a nicer image. @Mabula-admin
Hi - I wasn't after an absolute number - these numbers are relative. But if I'm adjusting sliders, re-calibrating, and integrating - I expect to be able to compare numbers between each run. I would assume these would be in the documentation once done?
As an aside, unfortunately it isn't easy - in the current release of APP - to compare - due to the fact the Integrations get overwritten without any option to change any file name format. I can Save a fits and it heads to Other - but opening that same file, that was just saved to Other, gets over-stretched, usually because I forget to untick the Stretch option I assume. The placement/user journey is wrong for this Stretch option - it should be on the pop up for the type of file after you've clicked save and choosing file type, not next to the Save button.
Â
Yes, Mabula is working on the documentation to be available in PDF form and I'm sure these things will be covered.
Thanks for the suggestion, the UI will need to have a few changes as well and it's been worked on as well.
Hi @itarchitectkev & @vincent-mod,
HDU1 - NOISE-1 = ' 2.4179E-03' / noise level of channel 1
HDU1 - SNR-1 = ' 1.1106E+00' / Signal to Noise Ratio of channel 1
Like Vincent, indicates, you want higher SNR and lower noise if you compare integrations.
BUT !!! please realise that noise by no means is an absolute metric ! This mistake is made again and again on even the most advanced astrophotography fora 🙄Â
Noise is correlated with dispersion and I think an explanation of dispersion is therefore needed here as well:
Dispersion: each image has a peak in their histogram, usually this peak corresponds more or less to the sky background in the image. This peak can be regarded as the central value of the pixel distribution of the image and the average/mean values are calculated central values which will be more or less the same as the location of the peak/sky background. Now the way the data is spread around this central value is called dispersion. If the peak is very sharp, you have small dispersion, if the peak is wide, you have a high dispersion value. Dispersion is also called scale, and can be calculated in many ways ! the standard deviation (root of variance) is a way, as is MAD, Median Absolute Deviation.
Now let's get back to "Noise is correlated with dispersion" : let's say we have an image with a dispersion of 10, and a noise value of 6. Now if I would divide all pixels by 2. Then all of a sudden, the dispersion is divided by 2 as well, it will be 5. And, as you can understand, the noise value is also divided by 2. It will be 3.
Now what does this mean and why is this so important to realise: if I would stretch the linear data of the original image and also the image divided by 2, using a DPP autostretch, both images will end up looking exactly ! the same visually, the apparent noise levels would be the same as would be the signal in the image. But we know for sure that the linear data on which the noise levels are calculated, are different with a factor 2 ! The linear noise values are different with a factor of 2, but the stretched data will look exactly the same 🙄 for both noise and signal.
So please be very carefully when comparing absolute noise levels.
If you compare noise with just a mere noise script for different images of different sources, you will have no way at all to be certain about the relative meaning of the noise because the absolute values are of no use at all really !
Absolute noise values are only of real value when you compare images that are normalized for dispersion and this is almost always forgotten in noise comparisons on most internet fora making those comparisons a futile exercise really 😉
Now, the other values in the integration are there to help you with this problem:
HDU1 - medNR-1 = ' 3.2801E+00' / median noise reduction, channel 1
HDU1 - medENR-1= ' 1.1181E+00' / effective median noise reduction, channel 1
HDU1 - refNR-1 = ' 3.2972E+00' / reference noise reduction, channel 1
HDU1 - refENR-1= ' 1.2574E+00' / effective reference noise reduction, channel 1
The noise reduction tells you with what factor the noise is reduced relative to either the reference frame or the medain nosie value of all frames. Normally you expect that this value approaches the square root of the number of frames. So for 16 frames, a noise reduction of 4 is as good as you can get. if the noise reduction is much lower than the square root of the number of frames, something is not working well in integrating the data. You will see this if no dithering is applied. Dithering helps with better noise reduction.
The Effective noise reduction, is the noise reduction value corrected for dispersion. So the effective noise reduction is a good way to compare your different integrations. Since noise will drop when you integrate frames, and the clear correlation of noise with dispersion, also dispersion must drop. So please study what happens with especially the effective noise reduction values when you compare your integration following different calibration/registration/normalization paths 😉
Please let me know if this is clear 😉
Mabula
Hi - I wasn't after an absolute number - these numbers are relative. But if I'm adjusting sliders, re-calibrating, and integrating - I expect to be able to compare numbers between each run. I would assume these would be in the documentation once done?
As an aside, unfortunately it isn't easy - in the current release of APP - to compare - due to the fact the Integrations get overwritten without any option to change any file name format. I can Save a fits and it heads to Other - but opening that same file, that was just saved to Other, gets over-stretched, usually because I forget to untick the Stretch option I assume. The placement/user journey is wrong for this Stretch option - it should be on the pop up for the type of file after you've clicked save and choosing file type, not next to the Save button.
Hi @itarchitectkev,
I will take this into account, I agree with you, the strech/no stretch option should best be asked in a better file saving dialog. I intend to create a new bigger and complete dialog for saving the data in all formats and bit depths.
In addition I wll supply the option to save the integrations with a name of your choice as well.
Mabula
