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.
Mabula
I've recently run into an issue when stacking light frames. At first I thought it was something to do with corrupted master bias frames, so I generated a whole new set of them, along with new dark, flat, and BPM files.
I was able to successfully stack the LUM frames, but when I went to the RED frames, this was the result. I was having the same issue when stacking DSLR frames from last week as well, so it is not camera dependent. Is it a problem with outlier rejection maybe? I have attached two images, the file names delinate them. Also notice how much smaller the image file is with the BIAS frames included in the stack.
Thoughts?
Eric
Hi Eric,
I suspect this has nothing to do with outlier rejection. I suspect the problem would be in calibration somehow.
Can you please share the following information:
What kind of camera?
Is it mono or does it has a CFA sensor?
Did you alter settings in 0) RAW/FITS ?
What type of calibration frames did you use ? Only bias or bias + darks or bias + flats or ???
Probably there is a clear explanation but I need some more information.
Kind regards,
Mabula
Mabula
QHY163M - mono
Stock settings in 0) RAW/FITS
I built a library of darks, flats, bias and a BPM masters. I used all of those in the integration. Like I described, if I remove the master bias from the stack it works normally - albeit without the bias removal, but since that is included in the flats data, probably not a big issue. Is it because I am using flats and bias together that there is a problem?
Thank you, looking forward to the 1.055 release!
Eric
Hi Eric,
Okay, yes, this is what I suspected. If it works correctly without the masterbias and just a masterdark, masterflat (bias subtracted) and the BPM, that would indicate that the masterdark isn't bias subtracted.
So if you subtract a masterbias and a masterdark of which the bias isn't subtracted, from the light, the bias pedestal will be subtracted twice. That should be the explanation for the too dark image.
The QHY163 has the same sensor as the asi1600, right? I know this sensor has some amp glow with longer exposures. So I would think that the calibration path without the masterbias for the light frames is the way to go 😉
(And the bias is part of that masterdark anyway)
Let me know if this is clear 😉
Kind regards,
Mabula
Mabula
Why would it be that the Master Dark would not have the bias removed? I created all of these Masters at once - with two runs required after the BPM was created on the first one.
Is that the preferred technique or should I make each one separately and then include each in the final integration stacking procedure?
I migrated my data to a new SSD drive yesterday and it did help a lot with processing time, but the new version is much anticipated.
Thanks again,
Eric
Hi Eric,
If you created all the masters at once, then possibly the darks and bias had different iso or gain settings ? Otherwise the bias should have been removed from the darks. If not, maybe I need to check the data?
Currently, in APP's calibration engine, if you need to correct your light frames with darks, I recommend to only use darks and don't use bias for the light frame calibration. I a future version, the calibration engine will become smarter and should make this issue redundant. It's already on my priorities list. Currently it can be a bit confusing I understand from several users, so I will work to improve this.
Kind regards,
Mabula
