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.
When Calibrating and Integrating Subs from Multiple Sessions and using Two Different Cameras how do I load a BadPixelMap for each Camera? If I load two BadPixelMaps will APP differentiate between them and assign them to the correct camera and the proper corresponding Session?
Â
Thanks
You want to make that data in 2 sessions then and assign one bpm to 1 and the 2nd bpm to the other camera.
Hi Vincent,
Yes that's what I would like to be able to do.
The actual project that I am working on consists of three sessions of NB data from 2018 taken by camera A that I would like to combine with two sessions of NB data captured in 2020 from camera B. When calibrating the data I can load master flats, bias and darks seperatly for each camera (or session) but it appears that I can only use one BadPixelMap and it is then applied to all sessions (clearly not useful for one of the cameras).
Bill
Is it? I must say I have not done a lot of multi session processing, but that's exactly why that would be the way to go, you can't assign the bpm to a session? (if not, I'll ask Mabula straight away). 😉
Ah you're correct, just tried myself. Let me get back to that.
Ah ok, got an answer back. It should automatically assign the BPM to the correct sensor. If the dimensions of the chip are exactly the same, the capture software should add the name of the sensor to the header, otherwise APP wouldn't know indeed. Basically it would recognize the darks for another camera then also automatically like that. Sessions are more for the same sensor, with different calibration files for that session of that sensor.
Ok, but in my case the sensor size of the two individual cameras are exactly the same and I cant see any differentiation between the two in the FITs header. Wouldn't it be easier to treat the BPM in the same manner as the other Master calibration files and simply designate what sessions you want each BPM to apply to?
Â
What I have done as a work around is to calibrate each camera group seperately, save the calibrated subs and then reload both groups for registration and integration. This seems to work but adds a couple of additional steps and time to what is an otherwise wonderful and fully automated process.Â
I'm interested too in this possibility, that is: let me choose to add and assign each BPM freely to each corresponding session, as i normally do with all other calibration files...
Thanks Mabula if you can do thisÂ
Yes, when the sensor is exactly the same in dimensions and no name is given (you may have a look if the capture software can provide that, normally they should) the best is to process that data separately. It might be interesting to see if this can be changed somehow.
