MAY 4 2026: APP 2.0.0-beta44 has been released !
New improved internal memory controls should now work on all computers
May 1 2026: APP 2.0.0-beta43 has been released !
Improved internal memory controls (much more stable and faster on big datasets), fixed CPU image viewer, fixed Narrowband extraction demosaic algortihms.
Apr 29 2026 APP 2.0.0-beta42 has been released !
New improved Normalization engine, Fixed random crashes in integration, fixed RGB Combine & Calibrate Star Colors, fixed Narrowband extraction algorithms, new development platform with performance gains, bug fixes in the tools, etc...
Apr 14 2026: Google Pay, Apple Pay & WeChat Pay added as payment options
Update on the 2.0.0 release & the full manual
We are getting close to the 2.0.0 stable release and the full manual. The manual will soon become available on the website and also in PDF format. Both versions will be identical and once released, will start to follow the APP release cycle and thus will stay up-to-date to the latest APP version.
Once 2.0.0 is released, the price for APP will increase. Owner's license holders will not need to pay an upgrade fee to use 2.0.0, neither do Renter's license holders.
Hello!
I have a question about the reference for normalization and registration.
This is my current workflow:
* I have a set of RGB images and Ha-Narrowband images as pre-stretched TIFF images exported from Adobe Lightroom (Captured with a DSLR camera)
* RGB has three channels, Ha is black/white with only one channel
* I am using TIFF files instead of directly using the RGB as I process ultra wide field images with parts of a foreground in it which I manually mask out (pure black and no anti-aliased edges)
* Multi-Channel/Filter processing is enabled, Muti-Session processing disabled as there is only one capturing session
* First I load all RGB images, assign the filter "RGB", then I load all Ha-Images and assign the Hydrogen-alpha filter to them
* Calibrate is skipped
* Star analyzation is set to auto/1000
* Normalization is enabled and at default settings
* Integration is set to default settings
* Now I start the star analyzation and after this I set the reference frame to one of the RGB images
Now if I start the integration, it creates a stacked image for each RGB and Ha as I expect, but unfortunately it looks like that also the Ha images are normalized against the RGB reference frame which creates weird color shifts and most problematic it blows out all highlights (they are really blown out and not recoverable).
My "workaround" to this is to first do only the registration over all images, export all frames registered, and then stack each set of RGB and Ha from the registered frames by then disabling registration, which this approach I can set a reference frame for each RGB and Ha separately and everything is fine and I have perfectly overlapping and smooth normalized images for RGB and Ha each.
My question: Would it be possible to set the reference for normalization for each fiter independently of the reference used for registration? This would save me a lot of extra manual work, time and temporary disk space required.
Thank you and best regards,
Dominik
Hi Dominik @h-dominik,
Thank you very much for your question.
That is a very good suggestion actually and I am familiar with the problem. Thank you very much for the details description.
I propose that I open an issue on our ToDo list for this. Can you share the data in question with me, can you upload it here?
https://upload.astropixelprocessor.com/
username: uploadData
password: uploadTestData
Please make a folder with your name and issue like: Dominik-Mosaic-RGB-Ha-normalization-issue
then I can use your data while testing and solving this issue. Thanks !
Mabula
Done. Thank you for looking at this!
I've set "RGB1.tif" as reference, my APP version used is 2.0.0-beta28 (macOS Intel 64-bit).
@mabula-admin , Hi Mabula, yes, I already told you in the past but I was not happy with your answer. 🙂
this is my big issue with APP on SHORGB stacks. Ha for example got sometimes a normaization against Green and got star saturation for example at 32000 adu instead of 65000. Sometimes, it works fine, but for some images it is an issue.
Why you don't do normalization inside each stacks (ie : normalize Ha frames with Ha reference, even if it is aligned on green reference) ?
I don't understand the concept of normalize a Ha or OIII signal with a green signal (for example, as the green is often taken in reference).
It causes me big issues on SHORGB mosaics for example. you put 3 panels it works, you put 4 panels and result is a disaster.
Maybe you should add the option to normalize by stack or full (but honestly, full is not usable and not necessary)
Done. Thank you for looking at this!
I've set "RGB1.tif" as reference, my APP version used is 2.0.0-beta28 (macOS Intel 64-bit).
Hi Dominik, @h-dominik and Philippe @philippe-bernhard
Great Dominik, we have received the upload in good order. I have officialy opened an issue on our ToDo list to have this improved.
I fully get it now Philippe, i have seen the problem myself recently on some test data and I agree that we need to improve this. I think the suggestion of Dominik can be a proper solution:
In multi-channel mode, to have a single reference for registration as usual. But we need to have references per channel for normalization, it will complicate things for the user for sure and we need to implement options/buttons so the user can select references for normalization.
The reason for APP to work like it is doing now, is the idea that you want all channel stacks to be normalized already and thus ready for a RGB Composite. With R,G,B data that works very well and easy clearly. The trouble starts if you start to mix broadband with narrowband and / or semi-broadband (like LPS filters).
Philippe, in your experience, to make the SHORGB work well, which of the channel would you normally use/select to normalize those stacks? Maybe the stack with the highest dispersion? Then the clipping of stars at 32000 can simply not happen, all stars will clip at white at 65535 in 16bit or 1.0 in 32bits floats. Maybe that can be a good and easy solution already, to simply use the best frame of the channel with highest dispersion in Multi-Channel mode. I can test with Dominik's data and implement this quickly if that works well. If you have a nice SHORGB dataset for me to work on this, please upload it as well with the same instructions as a give Dominik 😉 (use folder name Philippe-SHORGB-normalization so I recognize it immediately).
Thanks!
Mabula
Philippe, in your experience, to make the SHORGB work well, which of the channel would you normally use/select to normalize those stacks? Maybe the stack with the highest dispersion? Then the clipping of stars at 32000 can simply not happen, all stars will clip at white at 65535 in 16bit or 1.0 in 32bits floats. Maybe that can be a good and easy solution already, to simply use the best frame of the channel with highest dispersion in Multi-Channel mode. I can test with Dominik's data and implement this quickly if that works well. If you have a nice SHORGB dataset for me to work on this, please upload it as well with the same instructions as a give Dominik 😉 (use folder name Philippe-SHORGB-normalization so I recognize it immediately).
Thanks!
Mabula
Hi Mabula
I didn't explain well (I will send you the stack). We have done a mosaic of 2 panels in SHORGB with 100 Mpixels camera. Lot of images. All RGBSO are fine and normalization is from 0 to 1.0 (or 65535 in 16 bits format). But the Ha has been normalized differently. Like if the data have been divised by 2 (or so). It is not the 1st time it appears. I didn't do the preprrocessing myself but my colleague who also use a lot APP (we have both MBP M3/M4). I will see if individual datas still are in our dropbox but the mosaic stack, yes.
In fact, I can understand the RGB datas must be normalized but SHO is another story. We don't need the full normalization (in fact, I don't want the SHO normalization). Anyway, I don't know how you normalize (if it is on stars or signal to noise) but yes, you can try to use the best frame of channel with highest dispersion.
I will make, if possible, some new tests myself this week-end
