9 July 2020 - APP 1.082 has been released which contains one important bug fix. 1.082 has full Fujifilm RAF support, so that includes SuperCCD & X-Trans camera's 🙂 !
9 July 2020 - New and updated video tutorial using APP 1.081: Complete LRGB Tutorial of NGC292, The Small Magellanic Cloud by Christian Sasse (iTelescope.net) and Mabula Haverkamp
2019 September: Astro Pixel Processor and iTelescope.net celebrate a new Partnership!
Unable to process DSLR Milky Way panorama
APP is having trouble managing my 9-panel Milky Way panorama. The Analyse Stars step is a bottleneck: APP apparently can't detect usable patterns in the multitude of tiny stars. It'll work if I set the Automatic Star #s Target slider to the max, but the resulting files become so large that to assemble the mosaic APP asks for 3X the amount of RAM that my computer can provide. It'll scale down the result, but the resulting image is unrecognizable. Is there a special workflow for assembling such a mosaic? I'm using 9 panels from a full-frame Canon DSLR, .raw files, 18mm FL lens.
See https://www.astropixelprocessor.com/community/tutorials-workflows/green-panels-wont-respond-to-the-mosaic-workflow for a workflow that will probably do the trick.
What works OK for me in these cases is to stack the individual panels (if you have multiple exposures for them), then combine the stacks into a mosaic. If memory or disk space is an issue, set the "scale" to something below 1 in the 6) Integrate tab.
Keep an eye on the Registration RMS values after the 4) Register step. These values should ideally be well below 1 pixel. If they're not, something probably went wrong in the registration step, and (very) strange images may result.
@ralphThanks, Ralph. I didn't know about the Scale setting and will give it a try. Can you explain the RMS values? Thanks.
The Register step takes the stars it found in the 3) Analyse Stars step, groups them in patterns, and tries to match the patterns between the panels. Too few stars and there are too few patterns and the match will fail. Depending on the freedom given to the alignment algorithm (dynamic distortion correction, same camera and optics, registration mode) the match between the patterns found may be better or worse. The Root Mean Square difference of the star positions is an indicator of how well the algorithm performed. APP can do very good alignments, with good enough signal to noise in the images I've had values below 0.1 pixel. For noisier images about 0.3 to 0.6 pixel is quite good.
However, I've encountered RMS values in some of my milky way mosaics that seem to take forever to converge, and result in huge stacked images, similar to what you describe. The RMS value seemed acceptable at a value of about 1 or 2 pixels, just a bit on the high side. But the resulting stack had crazy distortion where the smart algorithm had the bad luck of noisy star patterns as input and enough freedom to try and make things match. And the algorithm did find matches, however nothing that was realistic.
it takes a bit of fiddling around with the various settings and workflow to get a decent convergence to the correct mosaic. APP is very good at what it does, but there is no sure fire way that I know of that works for anything.
A couple of things that helped me get good mosaic results:
- try to get high(er) signal to noise ratio in the images to be aligned. Remember that for aligning there is no absolute need to keep the colour information. So if needed I try to stack all exposures for a single panel, irrespective of filter band, into a panel that has very well defined stars. These panels are then used for the alignment.
- When taking the exposures, increase the overlap between the panels. I have not experimented too much and don't know for sure where the sweep spot is. Too little overlap might result in too few star patterns found between overlapping panels and increases the risk for occasional mis-identification of star patterns
- Split the registration step from the integration step for tricky mosaics. That's described in the linked workflow above.