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 Mabula, Vincent & Wouter. It seems that a bug has crept into the calibration engine of Beta6, namely when creating a masterflat, this happened, see picture.
Ā
With Beta4, creating the masterflat works properly.
Another thing I noticed is that the image size of the Fits header and Image Viewer differ. Which one is the correct one then?
Ā
I can provide a dataset for testing if needed.
Ā
With kind regards, Henry.
Hi Henry,
Thank you very much for reporting this. It looks very odd...
Can you upload the data on which this happens here:
https://upload.astropixelprocessor.com/
username: upload
password: upload
Make a folder with your name and issue like Henry-MF-trouble and let me know once uploaded š I will investigate and fix it a.s.a.p.
Regarding the dimensions, they are both right actually. The dimensions in the frame list are the actual image dimensions in the FITS file. The image in the image viewer has a raw border cropped off, because it is OSC data, this is normal. So the image viewer reports the dimensions of the cropped image with the raw borders.
Mabula
Hello Mabula, I have uploaded the dataset. The folder is called:Henry-MF-trouble. I hope it helps to find out what happened there.
With kind regards.
Hello Mabula, have you been able to test the data yet?
Hi Henry @minusman,
I am working on the whole calibration engine (optimization for speed and memory) at the moment and I will surely look at your issue in the coming days š so I will make sure it is fixed.
Mabula
Hi Henry @minusman, I am now investigating your issue after a completely updated calibration engine for 2.0.0-beta7, see the release notes:
You have uploaded data in 3 folders where all flats and flatdarks are duplicates per folder. If I make a MasterFlat using the 30 single flats and 30 single flatdarks, all works properly in beta6 and also in the current code with the updated calibration engine. Can you try again in beta6 and let me know the exact workflow that you perform to create the masterflat with this issue, so I can duplicate the issue? For now I can not duplicate it whatever I try. Even when I load the 3x30 flats (so per flat 2 duplicates, all works properly. I do not get the weird histogram and blue pixels in the raw border of the MasterFlat.
I created the masterflat using default and automatic APP settings.
Mabula
Hi Henry @minusman,
I also tried to calibrate the flats with your 600 sec darks to check if that was the issue, but even then, the MasterFlat is not showing your problem.
Mabula
Hello Mabula, thank you for taking the time to do this. That's why I have duplicate flats and darks in every session folder. In order to be able to understand exactly which calibration images belong to which session if I want to process the data again later. I've had problems with that in the past. My approach is true for each session that creates calibration images. I then looked at the master images and saw the colorful pixels on the edge. What made me suspicious, I thought it was a problem with the preview at first and switched back and forth between CPU and OpenGL but the pixels stayed. Then the interpolation deactivated in 0. But the artefacts can also be seen there. Then I looked at the master flats with other software, and there were also true artefacts visible at the edge. Then everything was reprocessed with Beta6 (Linux and Windows version), but the pixels remained. Then I re-transferred the images from the imaging PC again, re-processed again problem remained. New Flats Darks and Darkflats recorded and distributed again, pixels remained at the edge. Then everything was processed with pixinsight, there were no artefacts. So the data seemed fine so far. Then downgraded to Beta4 (Windows and Linux version), processed everything again and there were no more artefacts in the master flat. Then it occurred to me that something broke in the Beta6. Then I reported it in the forum. I might try again on my laptop with Beta6 if it's a machine problem.Ā
Best regards, Henry
Hello Mabula, you have checked it with Beta7. Maybe the problem no longer exists. I would have to test it there also times with version Beta7 if that is possible?
Hi @minusman, I also tested with beta6 and all is fine, I don't get your issue whatever I do. The thing is that between beta4 & beta6 nothing changed in the code relating to how a masterflat is created, so if it would happen with beta6 it should happen with beta4 as well I would think.
Anyway, please try again with beta6 to create new masters and let me know if you again get the issue or not š
Mabula
Hello Mabula, I have tried it with another computer. The same result with Beta6, I have also tested other data. I uploaded the result to the Henry-MF-trouble folder (subfolder Test 2 Bin1x1)including the frames.
Tried something else, I installed APP Beta6 only for me as current user (option 2 in installer "C:\Users\[User]\AppData\Local\Programs\astropixelprocessor" ). And again created different masterflats. See there suddenly everything in order. This of course crazy 🧐 .
With kind regards.
Hi Henry @minusman,
Do you have both 1.083 and 2.0.0-beta6 installed at the same time?
Please do not do this on Windows, it messes up the windows registry it seems and creates weird problems definitely.
I will test now with beta 6 installed for all users, to see what happens here š
Mabula
Hi Henry @minusman,
Do you have both 1.083 and 2.0.0-beta6 installed at the same time?
Please do not do this on Windows, it messes up the windows registry it seems and creates weird problems definitely.
I will test now with beta 6 installed for all users, to see what happens here š
Mabula
@minusman On my computer with beta6 installed for all users, all works fine as well... Seems a windows registry issue then somehow, very weird indeed.
While investigating your data, I see that some of your darkflats have a serious FITS header issue as well. I think you should possibly inform APT that they create bad FITS headers here or somthing is off when the data is saved:
For instance, if I load the (flat) dark :
Cali-Bilder_DF_UVIR-Cut_2022-11-03_23-02-17_11119_3.07813s__-5C_Bin2x2_G120_FP16902_ZWO_ASI294MC_Pro__Color.fit
Our NASA FITS loader indicates:
nov. 18, 2022 5:43:34 P.M. nom.tam.fits.HeaderCardParser parseComment
WARNING: []: Non-printable character(s), e.g. 0x0, in [????????????????????????????????????????????????????????????????????????].
nov. 18, 2022 5:43:34 P.M. nom.tam.fits.Header forceEOF
WARNING: Junk detected at 5855040.
nom.tam.fits.FitsException: Not a proper FITS header: at 5855040
Luckily our FITS reader will ignore this header error, but it indicates an error in how the FITS file is created here.
Ā
Ā
Thanks Mabula, I'll keep watching. And I will forward it to Ivo from APT. Maybe we can get closer. Thank you for the time and best regards Henry.
Hello Mabula, a question about the Nasa Fits loader. Which one is that exactly, or where can you download it? I would like to do some research on my data myself. Best regards, Henry
