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,
I read the post that Ha-Oiii Extract Oiii was fixed/improved in Beta 6, so I downloaded it and loaded up a dual band OSC capture that I had stacked previously with the "Ha-Oiii color" mode. I tried Ha-Oiii extact Oiii and all frames resulted "Star Analysis Failed". I tried four options and two options out of four failed:
Algorithm:
Adaptive Airy Disk: Success
Ha-Oiii color: Success
Ha-Oiii extract Ha: Star Analysis Failed
Ha-Oiii extract Oiii: Star Analysis Failed
I had the same files loaded in both cases (A subset of my lights and bias frames to speed the test, about 20 lights and 30 bias frames). AFYI: These lights only have about 120 stars, so not a ton.
Also, I had not played much with the Ha-Oiii Extract Oiii or Ha options on this data set before, so it's possible the earlier one would have failed too, but given that Oiii is supposed to work now, I thought I would give it a try. But I'm just surprised that star analysis would succeed with “Ha-Oiii color” and fail with “Ha-Oiii extract Oiii”… seems star analysis should be the same in either case, I would have thought you would be looking for stars for registering and alignment purposes, not optimizing color extraction.
- Steven
Hi,
Can you try this : do star analysis with Ha-Oiii color, then registration.
After that, choose Ha-OIII extract Ha or OIII, and start at the normalization step.
David
That worked! I should have thought of that workaround, clearly it has an issue with analyzing stars in these other modes. Don’t know why the particular color mode would break star analysis.
I have got this error in beta6 when doing Extract Ha
That worked! I should have thought of that workaround, clearly it has an issue with analyzing stars in these other modes. Don’t know why the particular color mode would break star analysis.
We are looking at the star detection algoritm as someone else saw a big difference pre-beta, we're investigating.
I haven't given any specifics about this error because I have seen it several times and I can't replicate it at will. I'm hoping that you can figure it out by looking at the message. I have seen it about 6 times now and I just quit APP and restart and it seems to work the next time.
I was doing Ha-OIII extract Ha. The problem may be occurring when I do an ordinary integration then go back and do Ha-OIII extract Ha without restarting APP. I don't know what you mean by "what kind of data." It's UVIR and L-Extreme filter data.
If you can't spot the problem as it is then I'll pay attention next time so see if it repeatable.
@ddnum The error is a generic one unfortunately, might be a bug which pops up once in a while. If you have the exact data this happened on and are able to reproduce it a bit, we could use that data to hopefully find it.
I’ll see if a small manageable subset of my data triggers it.
Sorry for the delay.
OK, I think I found the general cause: I stored one data set as TIFF from NINA instead of FITS. As noted in another thread, TIFF headers are not as robustly used or defined. I'm wondering if this is it. I've captured several targets using FITS and have had not issues.
If you are still interested, here are examples of the TIFFs (two lights and one bias).
Yes there may be something going on with the TIFF's in that sense. You should be able to process different formats, maybe when you first do the tiff and then the fits, then combine those?
Yes there may be something going on with the TIFF's in that sense. You should be able to process different formats, maybe when you first do the tiff and then the fits, then combine those?
Well, I shoot all FITS now, which is a bit too bad as lossless compressed TIFFS are half the size. Nice on the drive space, I wish FITS supported lossless compression. For the stuff I have as TIFF, I worked around the issue per the suggestion on the person that responded. Thanks!
