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.
Hello,
I have one of the new QHY268c CMOS imx571 based cameras, and am reading more and more that Darks and dark flats are just not needed with these cameras, and all you need is Lights, flats and bias, is this correct, as the sensors are so clean that darks and dark flats are just not needed, now what about hot and cold pixels, well won’t they be sorted in dithering and or rejection during the stacking…??
I realise different cameras require different calibration, but my concern is am I wasting time on a dark library if not needed…..with my camera….
Or am I hearing incorrect information..?
cheers 👍🏼
Some sensors do behave very nicely. But hot pixel detection I think would still be necessary (though I don't know the details of this sensor in particular) and while dithering solves that to some extent, it won't be 100%. I would still make a dark library and just test it out, they can be used for quite a while and don't take too much time when the skies are clouded anyway. ;)\
Another option would be: Create a nice Bad Pixel Map from a proper long dark and use that instead of the darks in most cases. That might be a good thing to try as well, create a long dark without any cooling to get it noisy, make a BPM out of that and us the BPM instead of the darks for all your exposures. Of course, this only work well when there is no amp-glow whatsoever.
If you use flats, they do need calibration from the bias signal, so for the flats I would still use dark-flats.
Dont the hot and cold pixels get rejected in calibration anyway, aren’t they sorted there…??
Amp glow is a thing of the past with this 16 bit sensors, it’s been eliminated
They are sorted in calibration yes, by the use of darks or a Bad Pixel Map.
Some sensors do behave very nicely. But hot pixel detection I think would still be necessary (though I don't know the details of this sensor in particular) and while dithering solves that to some extent, it won't be 100%. I would still make a dark library and just test it out, they can be used for quite a while and don't take too much time when the skies are clouded anyway. ;)\
Another option would be: Create a nice Bad Pixel Map from a proper long dark and use that instead of the darks in most cases. That might be a good thing to try as well, create a long dark without any cooling to get it noisy, make a BPM out of that and us the BPM instead of the darks for all your exposures. Of course, this only work well when there is no amp-glow whatsoever.
If you use flats, they do need calibration from the bias signal, so for the flats I would still use dark-flats.
This is good advice - I use a QHY268 and have done extensive tests with darks, and across visual comparisons and statistical noise comparisons in different programs couldn't see any meaningful difference. I have a TON of hot pixels however (when I am shooting with a duoband filter at least), and making a solid BPM via this method works very well to remove them. Vital part of the process IMO - especially since I have backed off a little on the frequency of my dithers, due to my mount taking a while to recover and the super low amount of fixed pattern noise on this sensor.
Hi Vincent,
I’m relatively new with APP and astrophotography in general, but had a question regarding creating BPM’s for IMX571 cameras suggested in this forum. I own an OSC RisingCam IMX571 and want to ensure I calibrate most effectively, efficiently, and consistently. You mentioned creating a BPM from a long, noisy dark. Could this be created from just one dark? And can it be created on its own (no lights, flats, etc…)? And when created, can I just use the BPM along with flats and dark flats only, for future use?
Thanks,
David
This can be done with a single dark yes and it can be created on its own, just load the dark (or a few darks) and let it create the masters (leave the BPM creation checked of course). This BPM can be used with any processing it never destroys data basically. If your sensor doesn't have amp-glow, you may even see if it's enough to only use the BPM without darks. A BPM can typically be used for a year or even longer, but of course your sensor characteristics will change, so do check from time to time if it still performs well. You can easily do this by zooming into hot pixels of 1 light, add the BPM and then switch to "l-calibrated" on top of the preview window. APP will then calibrate a single light and show you what happens with your calibration data added, before you'd have to wait for an entire integration.
Thank you! One point of clarification, could the BPM substitute for both bias as well as darks in this case?
No, a BPM is there purely for hot and cold (you need flats for that, though modern sensors almost don't have those anymore) pixels. Bias or darkflats are required for proper flat calibration.
