Ultra-wide-field mosaics: what am I doing wrong? [Deep Sky] Processing techniques · Brian Boyle · ... · 5 · 324 · 5

As part of the Astrobin Community Survey in progress, I am attempting to put together a mosaic of the entire Southern Sky using a Sigma Art 40mm + ZWO 2400MC rig.  Elsewhere on this forum my AB friends (in particular @Jakub Korbel@GalacticRAVE ) have been really helpful on issues regarding lens/camera backfoucus issues, but I am also experiencing issues with the mosaicing. I wonder if anyone has had simpler experiences - and may have suggestions for what I am doing wrong.

Currently I have between 1.5hours and 3hours of 120-sec sub-exposures on each of 21 fields with fields centers at declination 0 or further south.  Fields with centers 7<RA<0 , dec>-75 are also missing, since I only bean this wide-field survey this past lunation.

All fields are processing using WBPP and then GraXpert and BXT applied before passing to MosaicByCoordinates and then GradientMergeMosaic [shrink radius 5 merge radius 50].  On my trust old iMac 2017 this takes a less time, but eventually I get the following lightly stretched result [binned up 4 x 4 from the original] 



This is not bad for a dramatic "public" image, but seams between the fields are beginning to become visible .  If I want to go any deeper using an arcsinh/GHS stretch this is what I get



All the faint stuff is there, but so is the pattern left by the individual fields in the mosaic.

So the question is simply  What am I doing wrong?

Limited by the speed of my 4-core processor, albeit (with 48GB ram) I have tried using different post-WBPP routines including including/excluding] ABE, SPCC and and BXT (full or correct only).  I have also tried APP [failed with cryptic errors with more than 4 fields] and PTGui.  PTGui is brilliant stacking software but needs stretched images and using the STF-like PixelMath algorithm] unfortunately stretches the non-Milky Way fields disproportionately to the Milky Way fields.  

Although it fails on fields that not distributed in a near-rectangular fashion, PhotometricMergeMosaic used to work quite well removing edges.  However, it appears to have disappeared on the latest release of PI.  This may have something to do with the upcoming MARRS project.  But since the PleiadesAstro team have already asked me for some of the ABC survey data to support the MARRS project in the south, it would look like a bit of a chicken and egg problem if I need to wait for the MARRS project, in order correct data needed for it. [It may be that the MARRS project have found another solution, in which case this data is not so important]

As you can see I have pretty much run out of ideas.  Perhaps I am not doing the correct order of post-WBPP processing for input to the mosaicing routines.  Or not doing the right post-WBPP processing at all.  Perhaps there are other mosaicing packages out there.   [Tried Photoshop - but it was the worst of the lot].  APP used to be my goto package, but it now fails - and I understand that there are some communication challenges with APP at the moment.

Any advice/experience gratefully received.

With many thanks in advance

Brian

Wei-Hao Wang:
Hi Brian,

Nice project. 

I am never a fan of GradientMergeMosaic.  It never works well enough for me.  The PhotometricMosaic script is still provided by John Murphy, just not as part of the PI distribution because of competition with the PI team on similar functions.  It works very well for me if I use a very wide-field single image as a reference for the mosaic panels.

I think you correctly point out the chicken-and-egg issues.  Both the MARS project and your ABC survey can potentially provide background references for mosaics.  But who can provides a background reference for MARS or ABC?  When it comes to such extremely wide field, essentially from horizon to horizon, can a good background reference even exist?  I don't have a good answer.  Even if all the amateur astrophotographers collectively fund and launch a small camera to the orbit to avoid any atmospheric effects, it can still suffer from zodiacal light, which is seasonal.

If you ask me, I would say APP's approach to remove gradient and match the mosaic panels should still be the most promising one to come up with a quick  solution.  It should be able to produce a seamless mosaic, but the background structure is almost certainly to be wrong or inaccurate at least.

Thanks Wei-Hao.  I think you put your finger on the issue i.e. that this is an issue which is within the community's grasp to solve [if a solution doesn't already exist'. @James Tickner who is doing the field matching for the ABC survey, is coming up against similar issues.

I just wish I could get APP to work with more than 4 images.   

I note that GMM appears to overestimate background for fields with the greatest stellar density.  This suggests to me that the use of even a robust median estimator, still gives a biased (high) estimate of the background in areas with the Milky Way.  It is almost as if you need to make multiple medians across the frames and sigma clip that stack.  

My last experience at writing code to reduce astronomical images was back in 1990, so I am a little out of date.

Many thanks Chris.  That is very useful.  I followed your prescription with PTGui [both without and with GraXpert] and still got quite significant variations.  It may be that the data is simply not up to the task [your images are wonderful] but I will explore for a few more days.  

Thank you again.

Brian