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.
What is the formula for Ha and Oiii dual band/OSC extraction?
I ask because I noticed with my ASI2600MC camera has the following relative sensitivity of Ha in the three color channels:
Red: 80%
Green: 15%
Blue: 5%
And for Oiii, it has this sensitivity:
Red: 3%
Green: 90%
Blue: 50%
So if a target has a very strong Ha signal that is much stronger than the Oiii, which is usually the case, it seems it would take some very careful math to extract the Oiii since the Ha bleeds into the green and blue channels with a fairly strong percentage in the green especially. If Ha is more than 5 times strong than Oiii, the green channel will be dominated by Ha, not Oiii… sadly.
I expect you would need to know fairly precisely what the sensitivity of the camera is to both Ha and Oiii in all three channels to have a chance of separating them cleanly.
Can you say a bit about how this is done and is there a way to inform APP about the sensitivity of the channels of my camera?
is there a way to improve it given I know what the sensitivity of my camera is?
Hi Steven, @readyjetty
There is no set formula because the sensitivity completely depends on the optical setup:
- the bayer filter characteristics will be different between sensor models and brands.
- the narrowband (or dual/triple/quad NB) filter will have different characteristics.
- the sensor's QE will be different per sensor model.
For H-alpha, we only take the signal present in the red channel. The contributions in green and blue would be almost completely due to the bayer filters not being perfect filters for only R, G, B, so a Red Bayer filter would still let some green and blue photons through like you are seeing. Those signals in green and blue for H-alpha are not worth using, since they also contain a lot of noise, if you add them to the red signal, you get worse results.
Now, for the extraction of the O3 signal, your question is relevant to the 2.0.0-beta6 release that was released yesterday. From the release notes:
- FIXED and IMPROVED Bayer/X-Trans Drizzle HaO3 extract O3 & HaO3 mono narrowband processing
As reported in this topic https://www.astropixelprocessor.com/community/main-forum/drizzle-and-dual-band-filters/ there was a bug in Bayer Drizzle processing, especially with O3 data. It turned out that Bayer Drizzle had 2 bugs. The second bug was that the O3 data reconstruction from the green and blue channel was not working correctly. This is now fixed by properly scaling the O3 signal in the green and blue channels for O3 extract and similarly for HaO3 mono reconstruction. This fix has a strong positive effect on the Signal To Noise Ration of the results 🙂 :
APP will measure the signal in both green and blue over the whole sensor and will now scale Blue to Green giving you the best O3 reconstruction possible. So no formula is uses, since we measure it per image. In that way it will work optimally for all optical setups whereas a formula would not ;-).
For O3, the amount of signal in Red is mostly garbage, so it is not used. The signals in Green and Blue are used and thus scaled starting with 2.0.0-beta6.
Mabula
Thank you for the update. It’s good to see an Improved/fixed beta released. I’ll restack a dataset with it to check the improvement.
With respect to your answers a couple of comments:
1) yes, I certainly understand why you would not to try to extract any Ha out of the blue and green channels at any 03 out of the red channel. My question was really around the extraction of 03 out of the blue and green channels in light of the strong Ha sensitivity in blue and green given filters commonly used on one shot color cameras.
2) in light of that it seems to me that in order to extract 03 you need to remove any Ha that is picked up in those blue and green channels. And since the red channel is so sensitive the Ha, Ha is typically very strong, and red has low sensitivity to Oiii, I believe you can treat the red channel as a pretty clean Ha signal and subtract some proportion of that off from the green and blue channels based on the camera specific sensitivity. if you were able to enter the camera sensitivity parameters into APP, informing you of your camera specific sensitivity to Ha for the blue and green channels (which is a combination of the filters sensitivity and the cameras overall quantum efficiency), the I expect the amount of Ha that is picked up in the blue and green channels can be estimated with reasonable accuracy.
Do you agree?
Hi Steven @readyjetty,
1) Okay, so you are concerned about the Ha signal interfering in the O3 signal I understand.
2) In theory, in can follow your thoughts, but I think in real life it will be very difficult if not impossible... I would simply argue to make life much less difficult in that case and I would consider buying a mono camera with separate Ha and O3 filters, the result will be sharper and better for sure when compared to data from OSC camera's with dual/triple/quad filters. OSC camera's and such multiple NB filters do have their charm of course and provide a fast and cheap entry into narrowband imaging.
So no, I would not fully agree, because I think the exercise that you propose will be very difficult and fraud with danger. If you simply enter multipliers/dividers based on those sensitivities, I still have no clue how I could say that some part of an ADU value of a pixel will be due to Ha signal and the other part to O3 signals because of the stochastic nature of light. The light sources themselves are noisy, photons are not coming in that reliably.
Mabula
Thank you for your thoughts.
Upon more reflection I think you can probably determine the amount of Ha in the G and B channels reasonably accurately and then subtract it with reasonable precision if your model contains the camera sensitivity.
I think the formula that gets very close is simply:
Ha = red_channel
Oiii_green = green_channel - Ha * camera_greenHaSensitivity / camera_redHaSensitivity
Oiii_blue = blue_channel - Ha * camera_blueHaSensitivity / camera_redHaSensitivity
