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.
@minusman much appreciated. Â I have been told by the techs at ZWO that in order for the camera to calibrate properly that I should a) NEVER use bias frames, and; b) take 3 second flats and dark flats at the same temp as the light frames (-10).
I have a tough time getting the flats right but I just ordered a spike-a flat to help. Â
Â
The issue is with my technique, not the camera, correct?
If I calibrate the data with MD and BPM only, it looks like this. Only the expected vigentte and dust remains in the picture.Â
When I calibrate the data with MF, MD and BPM, it looks like this.
The color gradient of the masterflat is also introduced into the calibrated light. Which light source do you use for the flats?
Â
T shirts over the telescope and a morning sky... hopefully the spike-a flat will be better?
The ZWO technicians are right, do not use bias frames, only darks and dark flats. For the flats, expose so that you stay 3 seconds or more. At exposure times below 2s the camera shows a non-linear behavior (post in Cloudy Nights forum). In addition, the USB cable of the camera can cause problems. I replaced it with a high quality one, because the cable that comes with the camera is not that good. This manifested itself with me in horizontal really wide stripes.
@minusman I have seen that banding as well! Â Can you post a link or point me to the USB cable you prefer? Â I have all kinds of problems with banding when I use my IDAS NBZ filter on 30 second subs at f/7. Â The banding shows up in my light frames as well... did not show up on my lights when I did not use the filter on this galaxy... that is why I am asking if the camera looks all right.
Â
I think the spike-a flat will also help. But would still absolutely look for light leaks. I stood in front of the telescope and looked in at the front, illuminating everything from the dew shield to the camera with a flashlight. I noticed that light can penetrate the dew shield, ventilation holes and filter drawer. This can ruin a successful calibration.
M.f.G
The diagonal stripes are walking patternoise. These can only be removed with dithering. Because of the cable I have to search where I had ordered.
Right! Â Hard to do on an Evolution mount! Â A local astronomy club just lent me an old HEQ5 that I will try out.
This is what the stripes looked like in my case. Wide bluish stripes.
This is what the stripes looked like on me. Wide bluish stripes. In the finished stack, they were barely to miss and just as hard to get rid of in post-processing.
This is the USB cable.
Â
Found the cable! Â Is 1m ok?
1m is fine I think. 😉
Hey Lucky Budd. I had the same gradient problem with my ASI294mc pro. What offset setting are you using? I was able to mitigate this effect by lowering my offset value to 10. There seems to be a lot of variability with the amount of background noise in this sensor. According to ZWO, Sony says these sensors are all within parameters.
There are extensive threads about this on Cloudy Nights.
Hope this helps
John
@neaptide hey John, Thank you!!  I have been working with a tech as ZWO as my sensor seems to be particularly noisy.  I will try your offset trick!  It seems to be particularly accented when I use my IDAZ NBZ filter, perhaps it brings up the background?  The data this camera captures is awesome, but for an advertised "Low Noise" camera there seems to be a lot necessary to get rid of the banding!  🙂
Hey Lucky Budd,
I'm super late to the party, but I wanted you to know that I had this very same issue of wave patterns impacting my images as well and found my problem to be batch cropping in APP and saving as 16-bit TIFF files. Instead, I now save batch crops (if/when they are done) as 32bit Floats and then after all is said and done, I go and save the final TIFF files as 16 bit TIFFs. That appears to have removed the waves from my images. I'm using a William Optics RedCat 51 f/4.9 with a ZWO ASI2600MC-Pro OSC. Bortle 8+ skies in DC region with plenty of light pollution in my immediate vicinity too. And the occasional moon 🙂Â
FYI - I found this solution before finding your post, but it's good to see we both found a similar solution. I'm going to continue testing, Mabula, and if I see this to be a more consistent issue, I'll be sure to let you guys know. And to let my subscribers know too as some are using APP and may make this same error unintentionally when preparing to export their data for post processing (particularly if they are like me and do some of their final edits in Photoshop, Lightroom, etc.).
Clear skies all!
Chris
