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.
I have an FLI proline I use from KStars/Indi/Ekos. The camera images include 2 overscan regions. Is there a way to have APP process the overscan or skip.
Thanks David !
How do you save the overscan? Do you select it as an option in the capture application?
Or is it special metadata in the fits headers? Probably I need to see exactly how it works for your camera to be able to implement this.
Mabula
The overscan is always in my FITS file from the Indilib FLI driver which uses the Finger Lakes Instruments Linux driver. Unfortunately there aren't any keys in the file to describe the overscan region. I've contributed to this driver for Indi and could reach out to Finger Lakes to see if they know of any "standard" format for adding overscan keys to FITS files.
I found I could use your crop tool to remove the overscan , in my case its a 40 pixel wide strip across the top and a 40 pixel wide strip down the left side. I could just set the offset to 40,40 to crop it out. So I have a workaround that pretty easy to apply.
If you'd be interested in processing the overscan I could reach out to Finger Lakes to get their input on adding FITS header info describing the overscan and look at adding it to the Indilib FLI driver. Only if you think this is worth it for APP long term as I'm good for now.
Best,
David
Hi David @deisenlord,
Excellent, yes the offset crop tool is the answer to be able to remove the overscan from your calibrated files before starting with registration etc...
Yes, if they camera maker/capture software maker adds overscan information in the metadata/fits header, it will be very easy to fix in APP 😉
Without the information in the metadata, it will become very cumbersome quickly.
Another way would be to provide the overscan offsets manually in the calibration menu. So then, after calibration APP can automatically remove the overscan based on the supplied offsets. I can implement that fairly quickly I think. Would that be a good option/alternative?
Mabula
This is the way PI handles it in their Batch Processing Script, a set of fields where you can describe the overscan regions. The documentation is non-existent so it took a little messing around to get it specified correctly. I researched FITS keys and it seems the BIASEC and TRIMSEC are commonly used in research environments, but certainly not always, example.
BIASSEC= [2054:2101,10:2045]) Overscan strip image section
TRIMSEC= [51:2002,51:2002]) Trim data section
I'm pretty sure this isn't used enough to warrant implementing though, I think your idea of adding options in the calibration menu would be more widely applicable and a better solution.
Hi David @deisenlord,
I will study the FITS specification for these tags.
Indeed, providing overscan offsets in 2) calibrate at least should work always then.
This is on my ToDo list to implement.
Thanks for bringing this to my attention 😉
Mabula
