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 have a strange issue that I can't seem to track down.Â
I am using an ASI6200MC Pro Full Frame camera. On processing images last night (Ha-Oiii Color) I noticed exactly (it appears to be exactly half) of my image is processed differently than the other. I can see a delineation line. The attached pic is obviously reduced andsuper brightened to try and show the problem more clearly.
I have
- 10 min subs as 16-Bit Flats
- Flats 22K ADU + DarkFlats
- Master Bias
- Darks
- BPM
So just a number of questions to get to understand it a bit better; is this a mosaic or just a large FOV? How do you create your bias frames and could you show me the master-bias? Are you using LNC?
Â
This is a full 9756x6388 FITS.
Bias was shortest exposure - I went for 0.002 seconds. Master Bias is 122Mb in size. Where can I upload?
Right, so maybe just an screenshot of the masterbias? I just need to see the quality of it as some sensors also have problems with using the shortest exposure for a bias, which is especially an issue with CMOS sensors. As your sensor is a relatively new one, I'd advice to make the bias frames at about 0.1 seconds as a minimum or use dark-flats.
Flats I'd also advice at around 32000 ADU.
Here's a screenshot. Looks ok?
Â
Could you stretch it a bit more? Difficult to say. I would advice though to try another processing with your darkflats being the only bias. Selecting LNC with 3 iterations and checking again.
As soon as you said about the Bias I'm giving the process another go and it didn't make a difference.
I've tried 16K, 22K, 26K and 32K ADU Flats (and associated DarkFlats) as only had this camera for 48 hours so still trying to work out what is really required so no changes.
Given this is appears to be a 50% split, are dimensions of the FITS a factor? Whilst I've had mosaics processed in APP before, is this a 4k limit somewhere, given 4096 is around about half of the 9k wide resolution of this?
There are no real limits to that no, so it wasn't clear to me but this is indeed a mosaic? If so, you did have MBB on as well set to about the % of overlap?
Not a mosaic - a full-frame sensor FITS.
Ok, thanks. It's rather difficult to tell without the raw data, is a zipped light sub very big still? Maybe I can have a look at some raw frames.
I'm going to just put this on hold for now as it could very well be the data captured - though I can't see it clearly at all in my individual subs. I just processed another target from the same night, further away from the bright moon, and it appears to be fine. Same optics/setup/length of exposure, etc. So for now I'll re-test on a moonless night if the stars align in a couple of weeks!
Ah right, some residual gradient in the background maybe. Light pollution correction doesn't help this at all? I always advice to really stretch the image in the preview window, over-saturate the backgound as well and then slowly start with 5 boxes around the image, then add some more when it seems the gradient model looks ok (which you can check with "show corrected image" button). This might show a light source (the moon) somewhere on the side of the image. Which then would be a good correction model. I'm always looking for the background to become nice and even.
