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 corner case for you. I'm using a full frame sensor and I love it for 85% of the frame, but the very corners have a severe and rapid drop off in light, so they are heavily vignetted. I mean from 80% of the way to the edge to all the way to the edge it drops from 50% illumination to nearly 0%.
So I have two solutions: Crop about 15-20% of the width, or is there some way to have APP ignore any pixel where the flat is below a certain percentage of illumination. I expect trying to correct an area that is 50% illuminated (i.e. 50% vignetted) may still create somewhat useful data even if lower SNR, but when it drops below some %, I expect you are just scaling up noise and that is very bad. So what I would like to do is reject any pixel where the FLAT for that pixels is below X% (A parameter I set) of the average flat illumination. I don't know what that X% should be at this point (80%, 50%, 25%?).
But this would mean that I can take advantage of all of the sensor that is collecting useful data. Of course my stacked frame won't have many contributing pixels near the edges, no biggie, I'll crop.
And, when doing a mosaic, or a shot with two largely overlapping panels, it'll only integrate good data from the edges that that overlap.
Thoughts? Is there some feature in APP today that essentially does this?
- Steven
@readyjetty I have a full sensor camera as well and it is a ZWO one. ZWO allows for shooting APS-C frames with this camera. Perhaps that's a solution for you as well?
@wvreeven Yes general rectangular cropping is a fallback solution, and even better, with NINA, I can define an overall % crop, so instead of all the way down to APS-C, I would crop a smaller percentage.
I guess I'm trying to optimize and reduce how much unnecessary cropping I do here, because I really only want to crop the width, but better yet, really just the corners.
If I use NINA, it's probably a ~15% all around crop (15% off on both width and height). But that tosses 28% of the camera data. With a strictly horizontal crop, I can probably do just about 20% horizontal only, so a 20% data loss. But if the stacking ignored the corners only, probably only about a 10% loss of data. So I know it's greedy, but every photon counts!
Since I shoot alt/az on my Goto Dob (with short subs), I get a rotated integrated frame anyway, so ignoring the corners makes it a roundish frame, and that actually works really well when integrating a field that can rotate over 90 degrees sometimes. It all works, but this would really make it a super efficient photon gobbling monster, and trimming only what is not good is perfect for shooting offset frames for an expanded integration, or even Mosaics.
So, just like APP has some criteria for rejecting pixels (hot pixels or other criteria), if it also had the criteria to reject any pixels where the flat is out of bounds, that would be awesome for me... I think, based on my assumption on how APP works.
As an update it turns out that NINA has a new (for me) Lucky Imaging plugin that does two very nice things for me:
1) It allows a crop off each of the four dimensions independently.
2) It captures shorter exposures with very high performance, the classic NINA capture can have a 0.5-1.5 second delay between exposures. this looks to be under 0.25 second.
For me that takes short exposures and needs to sometimes crop a tad of the width off the camera, these are very nice features.
However, I’m still wondering if APP has a feature than can cause pixels of the image, for which the flats are below a threshold, to be ignored because their SNR would be too low once rescaled/calibrated using the flat. Pixels are already rejected for various reasons this would be another.
The best solution would be to optimize your light path in the setup. Full frame sensors are quite difficult with most setups as you'd need 2-3" adapters etc. to prevent a dropoff. When calibration with flats, APP tries to use an adaptive pedestal where needed to prevent clipping, but this will still not be actual data and likely still requires cropping.
The best solution would be to optimize your light path in the setup. Full frame sensors are quite difficult with most setups as you'd need 2-3" adapters etc. to prevent a dropoff. When calibration with flats, APP tries to use an adaptive pedestal where needed to prevent clipping, but this will still not be actual data and likely still requires cropping.
Yes, but that is not the equipment I have, so making the best of it here, being creative. Really what would work well is for there to be a way to create a mask of the pixels it should ignore because I do a lot of small mosaics (1x2 and 2x2 Otha a lot of overlap) so I need the pixels ignored during stacking. I can't just crop it afterwards, and with my Alt/Az field rotation, I really need it cropped per capture frame.
So that makes me wonder: How do you notate pixels to ignore on each frame such as hot/stuck pixels? Are they a separate mask or special values in one of the masters or calibrated lights? It seems to me I could create a mask that way by setting all the pixel locations I don’t want to integrate to that value? My vignetting is really in just the corners, I could set all those to "bad pixels" essentially.
Just brainstorming here…
There is no real mask option there, APP uses the BPM and darks to determine the hot pixels, if the automatic options don't work well for you you can change the kappa values in the calibration tab and play around with those (lower kappa values are more aggressive). There is also a batch crop feature that may help you? In the tools window. If you first calibrate the lights and then save those to disk, load them in in the batch crop tool, you can crop the edges for all lights and then proceed with integration. Using the edges that basically have no signal is impossible if there is no data, that's why I mentioned you would either need a setup that allows signal there or a crop sensor like Wouter mentioned or the batch crop tool, that tool allows for only cropping height or width I believe.
@vincent-mod
Thank you for the response and taking the time to think about this and to make the suggestions. I’ll learn about how those features work and play around with them.
I was curious how pixels were ignored that are tagged by the bad pixel map. But I see you try to reconstruct a good pixel from interpolating from neighboring pixels versus just ignoring it and not integrating it (giving it a weight of zero). That is what I expected you to do, it’s the most logical for distributed spurious pixels, so it wouldn’t work for a region of bad pixels. So can’t repurpose that as a mask.
