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 captured some 16-bit raw FITS with my ASI2600MC. So being at 26 megapixel camera, they are about 52 megabytes each. So far so good.
So I bring a few into APP's crop tool and crop off 400 pixels on the left and right, so about 14% and save as 16-bit Integer FITS.  They exploded to 134 Megabytes each, I think they may be 6 bytes per pixel.
What am I doing wrong?  I just want a 2-byte/pixel FIT that is cropped.
I'm able to capture cropped FITS in NINA and it doesn't cause the file to expand like this. The issue with NINA is that the cropping is limited to a % from all sides (ex: take of 10%), but I want to only crop the left and right due to severe vignetting in the very corners.
 Did it debayer it?
OK, more information, it looks like cropping debayers the image.  I cropped and saved it as a TIFF and it really looks debayered.
Can't I crop a RAW and keep it as RAW undebayered?  I mean, I know you have to respect the bayer 2x2 matrix dimensions when cropping, but that just means respecting the bayer matrix by cropping by 2 pixel increments, but man... I really want to crop a RAW and keep it as a RAW, I think....
If I stack these now debayered images, do I lose anything?  They are sometimes broadband RGB and sometimes dual narrowband and I want to stack as "Ha-Oiii extract Oiii", can I still do that? Can I still align the color planes in the calibration step? Do I lose anything?
Hi Steven @readyjetty,
Indeed, if you perform batch crop, the images will be debayered so they will go from mono CFA (Color Filter Array) data to 3-channel RGB data.
Integrating already debayered data has a downside yes, you will not be able use Bayer Drizzle for instance, or process the data with another demosaic algorithm.
I strongly advise you to only start cropping the data after having calibrated the data with your calibration masters. Otherwise you need to crop the calibration subs exactly like the lights !, you need to have the exact same crop offsets.
Now, luckily there is already a workaround for you in the current APP version 2.0.0-beta9, you can use the batch modify FITS metadata/CFA tool which does enable you to undebayer the data again 🙂 If your cropp offsets are an integer factor x 2 on top and left side, you need to use the same Bayer pattern as normal, otherwise, you need to use one of the others and it will be okay.
I have added to our issue list, to provide the option that you can batch crop OSC data while keeping the undebayered data 😉
Mabula
Â
Wow, thanks for the help, this is wonderful. I do know I would have needed to crop the calibration frames the same way. When I capture NINA data with a crop, I use the same crop for Lights, Bias, and Flats and it works well.
Â
I'll think about how to approach this as I do both RGB broadband and dual narrowband OSC (ha oiii) demosaic algorithms.  Because I sometimes do several debayers on one data set, it would be nice to crop but still have undebayered data in some cases, but if strictly broadband RGB, it would be fine for me to do it in two steps. Â
So let me outline what I understand from you just to double check. For broadband data that I'll only be doing basic RGB debayering:
1) Save calibrated frames (I often do this to align color channels anyway)
2) Crop the calibrated frames
3) Stack the cropped and calibrated frames.
Â
Â
For dual narrowband (Ha Oiii) if I want several debayer types, I'm still a bit unclear. Here is a guess on what to do, but with low confidence:
1) Save calibrated frames with RGB debayering
2) Crop the calibrated frames by even multiples of 2 pixels to keep same debayer
3) Use your batch modify FITSÂ metadata/CFA tool to undebayer
4) Now reload as raw FITS and use "Ha - Oiii, extract Ha" or any other dual band Ha/Oiii debayer as before
Â
Yes, a debayer friendly crop for all of the frames (lights, darks, bias, flats) as part of the front end stages would be great!  I use a camera that is a bit too big a sensor for my illuminated field, but I really only need to crop a bit off the width, this would be an excellent tool for me.
