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.
Hello,
I'm enjoying APP so far. I have one question - is it able to bin the integrated image? I notice you can select a "scale", but I don't think that's what I'm looking for. I'd like to have the option to combine the nearest 4 pixels into one, to increase S/N and greatly increase sensitivity. The resulting image would be half the length and width. I have done this in a program called Sequator with really good results. It could be a killer feature.
Hi 1llusiveAstro,
That's great to hear 😉
Actual binning your image is not possible currently, but a tool could be made fairly easy for this.
On the hand, what you want to accomplish is possible with APP using the batch rotate/resize tool.
You simply need to select
- nearest neighbour data interpolation
- and a resize factor of 0,50.
In down-scaling operations, the data interpolation will use 4 pixels in this case to reconstruct the new pixel ;-), since nearest neighbour is used, it will be the average of the 4 pixels, just like binning.
The upsides of this method are that it's much more flexible than just binning:
- You can use any rescale factor and
- you can use more advanced data interpolation kernels that will preserve the resolution of your data better.
Binning is only removing resolution, thereby removing information and small scale noise that will indeed give the image lower noise, but also less sharpness as you are well aware. You're simply trading resolution for lower noise.
From literature and experience I would recommend to use the following, instead of binning:
- Cubic B-Spline data interpolation (will preserve more detail but will be very smooth as well)
- and a resize factor of 0,50.
And in APP, you can actually directly create the integration using such a down-scale operation if you wish. Just set scale of integration to 0,5 and use Cubic B-Spline for data interpolation.
As an example, here is a crop of an integration of some pretty old data of my own. It's the Cocoon Nebula, shot with a Robtics 102ED doublet APO and a Nikon D5100BCF mod and a Baader UHC-s filter. 2,5 hours epxosure time in subs of 5 minutes, iso 400. Only calibrated with a Bad Pixel Map.
I integrated the data and post-processed up until star color calibration in APP. this is the crop at original size:
Antd this is the same image downscaled using Nearest neighbour and 0,5x scale:
Together with a Cubic B-spline version at top right (bottom right is Nearest Neighbour, left is original) in a mosaic of 3 images (can you tell the difference?):
To make it a bit more clear, further zoomed in original:
And downscaled with Cubic B-Spline:
the original and down-scaled version next to each other, the loss of resolution is clear, as is the reduction in noise:
Let me know how the down-scaling works for you and if you think a binning tool would still be usefull 😉
Kind regards,
Mabula
I'd like to just confirm that the details in this thread still represent a good method for downsampling after the fact. I prefer to not bin in the camera driver, but when the pixel scale makes sense to do so I'd like to "bin" 2x2 after the fact, without batch processing all the subs individually before integrating.
Is it still a valid and preferred method to set the integration scale to the desired factor (0.5 for 2x2) and set the pixel interpolation filter to Cubic B_Spline? Or is there a better method 3 these days?
Are there any other relevant settings when doing this? Does the Kernel shape play any role for interpolation or is that only used for drizzle?
My main reason for "binning" is for the SNR advantage when the native pixel scale is oversampled. However, I'd still like to be able to drizzle, especially when reducing the data resolution with "binning." Interpolation and Drizzle are mutually exclusive in the integration options. Is there a method to drizzle downsampled data and does it make sense to do so in APP? If there is currently no method to downsample and drizzle when integrating, is this a use case for an integration tool change or a new "binning" tool?
Put another way, what is the best workflow to "2x2 bin" data to increase SNR, then drizzle integrate the now slightly undersampled data?
Thanks!
In another program, when I chose to do this, the image got brighter. It was a way of combining the light of the surrounding pixels. The description of the feature states:
"Merge neighbor 4 pixels to increase sensitivity. However, the result will be downsized to 1/4"
I suppose the method described above does the same thing, but only averages the noise instead of using the pixels to increase sensitivity. Right?
I know it's an older post but nevertheless. I'm also interested in software binning after calibration because I've an Altair 183M with fan cooling and a good dark database is already not easy even without binning.
I think from an SNR point of view, it might be even better to do the binning after integration if one uses clipping algorithms. Without clipping and just doing averaging, it shouldn't matter unless there's a non-linear process in between.
My actual point, the definition of "nearest neighbor" interpolation confuses me and I would like to confirm on this: in APP this means that it's averaging the values of the nearest neighbors and is not just taking the value of the nearest neighbor, correct?
The definition that I've seen in many applications is the latter. Could you clarify this somewhere through a tool-tip entry or maybe IMHO a more proper name, e.g. "nearest neighbor average"?
Björn
I'd like to just confirm that the details in this thread still represent a good method for downsampling after the fact. I prefer to not bin in the camera driver, but when the pixel scale makes sense to do so I'd like to "bin" 2x2 after the fact, without batch processing all the subs individually before integrating.
Is it still a valid and preferred method to set the integration scale to the desired factor (0.5 for 2x2) and set the pixel interpolation filter to Cubic B_Spline? Or is there a better method 3 these days?
Are there any other relevant settings when doing this? Does the Kernel shape play any role for interpolation or is that only used for drizzle?
My main reason for "binning" is for the SNR advantage when the native pixel scale is oversampled. However, I'd still like to be able to drizzle, especially when reducing the data resolution with "binning." Interpolation and Drizzle are mutually exclusive in the integration options. Is there a method to drizzle downsampled data and does it make sense to do so in APP? If there is currently no method to downsample and drizzle when integrating, is this a use case for an integration tool change or a new "binning" tool?
Put another way, what is the best workflow to "2x2 bin" data to increase SNR, then drizzle integrate the now slightly undersampled data?
Thanks!
Just a small remark here on the described workflow @ohmeye, binning first to increase SNR (artifical SNR increase by downscaling, no real improvement) and then Drizzling to restore resolution will not maintain the gained SNR because the drizzle itself will inject noise... I am not sure why you would want to do this because drizzle is not magic in the sense that it will restore your resolution and remain the SNR of the binned data 😉
Cheers,
Mabula
In another program, when I chose to do this, the image got brighter. It was a way of combining the light of the surrounding pixels. The description of the feature states:
"Merge neighbor 4 pixels to increase sensitivity. However, the result will be downsized to 1/4"
I suppose the method described above does the same thing, but only averages the noise instead of using the pixels to increase sensitivity. Right?
I can easily make a bin2x2 algorithm to bin your data even before calibration, but I think it will be of less quality for several reasons when compared to processing at native resolution and then scale the integration combined with a suitable resampling filter like Cubic B_Spline which works like a gauss filter in it self.
Mabula
I know it's an older post but nevertheless. I'm also interested in software binning after calibration because I've an Altair 183M with fan cooling and a good dark database is already not easy even without binning.
I think from an SNR point of view, it might be even better to do the binning after integration if one uses clipping algorithms. Without clipping and just doing averaging, it shouldn't matter unless there's a non-linear process in between.
My actual point, the definition of "nearest neighbor" interpolation confuses me and I would like to confirm on this: in APP this means that it's averaging the values of the nearest neighbors and is not just taking the value of the nearest neighbor, correct?
The definition that I've seen in many applications is the latter. Could you clarify this somewhere through a tool-tip entry or maybe IMHO a more proper name, e.g. "nearest neighbor average"?
Björn
Hi Björn @barnold84,
Nearest neighbour applies to the resampling/interpolation filters that you can use to reconstruct the data while applying the registration/alignment parameters. Nearest Neighbour interpolation should never be used/chosen normally because it will create artefacts and will not maintain resolution. It is only good to preserve noise actually 🙂 All other filters will change the noise levels.. when compared to the original image.
Nearest Neighbour Interpolation/Resampling in APP uses the "nearest neighbour" and it is NOT averaging the nearest neighbours as it shouldn't. Then it is not nearest neighbour interpolation in principle. Then it would become the well-know bilinear interpolation, where the 4 nearest neighbours are bilinearly averaged using a simpel filter kernel.
Indeed, you could alter bilinear interpolation to simply average those 4 nearest pixels to make a filter which performs between Nearest Neighbour and Bilinear in terms of quality, but I see little use for that. Bilinear is superior to Nearest Neighbour already and it will be better than this "in between" filter, no doubt.
Mabula
Hi Mabula, @mabula-admin
I guess I should have been more precise in my previous description. What I did is to use the batch resize tool and downsampled by 0.5 using nearest neighbors. To confirm my assumption, I used an artificial image which consisted of pure RGB colors patches and it seemed that at the borders, the colors have been averaged, e.g. at the B-G boundary, the color became cyan as it is the average color of B and G.
I guess a bilinear downsampling will likely behave similar at a factor of 0.5. But my question was rather that the nearest neighbor downsampling behaves like an average binning?
Based on my test it seems to be that case.
Björn
