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.
Dear APP Team,
sometimes I use Siril with Sirilic to calibrate and stack my raw files captured with my ASI294MC pro color camera and Optolong L-extreme filter. The advantage is, that Siril is able to process the Halpha and OIII stack in one session and - is still faster than APP (even when APP 2.0.0 is in the meantime much faster than the 1.9.x version).
When loading the resulting OIII output file (32 bit float fits format) into APP the autostretch result looks much to dark and the histogram looks strange and cut on the right side.
To load the file I use either Load as Light or Load other/processed – the result is the very same.
The funny point is, that the Halpha output file processed in the same session can be loaded and displayed without any issue.
I have attached a screenshot of the result when loading the OIII or loading the Halpha picture.
Remark: Fitswork or ASIfits viewer have no issue to display the OIII fits file.
Can you may check, why the OIII pictures make problems to be loaded and displayed in APP? I really like APP for the further processing of these files.
Thanks a lot and best regards
Ralf
Unfortunately I don't have experience with Siril and what it exactly does to the data. I would need to look at some of the data to see, can you provide like 10 raw lights and calibration data, together with Siril processed files?
Hello Vincent,
thanks a lot for your fast reply. I have created the folder "rhe2sifreenet-de-siril" and uploaded the raws, calibration and output files.
Hope you can find the issue with the O3 output files.
Thanks a lot for your effort and support and CS
Ralf
Hello Vincent,
did you have a chance to check my uploaded files already? Would be great to hear from you.
Thanks a lot and best regards
Ralf
Hi Ralf @rhe2sifreenet-de,
Thank you, Vincent is not available at the moment, but we have your uploaded data. I will have a look at what is happening and fix it. I do know that Siril data earlier also gave issue because of not controlling float precision errors. Maybe that is the case here again and this could upset our automatic stretching which is probably why this problem exists.
Mabula
Hi Ralf @rhe2sifreenet-de,
When processing the data with APP all is okay and fine. And i can confirm that the issue with the Siril O3 stack a problem is with APP's preview filter which is caused by Siril not conforming to normalized floats in the 0-1 range. I checked max and min values in the O3 stack, and they do not conform to normalized floats between 0-1 which they should I think. Weird thing is that the Ha stack does conform to this range. (Other applications like Pixinsight and APP strictly confirm to this data range when they produce 32bits float stacks.)
In the screenshot below you can see what Nasa Fits liberator shows, the O3 stack is on the left, the O3 stack has even negative values and values way over 1... while Ha is correct.
In total almost 2000 pixels are not in the data range... and these are all scattered over the field of view and are likely burnt out pixels in star cores I would think.
Edit, if i clip all pixels smaller than 0 to 0 and all pixels > 1 to 1, the image is fine and it looks correctly. So this must be marked as a Siril bug if you would ask me, it does not clip the data at points were it should or it should add header tags about the data range so other applications can understand how to interpret this. This is also missing, so normally, no application would be able to show this correctly without making assumptions about the data actually confirming to the 0-1 data range.
But, I will try to fix it on our end to still stretch this correctly.
I will use your data as well to implement that APP will create the Ha and O3 extract stacks also in 1 go 😉
Mabula
Hi Ralf @rhe2sifreenet-de,
I have fixed it from our end :
- FIXED interpretation Siril output data
As reported here https://www.astropixelprocessor.com/community/main-forum/problem-loading-oiii-fits-files-processed-with-siril-into-app/#post-29027 , APP could not stretch a 32bits float FITS file produced by Siril. Data analysis of the data inside the FITS file showed that the data did not conform correctly to normalized floats in the data range of 0-1. Once actually clipped to this range, the data shows correcly, something Siril forgot to do perhaps. We have added an exception in our FITS converter for Siril data to check for this data problem and apply the clipping.
Hi Mabula,
Wow, that was quite fast. Thanks a lot for your detailled analysis and report of the problem and for the remarkable fast fix, evening it is no APP issue. I am deeply impressed.
If you don't mind, I would like to forward your post as bug information to the Siril team to fix it also from there side?
Best regards, Ralf
Hi Mabula,
Wow, that was quite fast. Thanks a lot for your detailled analysis and report of the problem and for the remarkable fast fix, evening it is no APP issue. I am deeply impressed.
If you don't mind, I would like to forward your post as bug information to the Siril team to fix it also from there side?
Best regards, Ralf
Hi Ralf @rhe2sifreenet-de,
I am not sure if they will consider this a bug from their end, but as far as I am concerned, I think this certainly can be done better from their end. Earlier this year, we encountered a similar issue with data produced by Siril and I think that was reported to them as well but I am not completely sure.
Simply said, if they don't fix clipping to the data range, they either need to add metadata information about what the data range should be or perform the actual clipping to prevent data processing issues down the road...
Siril produced a max value of 2,8 in your O3 stack with star cores having many pixel values above 1.0. APP studies the data range and because it found a max value of 2.8 it considered the data range to be 0-2.8 instead of 0-1 which caused the issue with showing the data as you experienced. Clearly, the data should be in 0-1 range because if we do this, the data actually looks as expected and almost identical to having stacked it in APP from the O3 subs.
The reason the APP is flexible with the data range and not simply assumes it must be 0-1 is because a lot of scientific data does not adhere to that 0-1 range and their range can be anything, really so an application needs to adjust to that to be able to interpret the data correctly.
Mabula
