May 27 2026 APP 2.0.0-beta45 has been released !
Fully Multi-Threaded LNC, many improvements for the registration engine, platform upgrade, and further tuning of internal memory consumption and memory release back to OS.
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.
I recently reset my APP version to factory defaults while troubleshooting another (now solved) problem but now I can't use the RGB combine tool 🙄 Pretty sure that I am just overlooking some obvious setting but I seem to be getting very excessive auto stretches which make it impossible to see the effects of the RGB combine tool. I've never seen this before so hopefully someone can point out the problem..
As an example, here are some fairly typical narrowband stacks which seem OK to me (these have been registered and normalised prior to using the RGB combine tool)
and here are the results of a couple of Hubble palette combinations, without any intervention on my part, just the automatically generated result:
Â
Â
I'm not exactly sure what is causing the excessive stretching behaviour (BTW - turning off 'auto' doesn't help). Any thoughts?
Â
thanks, Jon
No idea but you might try "none" for normalize in the RGB combine settings. I read that it would not be necessary after APP's preprocessing. And also maybe not necessary to have neutralize-bg in the stretch control - just that it doesn't seem to do anything much after preprocessing as well.
Thanks @astrogee Using 'none' just seems to produce a dark screen with barely any stretch but I think that you are right in so much as the problem is something to do with normalisation. The blown-out images occur mainly with the recommended 'Add-scale' and 'Multiple-scale' options. If I just use 'Add' or 'Multiple' I can get one or two of the SHO options to look reasonable (hadn't tried this before as they are not recommended). This does seem to be an 'interesting' new problem that I have inflicted on myself though... 🙄
Not sure I can help much and it is difficult to see clearly in the screen shot but to me the Red channel in the histogram looks to have a very unusual distribution in that in that the data all looks to be piled up on the RHS. I would take a careful look at your Red channel subs for anything abnormal. I am thinking that to get that data pushed mostly to the Right then there are possibly a small number of abnormally very dark (clipped) pixels in the Red integration. Not sure what might cause this though apart from a camera fault or darks calibration problem.
Regards
Mike
Speaking of channels, I just noticed that your OIII image is very strong. Usually this is faint compared to Ha. So it looks like your channels are not normalized properly. When you then do RGB combine with one of the formulas, it will probably not look right because I think the channels need to be at the correct relative levels.
thanks everyone. I agree that this looks like a normalisation/stretch issue but it does seem to be happening within the RGB combine tool. If I take the very same FITS stacks and save out a TIF from each one then use the TIFs in the RGB combine tool (rather than the FITS files) then everything looks fine with no overexposure. Very strange...but I will go back and looks at the subs..
I wonder if you might be able to comment on possible things which could be going wrong here as I am running out of ideas?
In short, after years of no problems, Â I no longer seem to be able to use the RGB combine tool. The issue is that none of the normalisation methods produces a reasonable scaling of the fits stack files, whether they are three RGB, or three HSO stacks etc. There is always a crazily different scaling between the channels which results in terrible combined images.
I had thought that maybe there was something wrong will the filter assignments but I have now confirmed the same issue present with data from two different scopes and filter systems, both RGB and HSO.
Strangely though, if I export a tiff. file from each R,G,B,H,S,O stack...then use the tif files in the RGB combine tool, rather than the fits files, then everything works just fine. Â It is something about the fits scaling...but I have no idea what's going wrong.
Â
I have also tried a freshly downloaded version of APP on a different computer...but with the same result.
As always any advice most welcome 🙂Â
Â
thanks, Jon
Hi @jdwood and others,
I have read the entire topic and I am very sorry to have kept you waiting for so long for my reaction.
Can you please share data that shows this particular behaviour? Somehow both the normalization and the auto stretch do not work well it seems on these data sets. I am working in the normalization engine as well at this moment for the next release, so it is very good timing as well if I can test your data as well to make sure all will be much better going forward. Thanks.
Can you upload data here:
https://upload.astropixelprocessor.com/
username: uploadData
password: uploadTestData
Please make a folder with your name and issue and upload the data into those folders. I will have a look as soon as I see the data on our server.
I have also opened an issue on ToDo list.
Mabula
I have uploaded the three master stacks (FITS) from the example above - H, S, O. These are simply light pollution corrected at this stage - I have not uploaded any derivative files as I thought that you would want to process them further yourself.
As noted above these files look fine to me in a FITS browser and everything seems to go OK when I register and normalise them. Â After that things get a little strange...
If I save the normalised files as FITS and go on to the RGB combine tool then the resulting image (e.g., SHO) is badly overexposed. Â If, however, I export TIFF files from the normalisation panel then do the same RGB combine, it all works fine...
Currently using beta 39 on an M1 Mac Studio.
thanks for looking at this.
Jon
Hi Jon @jdwood,
Thank you very much for the upload, we have received the data in good order. I will work on it in the coming days 😉 and will get back to you.
Mabula
Hi Jon @jdwood,
I have found the problem, just like the problem here https://www.astropixelprocessor.com/community/main-forum/strange-calibrate-star-color-behavior/#post-34375 it had to do with inherited fits tags in the header of the input images, they contain wrong values for locations and dispersion which the RGB Combine was using without actually analysing the frames. I am fixing all these issues now and will make sure it works correctly in 2.0.0-beta42.
Mabula
Hi Jon @jdwood,
This normalization issue is now also fully fixed 🙂 I am very sorry to realize that this issue was in APP for a long time already... It was actually a regression from several beta's ago where we started inheritng the old FITS headers from input files. We did not properly clean the fits tags if needed for several tools like RGB Combine and Calibrate Star Colors to work correctly.
I registered and normalized your H-alpha, SII and O3 stacks. Save the normalized frames. Then put the normalized frames into the RGB Combine TOOL, stretchting works as expected and the data is very nice 😉
SHO Hubble 1:
SHO Hubble 4 :
I will make sure to release beta42 with all the fixes in the coming week 😉Â
Mabula
once again many thanks @mabula-admin for looking into this. That makes perfect sense - everything used to work fine for me but then started to show strange results a few betas ago. I thought that I somehow had corrupted the settings but could not get everything to work even by going back to defaults. This is great news! 🙂Â
You are most welcome Jon, and again sorry to have kept you waiting for the fixes.
Mabula


