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.
I completely agree with you, Larry. It would’ve been nice to get a little direction on this instead of having to dig through all of the post to figure this one out.
Hi all, @larry-1969, @croz, @chifles
Apologies for the late response. I am glad to read that you were able to solve the issue by enabling the hot pixel cosmetic correction. But it is definitely not the best solution here. The best solution is to use a Bad Pixel Map based on some of your darks. I think I read above that darks were not used? If you do not want to use darks, then at least create a Bad Pixel Map for your camera's sensor with some darks, and then use that single Bad Pixel Map in all your data processing without darks. That will also remove the hot pixels and more reliably than the cosmetic correction where you run the risk that very faint and small stars are removed by the cosmetic correction. BPM will never harm your data and you really should be using it always I think.
If you don't want to use darks, what is the agument against it If I may ask? Are you exposures that short that dark current is virtually non-existent?
Mabula
I’ve been using darks with my 183C for years. I just upgraded the camera and with newer technology there isn’t any amp glow. So I was just trying to avoid a step that was mostly unnecessary. I didn’t realize that the hot pixels were going to be problematic. I will either consider a BPM or using darks.
Thanks!
Kevin
I got very good results up to and including Beta 10. This issue didn't come to light until Beta 11. APP creates a bad pixel map even when I don't use dark frames. My climate changes quite a bit, requiring me to cool to different temperatures throughout the season. Dark frames are a huge pain... How would I go about creating a bad pixel map using some darks? I understand that when integrating dark calibration frames that they have to be the same temperature and exposure time as the light frames. Is there a way to create a bad pixel map that I can use at various temperature and exposure times?
Thanks!
Larry
Yes, a BPM is there to get an as complete as possible picture of the sensor characteristics in the hot/cold pixels. What you can do is to create a very bad dark, so no cooling and long exposure. This can then be loaded and used to create a BPM which you can use for quite a long time. Darks still work in the sense of getting rid of amp-glow and they still may add some extra pixel rejection. You can give it a try with such a bad dark and pixel peep to see if it indeed removes the hot pixels properly.
Yes, a BPM is there to get an as complete as possible picture of the sensor characteristics in the hot/cold pixels. What you can do is to create a very bad dark, so no cooling and long exposure. This can then be loaded and used to create a BPM which you can use for quite a long time. Darks still work in the sense of getting rid of amp-glow and they still may add some extra pixel rejection. You can give it a try with such a bad dark and pixel peep to see if it indeed removes the hot pixels properly.
Thanks for the suggestion.
Would there be an advantage to integrating a bad dark frame over applying hot pixel kappa in cosmetic correction?
If so, how would I actually go about doing that? Just load the "bad dark frame" into the dark folder and go about integration normally?
Or, is there a way to create a bad pixel map from a single dark frame only, without having to go through the entire integration process?
Thanks again!
Larry
No I meant to use the bad dark frame, load it and then go to the calibration tab to create the bad pixel map. This bad pixel map can then be saved somewhere you like and used for all your data with this sensor. The bad dark shouldn't be used for normal calibration.
No I meant to use the bad dark frame, load it and then go to the calibration tab to create the bad pixel map. This bad pixel map can then be saved somewhere you like and used for all your data with this sensor. The bad dark shouldn't be used for normal calibration.
Thank you. I'll give that at try.
Larry
@vincent-mod
Sorry to dig this back up, but can someone point me in the direction of how to go about creating the bad pixel map from a single dark frame?
I would load the frame into the dark selection in tab 1. Then do something in tab 2 to create the BPM? I've never done this manually before...
Also, is there an advantage to doing this over just selecting "hot pixle kappa" in cosmetic correction?
Thanks again!
Larry
Hi Larry @larry-1969,
I would suggest to make a couple of bad darks, 5 -10 ideally. Just use long exposure and no cooling. Then they will manifest many hot pixels reliably.
Then load those darks with the dark button.
Go to 2) Calibrate, make sure that Bad Pixel Map creation is on automatic or on:
Click on create masters and assign to lights.
That produces both a masterdark and a Bad Pixel Map, right?
You can delete that MasterDark.
The produces BPM should have reliably information about your hot pixels and you can use this BPM on all your lights of diffferent exposures and different temperatures without any issues.
So on your next project, load your lights and the normal calirbation data that you have. And load this new BPM separately with the BadPixelMap load button in menu 1) Load.
To be clear, even when darks are not loaded, but flats are, then a BPM is still created based on the flats, but only for cold/defect pixels. So that BPM would not correct Hot pixels 😉
Mabula
Hi Larry @larry-1969,
I would suggest to make a couple of bad darks, 5 -10 ideally. Just use long exposure and no cooling. Then they will manifest many hot pixels reliably.
Then load those darks with the dark button.
Go to 2) Calibrate, make sure that Bad Pixel Map creation is on automatic or on:
Click on create masters and assign to lights.
That produces both a masterdark and a Bad Pixel Map, right?
You can delete that MasterDark.
The produces BPM should have reliably information about your hot pixels and you can use this BPM on all your lights of diffferent exposures and different temperatures without any issues.
So on your next project, load your lights and the normal calirbation data that you have. And load this new BPM separately with the BadPixelMap load button in menu 1) Load.
To be clear, even when darks are not loaded, but flats are, then a BPM is still created based on the flats, but only for cold/defect pixels. So that BPM would not correct Hot pixels 😉
Mabula
Thanks a lot for that! That actually makes sense.
Once I create this new BPM and load it into my next project, would I disable BPM creation in 2) Calibrate, or doesn't it matter?
Larry
Thanks a lot for that! That actually makes sense.
Once I create this new BPM and load it into my next project, would I disable BPM creation in 2) Calibrate, or doesn't it matter?
Larry
Yes, simply disable the creation of the BPM then 😉 if it is on automatic mode, then it is fine as well, in automatic mode, only a BPM is created if none is loaded 😉
Yes, simply disable the creation of the BPM then 😉 if it is on automatic mode, then it is fine as well, in automatic mode, only a BPM is created if none is loaded 😉
Great! Thanks again!
One more question and I'll let this topic die.
How is creating this BPM from a set of "bad darks" better than selecting "hot pixel kappa" in cosmetic correction?
Larry
Yes, simply disable the creation of the BPM then 😉 if it is on automatic mode, then it is fine as well, in automatic mode, only a BPM is created if none is loaded 😉
Great! Thanks again!
One more question and I'll let this topic die.
How is creating this BPM from a set of "bad darks" better than selecting "hot pixel kappa" in cosmetic correction?
Larry
@larry-1969 Well, cosmetic correction is simply less robust and can harm actual faint stars possible, these faint stars could be mistaken for noise/hot pixels and they could be removed then by cosmetic correction. Obviously, a BPM would not have that problem and thus it is more robust/reliable 😉
Mabula
