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 am having some issues with generating flats and using them successfully. This is not an APP issue, since I experience the same issue with DSS & PixInsight as well, but I thought I would post here to see if anyone else has faced the same issue.
Here is the workflow:
1. I captured 10x Light frames with Ha filter near the zenith.
2. Immediately after step 1, stopped tracking the telescope at zenith, put a flat box on my Celestron EdgeHD 11" OTA, and captured 25x flat frames for the same Ha filter without changing focus or anything else with ADU value at ~30,000 (I calibrated flats in SGPro).
3. Loaded 10x light frames and 25x flat frames along with master bias and master dark frames (generated earlier for my ASI1600 camera).
4. Generated master flat calibration frame and re-assigned all master calibration frames to my light frames.
5. When I switch to "l-calibrated" view, the light frames look like the edges were over-compensated for vignetting.
6. I tried integration, but saw the same results, which tells me that the flats were not generated correctly.
I am not sure what I am doing wrong, since this exact procedure has worked for me for a refractor. What's different about the EdgeHD 11" that is causing this issue?
Actual light frame in linear view:
Master Flat frame:
Calibrated light frame:
Thanks,
-Rathi.
Hi,
Did you use bias or dark flat for calibration ? I notice that different bias affects flat field calibration too.
Kijja
I used bias, but just for experimenting, I tried with and without bias frames as well. It resulted in the same weird inverse vignetting issue.
I use qhy 163m which has the same CMOS sensor as your ZWO. The over-corrected flat field in narrow band filters was gone after using 0.3second bias. Shorter biases didn’t work with my camera.
Kijja
Hmm, I will try to generate a new set of biases. However, with this set of biases, I don't face any issues when using a refractor. I thought it might be due to the EdgeHD optics. 🤔
It is indeed a thing that a slightly longer sub might help with these sensors. The reason why exactly I can't find at the moment, but it's worth a try.
I tried longer (0.3sec) biases, and I even tried Flat Darks with no luck. I keep getting the over-compensated flats.
Another thing I tried was using sky-flats instead of my flat box, but did not have any luck there either.
Dropbox File (Private or Invalid)Just try your data. My result is exactly similar to yours. So, I think flat subs themselves are the cause of vignette over corrected. Still have no idea why flat subs behave like this.
Kijja
By the way, the integrated image without flat calibration looks good, very few amp-glow is seen.
Thanks for the data link! That's always helpful. I think Kijja shows the problem to be with the flat indeed. As to what might be wrong with them exactly can be difficult to figure out from here. It seems the drop in the flat frames on the sides is simply to big compared to when you make the light frames. That would indicate a change in the optical path between the two situations. Is that the case?
@vincent-mod
No, the optical path was identical. I think I am close to figuring out the issue... I retook the bias and dark frames and the flats started working much better. There is still a very light over-compensation, but much better than before, which tells me the flats are not getting calibrated correctly by the bias and dark frames.
That's interesting as well, then the problem would be those frames as all programs you tried apparently calibrate the flats in a similar way. Could you post a masterdark and masterbias from the ones maybe having a problem versus the new ones?
@vincent-mod
Sure, I added it to the previously posted dropbox link, under the "Masters" folder inside "Newly Collected Calibration Frames". The only difference between the old and the new files I discovered was that the camera offset in the old files were set lower. I had collected the old boas and dark frames a long time ago, so I guess I had forgotten what offset value I had set then.
I agree... I have been making do without flats. In fact, the final processed image looks pretty great without flats, but I would love to be able to correct it further with flats. Here is the final integration: https://www.astrobin.com/417848/
I'll get to them later, but you might have figured the problem out already. Maybe playing around a bit more with the offset eliminates it all together..
@vincent-mod
Yeah, looks like it was the offset, and a lot of folks with the same camera have claimed that using dark flats solves the issue altogether. I'll try all of those.
