2026-10-09 APP 2.0.0-beta48 has been released !
This is mainly a bug fix release for the reported bugs in beta47. In addition it has a significant User Interface performance improvement noticable when you need to process 1000s of images in APP.
2026-10-03 APP 2.0.0-beta47 has been released !
This is a very big release... many code optimizations/rewrites, many parts of APP are much faster and more precise, especially star analysis and registration are much faster ! Big mosaics will go much faster 🙂
And we introduce a new preview filter, which includes the new Adaptive Deep Sky Stretch and a General Levels Stretch, this has been long over due. The old preview filter (the panel on the right side to stretch and preview your data) has not been updated for a couple of years and it is a critical part of any APP session.
Adaptive Deep Sky Stretch or ADSS is a much more intuitive stretch algorithm. It is also color preserving (which is a great new addition in itself ! ) which means that the highlights are no longer bleached, color is maintained from the linear data while stretching. You can simply stretch your data using the sky background level and signal width sliders which work much easier and more intuitive. You no longer need to fiddle with the old complicated sliders with zoom buttons. All the zoom buttons for the sliders are made redundant. And you can enter slider values in the slider value fields yourself. I will make a youtube video in the coming days to explain and fully introduce ADSS. Once the video is ready, it will be highlighted on the forum.
RGB Combine upgrade !. The RGB Combine Tool has been rewritten mostly. The tool is faster and easier to use and most importantly, the Luminance slider to inject a luminance channel or channels into the RGB composite is now working correctly. It no longer bleaches the RGB colors. Combined with the new ADSS preview, you will get much better and easier great composites with great color! I will also explain this in a new youtube video.
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
