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.
Hi @dcaponeii,
Thank you very much for reporting this. This is not a common problem, but I know the problem and how it can be solved. I have fixed this for the 2.0.0-beta18 release which is upcoming.
The error can occur if you change something in the 0) Raw/Fits menu after the star analysis stage completed before you start integration. Could this be what happened in your case?
Can you duplicate the problem? Does it happen always on this dataset?
Mabula
I have four sets of collected data. This error happened on two of the four (I haven't tried running the other two sets because I was waiting to see if you had a chance to respond.) My usual work flow is to perform "star analysis" and then order the set from best to worse and delete the worst 10% or so. The I do registration and order those from best to worst and again delete the worst 10% or so. I then proceed with integration. The normalization process completed normally in both cases but the integration processed failed with the error in both cases. I think you're saying that if I do NOT cull and frames and let the default process proceed uninterrupted then I might not get the error? I'll try in any case while I see if you have any other suggestions. Thanks for responding so quickly.
Hi @dcaponeii,
I think you're saying that if I do NOT cull and frames and let the default process proceed uninterrupted then I might not get the error?
No, that is not really what I am saying, I am saying that if you change something in 0)Raw/FITS between processing step 3)-6) this error could occur, simply removing frames between these processes definitely should not harm any processing.
The error indicates that something is off with the image dimensions and the registration parameters of the data. Adjusting a setting in 0) Raw/Fits could have that effect and I just solved this problem for the next release.
Can you provide a detailed step by step process which I can duplicate to see if the problem would occur on a different dataset?
Mabula
Images were from my ASI485MC planetary camera. Saved as fits files. No calibration frames because I was actually just testing out a new computer I'm running the camera on and no planets had risen yet. Captured about 300 3s subs. Loaded the into APP as usual. Used default parameters throughout. First ran star analysis. Removed the bottom 10% of the stars after sorting by star shape. Ran Registration and then sorted on quality and again removed the bottom 10% of the stars. I then selected integration which began the normalization step (again in default settings) which completed as expected and auto-started the integration steps (again in default mode). The error is triggered almost immediately after integration begins, the bar is less than 10% progress to completion. I ran the same data set in 1.083 and it completed without any error codes but the colors were all heavily skewed to the green (I seem to recall that 1.083 did not like using uncalibrated images) but no error codes were generated. I hope that helps. I tried to attached one of the fits frames, perhaps the camera is saving the files strangely and that's causing the error (But the forum won't accept that file type). Here is the text log from FC if that helps.
Dear Donald,
I think i need to see your data to understand what is failing here, it is very weird. The text file that your shared does show a fundamental problem and a possible 2nd problem with the data that you are trying to process though which you need to solve in your capture software if you want to process deepsky images properly with and without calibration:
..
Time_format=HHmmss
LT=UT -5h
Frames captured=400
FPS (avg.)=0
File type=FITS
Binning=1x1
Bit depth=8bit
Data=RAW
Debayer(Preview)=yes
Debayer(Data)=no (RAW)
Debayer(Algorithm)=NearestNeighbor
Debayer(Pattern)=RG..
The data is only 8bits, that is simply a waste of your data (and camera), you will have no meaningfull information in especially the low lights of your data. Furthermore, with only 8bits, data calibration will never work properly on data like this.
Another thing that looks odd is the bayer pattern mentioned, a bayer pattern of RG does not exist, it must mean RGGB ? If the capture software only stored RG in the fits headers, that could explain our problem here maybe, but I think I need to see this in the file itself to confirm to you the issue.
I have sent you an email with upload instructions for your data 😉 Can you upload a small batch of light frames so I can test it myself?
I seem to recall that 1.083 did not like using uncalibrated images
That is simply not the case, probably also caused by loading 8 bits data perhaps? Then many things will simply not work properly.
Did APP not warn you about 8 bits data being insufficient for deepsky imaging? If you load calibration data as well, it should warn you.
Mabula
Hi Donald @dcaponeii,
I have found and solved this error. It was caused by your data being color data with the ROWORDER keyword in the FITS header actually. So next APP release will not produce this error and will process the data correctly.
The actual CFA pattern in your data is mixed up for ROWORDER being Bottom-up I think... the pattern in the data states it is RGGB, which with Bottom-Up becomes GBRG... It should be reversed. Did you set the pattern in the capture software yourself?
Mabula
