2023-03-15: APP 2.0.0-beta14 has been released !
IMPROVED FRAME LIST, sorting on column header click and you can move the columns now which will be preserved between restarts.
We are very close now to releasing APP 2.0.0 stable with a complete printable manual...
Astro Pixel Processor Windows 64-bit
Astro Pixel Processor macOS Intel 64-bit
Astro Pixel Processor macOS Apple M Silicon 64-bit
Astro Pixel Processor Linux DEB 64-bit
Astro Pixel Processor Linux RPM 64-bit
[Solved] Odd result when integrating with 'per channel and all' option
I am getting an odd result in the Blue and combined Luminance channels when processing a set of subs using the 'per channel and all' option.
If I deselect all but the Blue subs and process these separately using the per channel option, the result is as expected.
Results using 'per channels and all' option:
Result of processing Blue subs separately:
I'm planning to capture some more Blue subs when the weather permits. I was interested in assessing my progress to date when this issue during integration arose. The Blue result to date is clearly rather noisy.
I thought at first that the odd result might be due to my choice of outlier rejection option but I have experimented with several of the other choices and always get an anomalous result.
The Red, Green and Blue subs are binned 2x2. The Blue integration uses the same MB, MD and BPM is Red and Green. I see no particular difference between the Blue MF and Red and Green MFs.
Hi Mike @mestutters,
I see clearly that something is not right indeed. Have you checked the individual blue frames for any artefacts? what happens if you process all data without doing any calibration?
Please send me the data if you want me to have a proper look at what is happening here.
Send it to firstname.lastname@example.org using dropbox or wetransfer.
Maybe the data triggers a bug in calibration or somewhere else or the data has a strange anomaly..
I am still struggling with this one. I have managed to capture some additional Blue subs and on first processing everything seemed to work OK although I was not able to combine the resulting LRGB integrations to achieve a satisfactory result owing to strong colour casts.
I have been trying since to reprocess the integrations after omitting some of the lower quality subs but unfortunately have been getting similar anomalous results to the ones reported above. I will see if I can get a repeat of the anomalous results using fewer subs and if I do I will send the data to you.
One problem I think exists is in the process of assigning Master Flats to Lights. I have loaded separate 1x1 and 2x2 MFs for each each filter. APP asks me to select a MF to assign a light, see screen shot, but then asks only if it should assign this MF to all lights with the same ISO/gain and dimensions. If I agree to this it assigns the MF to the relevant lights regardless of the filter. If I do not agree, I have to work through my lights individually assigning the correct MF to each one. To me it seems it would be more appropriate to assign the MF selected until a change of filter and and only then to repeat the assignment question.
NB: I do have the Multi-Channel/Filter Processing option selected at Load Files.
I have now managed successfully to integrate my stack of M81 subs on three or four occasions.
I am now fairly certain that the problem I reported at the start of this thread was due to a mistake/inexperience on my part when assigning preexisting MFs to lights.
My stack of lights includes both binned and unbinned RGB frames and I have loaded both binned and unbinned BPMs, MDs and RGB MFs, and I am using the Multi-Channel/Filter processing option.
I think my error started when presented with the dialogue box shown at the above screenshot.
To my mind, APP at this point should be asking if the selected MF should be assigned to 'all light frames shot with the same filter, ISO/gain value and dimensions' or perhaps 'all <filter name> frames with the same ISO/gain value and dimensions'. With the dialogue as it stands, if the option is selected, MFs will be incorrectly assigned to some of the lights.
To avoid this it is currently necessary to assign MFs to each light individually, which with a stack of more than a handful of lights becomes very tedious.
I hope my assessment is correct.
I am hoping with a bit more work I can bring out Holmberg IX irregular galaxy and the starburst features of M82.
Integrations successfully processed with 'Per Channel and All option'
RGB combined image
Dear Mike @mestutters,
Thank you very much for your extensive feedback here.
I will have a good look at the code of MasterFlat assignment in the mult-channel and session modes. I agree, if you choose to apply it on all, then it should be done only on the same filter.
I might just add, in case it is not clear from my description above, that I don't think this problem occurs during initial loading and processing of a set of lights but when for some reason I've decided I would like to redo an integration with a changed parameter value.
My recollection is that the file list showed all the correct calibration frame assignments from the earlier integration but for some reason APP thinks it necessary to reestablish the MF assignments. I'm not clear if the original file assignments have been lost by APP despite the file list showing the correct information, or if APP thinks something has been or may have been changed such that it considers it necessary for the MF assignments to reverified.
Hope this helps
I have discovered that by loading my binned (2x2) and unbinned (1x1) frames together with the relevant calibration masters into separate sessions, that APP then processes the image stacks without further ado.
From my perspective I think there is currently a small confusion within APP with regard to the assignment of MasterFlats to lights if a user loads binned and unbinned subs within a single session but that this issue can be readily addressed by simply loading the relevant frames into separate sessions Do you see any flaws with this approach that I have overlooked?
Please get back if you would like a sample of my subs for testing any planned resolution of this issue.
And in the meantime, thanks for your on-going efforts to maintain and enhance APP. I am very impressed by your work-rate.
I look forward to seeing some of the further improvements that you have in mind - my vote would be for deconvolution.
To add to my comments above I think there is maybe an issue in APP with MBB when integrating binned and unbinned stacks.
I integrated some new subs (lum unbinned and RGB binned 2x2) and the result looked OK. A little later I noticed that I had an issue with outlier rejection and repeated the integration but also switched on MBB and found the problem I originally reported was still present.
I repeated the integration first with MBB switched on and second with MBB switched off. Here are screen shots of the results. For some reason the glitch has affected the Blue and Green integrations but not the Lum or Red.
With MBB @5:
Hi Mike @mestutters,
Apologies for the late reply.
Thank you for sharing all the data, I have downloaded everything and I will start testing tomorrow to solve this issue with MBB and binned data.
I will keep you updated and thank you very much for your research on this problem 😉
Hi Mike @mestutters,
Excellent news, I have found and solved this issue 😉 Thank you very much for reporting this error and your own research. This is an important bug fix !
FIXED, Multi-Channel & Multi-Session integration with non-equal weights and Multi-Band Blending enabled, an important bug was found by Mike Stutters @mestutters and he reported it in the following topic: https://www.astropixelprocessor.com/community/main-forum/odd-result-when-integrating-with-per-channel-and-all-option/ The bug showed a problem that seemed to be caused by the Multi-Band Blending (MBB) algorithm. If MBB was disabled, all worked fine. It turned out that the bug manifested itself due to an improper calculation of integration weights in the Multi-Channel and/or Multi-Session modes. So this means, that integration weights per frame were miscalculated previously as well in the Multi-Channel and Multi-Session modes. This is an important bug fix ! All weights will now be correct when non-equal weights are chosen in integration combined with enabling Multi-Band Blending.
I have now marked this topix as solved 😉
I am currently using the trial license and I am interested in using astro pixel processor for the calibration to integration stages rather than pixinsight. I typically have a high light count and the astro pixel processor seems to achieve very similar results to pixinsight in my limited trials but with very little disk space used, ie no need for saving lots of files at the various intermediate stages.
I hope this is the right topic for my question, which is how does 'integrate per channel and all' work with regard to the quality score which was produced before the 'all' option is selected in the integrate section. My understanding is that the quality score is per channel, so how are the lights weighted when all channels are combined ? Similar question for normalize which I assume are also done per channel ?
Would be interested if anyone has used the all integration option for a super luminance and it if has any benefits over a separate integration of the master l, r, g and b (h alpha) channels ?