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.
Seems to be some debate about whether gain for flats needs to match gain for lights - in my view not, although APP flags a warning about this. Fair enough to point that out or any other potential issues. Trouble is it doesn't seem to flag it at the outset - it waits a while which is a pain if you hit the integrate button to do the whole process and come back hours later to find it's interrupted with a warning.
Summary - could all warnings be made at the outset, rather than part way though processing?
Thanks Tom C
Flats need a proper illumination of your sensor, through the optics of your setup to be able to correct for vignetting (and dust). These are characteristics of the setup and that data isn't something that needs to match regular astro-images and calibration data. You can set the gain to 0 (for max dynamic range) and take 1-2 second exposures that will have the linear histogram land at about 60-70% (the only thing is that you shouldn't clip the data to the right, the 50% you see quoted a lot isn't important). The flats do need their own calibration data, dark-flats and these do need to be at the same gain etc. as the flats.
Could you post a screenshot of the warning as I can't remember it does that, in my view it shouldn't be about having that match with the lights...
Â
To add to what Vincent wrote: the gain of the flats does not have to match the gain of the lights. Neither do offset, temperature and exposure time. However, the flats do need to get calibrated and for that either bias and darks or dark flats with the same gain, offset and temperature are needed. In case of dark flats, the exposure time needs to match as well with the one of the flats.
Thanks guys. We are all on the same page with regard to flats then - important thing is to make sure that the settings for the flats match the setting for the dark flats. And also as you say to ensure working on the linear part of the sensor.... which is something I've only just realised after 4 years of problematic flats!! It seems that setting the average ADU of the flats to match the average ADU of the lights may be the surest method. (For my ASI1600 cool at least)
Re the APP error message, which was the main point of my post - I did one re-run and it seemed fine so maybe I just did something wrong. If I get the same issue again I'll post back.
Thanks for the feedback - what a great forum!
Kind regards
Tom
Thanks so much for appreciating the help! 🙂
Yes, looking at the ADU is a good way to check if you're aiming for a good value. Glad it helped and I hope the processing is going better now?
