query on mosiac registration in new APP version

Mm, not sure what the issue is exactly, how did you set up APP to process a mosaic?

Normally you'd want to do the following:

- Set nr. of stars higher to about 2000 or so
- Set normalization to advanced
- Set registration to mosaic
- Same camera&Optics off
- Dynamic Distortion Correction on

With the rest of the settings at their standard setting, this usually already works.

@vincent-mod Thanks Vincent. No, I'm very experienced with the mosaic options after lots of fun mixing data from many scopes and nights and pixel scales 😊 , down to distortion models and star pattern geometry options etc. (APP still the standard bearer for mosaics).

The query was the length of time this took for 144 subs (registration alone was 3.5 hrs) , as I reinstalled the previous version and it was much faster. My query was a curiosity one-was there an update to mosaic registration? Its not a problem at all, just curious. It worked perfectly with 2 iterations of 2nd degree LNC in the end. Maybe an even higher star number or a change from quads to pents or triangle might change overall pattern matching time? 

One other thing I noticed is that integration defaulted to equal weighting when it was set on automatic, only happened after mosaic registration in the newest version. I later chose a rejection algorithm and distortion protection that made sense and it came out just fine, but the automatic equal weighting never happened before.

Both tests used star number of 5000, I might try a higher value just to see what happens.

All the best, Col

Right, sorry the light in my head didn't pop on as I do remember now you're very experienced already. 🙂 It is interesting as I don't think it should be slower. I'll ask Mabula as well.

Posted by: @col

I am running a process in APP, integrating 144 subs. 64 of the subs have about 20% overlap with the other 80 (2 separate sessions), rotated perpendicular to the other 80, so I am using mosiac registration, flip x-y descriptors etc. My last mosiac was with an older version but this one is taking quite long. I attach a screen shot. Can someone tell me what the 10,296 2-view registration is compared to older mosiacs where it was not as involved (i.e. much quicker). This registration task has been running several hours now, and every APP integration i have done in the past (even 500 sub ones) was always much quicker. I have dynamic distortion correction ticked, although it made no slow-down on overlapping subs in the previous APP version or previous projects. Curious if the method was updated, or if a particular setting has caused this lengthy

calculation.

Thanks @Mabula-admin, @Vincent-moderator, and @Wouter-moderator.

Hi Colm,

The mosaic calculation in the new version is in fact quite a bit faster than the previous version. The issue here is that you run the mosaic algorithm on 144 frames! With the current (and previous APP )version, APP will take a very long time.

If all frames overlap with the reference, the mosaic registration mode is not needed and not wanted. So simply run regular registration mode.

flip x-y descriptors are only needed if you combine data of different optics, where on of the optics has the data flipped compared to the other.

If you persist on doing a mosaic, then it is only a 2-frame mosaic ;-). First make a stack of the 64 frames with regular normal registration. Then with the other 80. Then make a 2 frame mosaic (but since they overlap, it can again be done with normal registration) 😉 It will be done quickly and without issues this way.

Mabula

@mabula-admin Thanks Mabula. That all makes sense, and in fact I did something very similar on the first go before I changed method to using all subs - it should have been obvious to me why it was taking so long 😶. Even after doing many mosaics my brain was fogged. I forgot to keep mosaic to the end and proceeded with the entire process this way.

Case closed/solved!

I normally do mosaic stitching with just a few frames, i.e. several integrated masters to merge together. In this particular case, it was very difficult to get the blending correct using the separate integrations (they were different orientations, completely different fields of view/rotation with the camera 180 degrees rotated on a new coma corrector compared to the other subs) even with many iterations of LNC of 2nd or 4th degree complexity. When I ran the 144 subs the blending was perfect using mosaic mode for the whole process. i dont know why, but i will try normal integration of the whole stack even if there is some camera rotation and partial overlap to see the comparison (curiosity). 

In any case, using a full mosaic mode for the two rotated fields of view worked perfectly in the end so its robust in both methods!

On side note: any reason why the automatic registration defaulted to equal (100) weighting in the integration? I saw this in the console. I like the automatic option for my high sub-number integrations since the diffraction protection, and kappa values always seem optimized and give great results.

Here is the result, my first image of something I like to look at visually - Kemble's cascade.

Thanks as always, cheers, Col

@vincent-mod Yes, but a failure to get good blending and some brain fog wiped out my experience and I ran the whole stack using mosaic mode instead of the registering the separate integrations that way 😕 ! It still worked, which is good to know and the PC got so hot my room was a little warmer!