UPDATE FROM MABULA
I have had a very rough 2 months unfortunately health wise. I was struck 3x in a row with bacterial infections. The second infection occurred  after a routine hospital checkup and I became very sick. I had to rest and take a lot of antibiotics. Once I was recovering and restarting work 1 month ago, I again became sick. The infection was not yet gone, so even more antibiotics and rest was needed. Needless to say, it took a lot of my energy and I needed a lot of rest.
Finally, the infection is really gone and my energy is coming back step-by-step now and I have started work again. I am terribly sorry to have kept you waiting for support. I will address all outstanding questions and e-mails step-by step and will be on the forum daily from today.
APP 2.0.0-beta47 will come soon as well, a lot of work was already completed before I became very ill, so the release is also nearly ready for you. Beta47 will be much faster actually. Many workflows will be more than 2x faster, mosaics can even be 10x faster than before because registration really received a major boost... all compared to beta46. Â Before I release it, I will make sure that everything is working properly and then I will release it.
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
