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 loading up ZWO mono files it is apparent that the FITS header is wrong. I have contacted ZWO and they have fixed it on more recent camera software. My questions: 1) will this have an effect on the image processing (1.082) if the FITS data is wrong? the preview screen shows colors which tells me it APP seems to use the FITS data. 2) will APP allow me to fix the FITS headers on older files?
Specifically the 'BAYERPAT" value is set to GRBG, when it should be set to none, or no BAYERPAT should exist.
What imaging software and which version of the ZWO driver did you use? I checked my mono images taken with Ekos (on Linux) in June 2020 and the BAYERPAT keyword is not available in the FITS header. Is the FILTER keyword present in the FITS headers of your images and does it have the correct value?
@randy-dunton To answer your two questions:
1) Yes this will have effect on image processing in APP, however this can be prevented. In tab 0 you can choose No Interpolation. That will completely ignore the BAYERPAT keyword and will treat your data as grey scale.
2) FITS headers cannot be edited in APP. But with the option given in answer 1) this should not be necessary.
Thanks Wouter !
I will redo the processing using the "no interpolation" option. Looking forward to a full manual on APP.
I use ASICAP V 1.6.2, I do not like the newer versions of ASICAP (less control), I will see if I can fix this issue as well.
Here is the FITS header as it is read by APP on my Ha channel, the FILTER keyword is not there it seems, but BAYERPAT is. Deep Sky Stacker was also having problems with this, they added a feature to read the FITS header just recently.
ZWO fixed the problem recently on ASICAP and the driver, I just have 2 years of data I need to reprocess with APP, so looking for a solution. Thanks again for you prompt help in this matter.
Kind regards,
Randy Dunton
Phoenix Arizona
Â
FITS HDUs: 1
HDU1 - SIMPLE = T / file does conform to FITS standard
HDU1 - BITPIX = 16 / number of bits per data pixel
HDU1 - NAXIS = 2 / number of data axes
HDU1 - NAXIS1 = 4656 / length of data axis 1
HDU1 - NAXIS2 = 3520 / length of data axis 2
HDU1 - EXTEND = T / FITS dataset may contain extensions
HDU1 - COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
HDU1 - COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
HDU1 - BRIGHT = 10 / Brightness of image
HDU1 - BSCALE = 1 / physical = BZERO + BSCALE*array_value
HDU1 - BZERO = 32768 / physical = BZERO + BSCALE*array_value
HDU1 - CBLACK = 0 / Initial display black level in ADUs
HDU1 - CWHITE = 65535 / Initial display white level in ADUs
HDU1 - EXPOINUS= 180000000 / Exposure time in us
HDU1 - GAIN = 180 / The ratio of output / input
HDU1 - PEDESTAL= 0 / Correction to add for zero-based ADU
HDU1 - XBINNING= 1 / Binning factor in width
HDU1 - YBINNING= 1 / Binning factor in height
HDU1 - BAYERPAT= 'GRBG ' / Debayer pattern,such as RGGB,BGGR,GRBG,GBRG
HDU1 - COLORTYP= 'RAW16 ' / Color space, such as RAW8,RAW16,RGB24
HDU1 - CSTRETCH= 'Medium ' / Initial display stretch mode
HDU1 - DATE-OBS= '2020-11-26T01:44:26.884' / UTC start date of observation
HDU1 - INPUTFMT= 'FITS ' / Format of file from which image was read
HDU1 - SWCREATE= 'ASICAP ' / Name of software that created the image
HDU1 - SWOWNER = 'ZWO ' / Licensed owner of software
HDU1 - XPIXSZ = 3.8 / Pixel Width in um (after binning)
HDU1 - YPIXSZ = 3.8 / Pixel Height in um (after binning)
HDU1 - END
My pleasure. Please let us know here if this solution worked in case other users encounter a similar issue.
Wouter
I seem to have the same problem. Â I have a QHY600M which I am using with kstars/ekos. Â The FITS files contain BAYERPAT RGGB by default and I can change it to say Mono but there doesn't seem to be a way to have it not write something in that field. Â If I change it to Mono and try and process some dark or bias files then it shows CFA is mono and color space Gray 16b on the images but the integrated file color space is 16b RGB.
 When doing the integration it goes through R, G1, G2, B channels in producing a bad pixel map.
Force CFA is disabled.
If I try no interpolation then the integrated master bias is still 16b RGB color space and it does the R, G1, G2, B channels to produce a bad pixel map.
The integrated Dark file has color channels but the RGB all appear to be the same. Â Maybe this is the correct form for Dark for APP from mono?
