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,
I'm having difficulty in using 1.063 vs 1.062 - so much so that I reverted to 1.062.
Calibration under both 1.062 and 1.063, using the same Flats, DarkFlats, Bias, Darks and Lights
Flats 20
DarkFlats 20
Bias 20
Darks 10
All using the same gain (I know that's not a requirement). I select Median for all my calibration frames. Under BadPixelMap I choose a hot pixels kappa of 4.0 and cold pixels % 25.
Under 1.062: My BPM looks normal (for what I'm used to). Find this attached as AA1062_BPM1.png
Now, I load up 1.063 and put in all the same values and files and I end up with the attached BPM screenshot: AA1063_BPM1.png
The difference: APP 1.062 has just over 3.4% bad pixels, APP 1.063 is over 99.9% bad pixels.
Here is the output when it is processing the Flats, so it's something to do with that I assume (all 20 entries would be this: NAN - Not a Number):
16:24:29 - GENERAL IMAGE LOADER: loading frame /nvme/Astronomy/Captures/ASI294MC/CALIBRATION/FLATS_CLS-CCD/17_43_09/FLATS_CLS-CCD_00009.fits
16:24:31 - 2) CALIBRATE: Adaptive Data Pedestal: disabled
16:24:51 - GENERAL IMAGE LOADER: frame /nvme/Astronomy/Captures/ASI294MC/CALIBRATION/FLATS_CLS-CCD/17_43_09/FLATS_CLS-CCD_00009.fits was loaded successfully
16:24:51 - 2) CALIBRATE: loaded flat 9 of 20 flats, starting analysis...
16:24:51 - 2) CALIBRATE: writing flat 9 of 20 to flat file mapping...
16:24:52 - 2) CALIBRATE: got analytical results of 9 of 20 flats.
16:24:52 - 2) CALIBRATE: location of flat 0 dispersion of flat NAN
16:24:52 - 2) CALIBRATE: location of flat 0 dispersion of flat NAN
16:24:52 - 2) CALIBRATE: location of flat 0 dispersion of flat NAN
What am I doing wrong?
For the BPM, this is created from Flats and Darks. I was concentrating on my Flats (because Darks are easy, right?) but it turns out my Darks were full of noise. FULL. This was an ASI294MC Pro cooled camera so that shouldn't have been right. At the moment I'm not sure where the problem is, but I've 5 good frames, then the noise increases - as if the temperature is increasing. The reported temperature (in SharpCap 3.1 and 3.2 Beta) maintains a nice -5C (that I set) however I don't believe it is correct. Trying again. Will report on my findings. But it is my Darks that were the issue here.
Hi @itarchitectkev,
Thank you for reporting this.
I am aware of a problem with creating the Bad Pixel Map with bad column detection ON. For you sensor, I think it's safe to turn this off. Can you try that and let me know it the BPM looks good again?
This particular problem has been fixed in the past few days and I will release a new version soon with this fix. See first bullet at
Is that flat analysis from calibration of the flats with that wrongly created BPM ?
Kind regards,
Mabula
Thanks Mabula, that one option disabled has allowed me get a good BPM now. I've just done a quick test though so will probably look at tuning and improving some options tomorrow. I now have about 1000 Dark Frames collected using a variety of techniques that I can delete it seems, (though I think there is a battle - separate to this with those, but that's not your problem!).
