Mar 28 2026 APP 2.0.0-beta40 will be released in 7 days.
It did take a long time to have the work finished on this and it will have a major performance boost of 30-50% over 2.0.0-beta39 from calibration to integration. We extensively optimized many critical parts of APP. All has been tested to guarantee correct optimizations. Drizzle and image resampling is much faster for instance, those modules have been completely rewritten. Much less memory usage. LNC 2.0 will be released which works much better and faster than LNC in it's current state. And more, all will be added to the release notes in the coming weeks...
Update on the 2.0.0 release & the full manual
We are getting close to the 2.0.0 stable release and the full manual. The manual will soon become available on the website and also in PDF format. Both versions will be identical and once released, will start to follow the APP release cycle and thus will stay up-to-date to the latest APP version.
Once 2.0.0 is released, the price for APP will increase. Owner's license holders will not need to pay an upgrade fee to use 2.0.0, neither do Renter's license holders.
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.
