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.
I'd be interested to hear what general workflow folks are using in APP. I am sure that I had read somewhere that one should avoid doing star alignment (or registration) more often than necessary. Because of this my processing in PI followed the following (simplified) workflow:
- Calibrate all lights
- Register all lights together (only registration required)
- Stack individual Channels
- Combine already registered stacks as required
Â
I can, of course, replicate this workflow in APP. But this does not seem to be the preferred workflow. If I understand correctly, APP lends itself to:
- Load all calibration subs (or masters if available)
- Load lights from one channel
- Calibrate, Register and Stack that channel (registration #1)
- Register the seperate stacks and then combine (registration #2)
Â
The APP method seems simpler (and quicker), but do I need to be worried about that second registration step? Â
Hi Steve,
Very good question 😉
Both methods you describe can be followed in APP as well. And yes, the second method that you describe is the easiest. But indeed, by applying another data resampling due to another registration process, it can be (for some datasets) sub optimal and lead to artefacts at the star borders.
So I would suggest to follow the first route if you encounter star artefacts with method 2. Most likely this will be the case with very sharp and/or undersampled data.
To solve this problem and to make it the easiest for the user, I intend to upgrade APP with full multi-channel (and even multi-session) processing. I will work on this soon.
So that would mean that when you load frames, you will be able to indicate to which channels (and/or sessions) the lights and calibration frames belong and then APP will calibrate the channels and register all data at once, and give you direct control to integrate the separate channels, by selecting the channel you want to integrate. To have this fully working will take some development time, but it's a big request from a lot of photographers, so I am bumbing this request up on my priorities list 😉
If you have any thoughts on how to implement this, let me know as well .
Mabula
Thanks for responding Mabula. Full multi-channel processing would be great, but I appreciate that this is a major task. I suppose the simplest thing (that we could probably do with the program as is) is to select one frame as our registration frame and keep this across the multiple registrations. My bottom window becomes awfully cluttered so I usually press the 'Clear' button between channels. I thought that one way might be to take note of which sub APP uses as the registration frame when processing the (for example) Blue channel. I could then use that same sub to register the other channels. However, if I load in that blue channel sub when all the rest are (say) greens, won't the blue frame get integrated along with the greens?
Could APP be set to 'remember' which was the best blue frame and use this for subsequent registrations, without it being incorporated into the stack?  Â
Actually, thinking about this a bit more, I think that it would almost always be useful to have a folder into which Calibrated Lights are saved (irrespective fo whether you follow method 1 or 2. I say this because there are a number of projects that you might want to add to - you might not get it finished in season 1, or you might want to add more data to a target that you were never all that happy with, or you might want to add data from a different telescope (maybe you have a dual rig). Since these combinations might require different flats, darks and biases, the best way of combining would be to have a bank of fully calibrated subs that you could just add to, then register as and when the mood takes.Â
What might be useful, therefore, is to use the APP method (method 2) but be given the option (a tick box) that allows you to save your calibrated subs into their own folder (possibly with the option of naming them as you see fit - I would use, for example, M17_June2107_Blue_900s - then the frame count).
Hi!
It would be very nice if I could simply drag an drop .fits files to the workspace and APP identifies them by their meta data (light,dark,flat,lum,red,green...). This would make things easy and fast I think:)
Uwe
Thanks for responding Mabula. Full multi-channel processing would be great, but I appreciate that this is a major task. I suppose the simplest thing (that we could probably do with the program as is) is to select one frame as our registration frame and keep this across the multiple registrations. My bottom window becomes awfully cluttered so I usually press the 'Clear' button between channels. I thought that one way might be to take note of which sub APP uses as the registration frame when processing the (for example) Blue channel. I could then use that same sub to register the other channels. However, if I load in that blue channel sub when all the rest are (say) greens, won't the blue frame get integrated along with the greens?
Could APP be set to 'remember' which was the best blue frame and use this for subsequent registrations, without it being incorporated into the stack?  Â
Hi Steve,
Yes, right now, you would need to load all frames, select the reference (or let it do automatically) and register all frames to that reference. Then in integration, only select the frames of each channel to create those integrations per channel. If you selected a green sub as a reference, it's no problem if you deselect it for integration 😉 of for instance the red channel. So the green reference frame won't get mixed up in the red data.
A true multi-channel implementation should cover all of this and make it work without having to think about all details oof course. So I'll definitely try to implement it in the most user friendly and technically correct way.
Could APP be set to 'remember' which was the best blue frame and use this for subsequent registrations, without it being incorporated into the stack? Â
Yes it could, but with the multi-channel implementation that I have in mind this should be a redundant issue.
Mabula
Actually, thinking about this a bit more, I think that it would almost always be useful to have a folder into which Calibrated Lights are saved (irrespective fo whether you follow method 1 or 2. I say this because there are a number of projects that you might want to add to - you might not get it finished in season 1, or you might want to add more data to a target that you were never all that happy with, or you might want to add data from a different telescope (maybe you have a dual rig). Since these combinations might require different flats, darks and biases, the best way of combining would be to have a bank of fully calibrated subs that you could just add to, then register as and when the mood takes.Â
What might be useful, therefore, is to use the APP method (method 2) but be given the option (a tick box) that allows you to save your calibrated subs into their own folder (possibly with the option of naming them as you see fit - I would use, for example, M17_June2107_Blue_900s - then the frame count).
Yes, exactly, and this would mean a multi-session feature then. It's probably a natural extension of multi-channel to also make it multi-session. I will start work on this soon since it should be a very attractive feature for a lot of photographers. (I have received a lot of requests for this 😉 ).
Mabula
Hi!
It would be very nice if I could simply drag an drop .fits files to the workspace and APP identifies them by their meta data (light,dark,flat,lum,red,green...). This would make things easy and fast I think:)
Uwe
Hi Uwe,
Thank you, I have put drag and drop frames to my priorites list as well:
https://www.astropixelprocessor.com/community/development-priorities/current-priorities/
Kind reagard,
Mabula
Thank you very much!! And dont forget the Metadata!
Uwe
Hi Uwe,
Yes, I almost forgot about that 😉
I think you refer to metadata that is supplied by the capture application right?
It's a bit difficult though, I would need to know how various capture applications store it in the fits files, that is, which fits header tag would the capture application use.Â
Mabula
