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.
Sorry for the long title but couldn't come up with a condensed one that describes what I'm attempting to do here. I'm sure this has come up before, but am not finding anything uniquely specific to my question. I've been imaging galaxies lately with my Celestron C8 and Antares .63 reducer. The star shapes have a lot to be desired due to the coma around the periphery due to the poor flattening ability of the reducer. I have a Starizona corrector on order, but in the meantime, I've been collecting several hours of data using my 8" SCT to get greater detail of the galaxy and then collecting several more hours using an AT102ED with flattener, with the intent of using the stars from the refractor to replace the ones taken with the SCT. Â
My first target was M81 and M82. I collected around 8 hours of M81 and 6 hours of M82 with the SCT and then shot around 6 hours of the entire area with the AT102ED. After integrating the AT102ED separately, the galaxies in the image are much more detailed than I expected using a 4" scope and now believe I'd prefer to integrate all sessions into one image. This is where my questions begin. Â
First question, which frame should I be using as the reference frame? If I use a frame from the widefield image, I risk downscaling the data from the longer focal length sessions. While you can compensate by setting a larger scale for the integration, I had read Mabula suggested using a frame from the longer focal length as a reference to avoid downscaling. How do you make this work, though, if there are multiple areas within the wider image that have been imaged with a longer focal length, as in this case?Â
Also, what would the correct weighting algorithm be for this situation? The images from the longer focal length sessions have much lower quality scores, due to the poor star shapes and bloated stars from the SCT so regular weighting based on quality results in less detail in the higher magnified areas. If I use equal weights, the ugly stars from the SCT inject themselves to a greater degree into the lovely stars from the refractor. Am I relegated to integrating the wider FOV image separately and extracting the stars to preserver them? Thanks for your help!
Well that is a very tricky one indeed, especially when the data is not very good in the smaller FOV. I have never tried it like this, so not super sure if it is possible to do it like that. Maybe only when the FOV are not super different, I do know APP is able to handle different telescope data etc (so switch off "same camera and optics" at the very least), but I wonder what the limit is there. Just give it a go by switching off same camera, loading both into separate sessions and try a registration, if that fails you can try some different parameters, but I doubt it's possible with the big difference in quality.
Well that is a very tricky one indeed, especially when the data is not very good in the smaller FOV. I have never tried it like this, so not super sure if it is possible to do it like that. Maybe only when the FOV are not super different, I do know APP is able to handle different telescope data etc (so switch off "same camera and optics" at the very least), but I wonder what the limit is there. Just give it a go by switching off same camera, loading both into separate sessions and try a registration, if that fails you can try some different parameters, but I doubt it's possible with the big difference in quality.
This is more than likely a question that Mabula will need to answer. I've seen it addressed here before but that was slightly different in that the poster was only wanting to implement smaller FOV data into one area of the widefield image and the solution was to use the smaller FOV frame as reference. I'm trying to implement multiple smaller, more detailed areas into a wider FOV. I'm trying to avoid several guinea pig runs of multiple hours and days of stacking and integration, but that may be my only option.
Also, I think you're misunderstanding the quality of the data. The data from the smaller FOV is very good which is why I'm wanting to use it. It provides much greater detail and resolution of the galaxy, especially in the dust lanes and spiral arms, in comparison to the data shot with the APO refractor. Having said that, even the best data from an SCT design telescope will show inferior star shapes and color in comparison to an APO refractor, due to the optical design (mirrors vs ED glass). Coma around the periphery is unavoidable with an SCT, especially when using an APS-c sensor which I am. But, the focal point of the data is in the center of the FOV and the stars are going to be removed after stacking anyway. Thus my question as to the best course of action in registering and weighting the integration of these data stacks from two different telescopes and focal lengths. Â
Much of the problem comes from the quality score calculations that APP performs. APP scores the data from the SCT (smaller FOV) much lower due to the decreased number of stars (due to smaller FOV) and greater FHWM so any integration based on quality scoring is going to heavily favor the data from the wider field of view, as is most of the other "weighting" options other than equal weighting. Is there a way to enter your own custom weights?Â
H Jason @jasonjeremiah,
What i would recommend is the following:
1) just like a mosaic, make integrations per field of view first for the different telescopes.
2) use the wide field image of the apo as reference
3) set scale factor in 6)integrate to such a factor that you preserve the pixel scale of the longer focal length data. That factor is simply :
image scale short focal length data / image scale long focal length data
4) If the wide field image contains all objects that you shot with the long focal length, you don't need to use mosaic registration, you can use normal registration mode.
5) in star analysis, you need to bump up the star count to 2000-3000 probably
5) in registration, increase scale stop to a higher level until registration works of all frames, if the data is diificult, it might be needed to use triangles instead of quadrilaterals.
6) In integrating, i would simply us the quality for weight, it will prefere the data with the best stars probably, otherwise, use star shape as metric for weights.
Let us know if this helps 😉
Mabula
