New Feature : Moon Mosaic Planner

[Borodog]

I have not been having much luck with the lunar mosaic planner. I'll try to describe my experiences.

First of all, I am trying to image full disks at critical sampling or near it in an 11" EdgeHD SCT, 2800 mm f/10. My image train runs a bit long so it's closer to f/10.6. So in my ASI678MC (2um, 8.3 Mpixel) that is an image scale of approximately 0.138"/pixel. So the full disk assuming 30' = 180" is approximately 13,000 pixels across. The chip is 3840x2160 pixels. With my ASI183MC (2.4um, 20.2 Mpixel, 5496x3672) the disk is about 11,000 pixels across.

With the "Automatic" method and the 678, SharpCap can't ever seem to find a solution and never makes it past trying to find the alignment points. I just don't think it can see enough of the arc of the limb. With the 183 it was eventually able to find a solution but it took a painfully long time of apparently randomly slewing back and forth to do so.

With the 678, I fell back on the "Guided" method, now that I understand better how to use it. Unfortunately in neither case, Automatic or Guided, 183 or 678, was SharpCap able to successfully complete a mosaic. I believe the problem in both cases was drift during capture, and just as importantly, while writing buffered frames. For the 678 there are 1918 frames worth of frame buffer available, for the 183 there are 788 frames available. I set SharpCap to capture this number of frames for each panel for the respective cameras so that the frame rates would stay at the maximum, 47 fps for the 678 and 19 fps for the 183. It takes as much time or longer to write the frames to the 6 Gb/s mSATA SSD as it does to capture the frames. The entire time during the capture and writing the frames, the Moon is drifting slowly relative to the frame. By the time the mosaic completes, each panel has moved successively farther due to drift.

The drift occurs for 3 reasons. One, because I have an unavoidably huge amount of declination backlash in the CGEM, I tend to leave my polar alignment deliberately offset a minute or two of arc left or right to enforce a drift in a single direction in dec so that the dec guiding is not constantly switching directions and having to take up the backlash. I could tighten this and probably get my polar alignment to within 10". A second problem is that the RA tracking is subject to periodic error, however this should be just that, periodic and not cumulative, so I am thinking it cannot contribute to net drift, only "wiggling" of panels in RA. But the last problem is the real kicker, which is that lunar tracking rate only tracks at the average movement rate of the Moon, not the actual instantaneous rate. That inevitably causes drift that I don't know how to compensate for. With the 678 prior to the meridian flip, the drift was enough to cause gaps. With the 183 after the meridian flip, the drift was in the right direction to increase the overlap, but the mosaic tool missed the bottom of the Moon (I was able to add the bottom layer manually, so hopefully I will get a full mosaic out of that one).

I have been assuming that the lunar mosaic tool is incompatible with Feature Tracking. But is this true? Is it possible to have Feature Tracking running and SharpCap cleanly suspend it to slew and restart it to prevent drift while imaging panels? This would prevent drift during capture and writing to disk.

[admin]

Hi Mike,

thanks for the test report - you can see why auto align is still flagged as experimental! The problem you are seeing with the excessive movements is because after the first measurement, even though the code knows the diameter of the moon and where the center is in terms of camera pixels (probably out of view), it doesn't know which way the moon will move for +/- RA/Dec movements, so it has to guess. If the movement it tries moves the edge completely out of view then it goes back and tries a different movement. I do find that some over-exposure at this stage can help avoid issues with the disc edge not being detected, but that's only one part of the problem. I do have a simulator that I have made, so I will try setting that for a large moon diameter of 10000+ pixels and see how it goes.

Feature tracking and mosaic are unaware of each other, so even if you do manage to run both at once, the tracking will go crazy when the mosaic code slews the mount. I'm not sure what else might help with tracking isssues at the moment though. In theory an ASCOM driver could calculate the instantaneous tracking rate for the moon and use that when the 'Lunar' rate is requested - I guess that either the mount or the driver is taking the simple approach though. There aren't any third party ASCOM drivers for Celestron that might be better than the official one are there (like EQMOD and GSServer for Skywatcher)?

Actually, in theory, application software like SharpCap can set a custom rate on *some* ASCOM drivers - there is a way to set an offset to the normal sidereal tracking rate, although not all drivers support it and since it is rarely used it could be buggy in some drivers. You can check this for your ASCOM driver by running

Code: Select all

print (SharpCap.Mounts.SelectedMount.AscomMount.CanSetRightAscensionRate)

in the SharpCap scripting console.

As to the time taken to write images to SSD, a couple of things to check

* Firstly ensure good amounts of free space on the SSD and run a Windows 'Optimise' on the drive before starting - this can have a big impact on SSD write performance in some cases, although depending on how much data you write, it might start writing quickly after this procedure and then slow down in later panels

* Check that the move to the next panel is happening after the 'writing buffered frames' is finished. I think it should be waiting for the buffering to be done before moving, but not 100% sure. Each panel movement is based on a fresh re-calculation of the moon position for the current time, so should wipe out any tracking rate induced drift from the previous panel (this won't help sadly with periodic error or polar alignment error).

cheers,

Robin

[Borodog]

Thanks, Robin. SharpCap was indeed waiting for the buffered frames to finish writing before initiating the next slew. Last night I worked on my collimation, and while I did get my polar alignment down to under 10", I did not have time at the end of the night to try a mosaic, so that will have to wait for another night for testing.

I have some suggestions for improvements that I hope would not be too difficult to implement. I believe you have all the infrastructure in place already.

It would be extremely nice if the mosaic tool could leverage Feature Tracking. Up until trying the mosaic tool I would use Feature Tracking every time I imaged the Moon, so I always have a valid calibration. It would be great once you have Feature Tracking open, calibrated, and guiding, if the mosaic tool were aware of that, so it could do things like already know the transformation from screen coordinates to RA & DEC, suspend guiding for a slew, and restart guiding for imaging. There would be no mucking about. If you start the mosaic tool with the limb in view, it could fit the limb curve, know the diameter, know where the center is in screen coordinates (even though it is off-screen), which it can then convert to RA and DEC because it knows where the center is in RA/DEC from the ephemeris calculation presumably. It plans the mosaic, it suspends guiding for slews, it turns it back on for capture and writing. No fussing with alignment, no drift, no gaps, no excessive overlaps. Feature Tracking solves all problems, basically.

[admin]

Hi Mike,

it might work... providing the feature tracking info is accurate enough. There are two key bits of info that you can get from feature tracking - the orientation of the RA/Dec axes relative to the sensor and the image scale. Now, the thing is that feature tracking still works if those pieces of info have some errors in them - if the scaling is wrong then the movements will be a bit bigger or smaller than expected, but the iterative nature of feature tracking deals with that. The same if the orientation measurement is a bit out.

The mosaic needs those to be correct to a much better degree of precision, otherwise the panels will come out in the wrong places, leading to gaps, missing parts, etc. The scaling can be checked from the diameter of the detected disc, but the orientation needs at least a 2 point measurement to check (the third point only verifies if the image is mirrored or not). Given some of the issues I've tracked down with feature tracking and how poor the calibration data can be to still get that working, I would be reluctant to trust it except as a first 'rough indication' of the scale/orientation followed by a more detailed measurement.

Since reading your earlier post above, I found an issue with disc detection working poorly if the only dark area in the image was on the far right hand side (now fixed) and I have worked out a way to do the automatic alignment with smaller movements without having problems with the relative error in the measurement compared to movement size causing inaccuracy - or at least a big improvement on that error issue. I still have to code up the second idea though. I will see how the new calibration calculation works out - if it is as good as I hope then it should be able to calibrate with movements of maybe 1/6 to 1/8th of the image size in two directions, which would be very unlikely to end up pushing the disc edge off screen.

cheers,

Robin

[Borodog]

Thanks Robin. I really hope it can be made to work well. It sounds like those potential problems only lie with using the Feature Tracking calibration data for the alignment. Even if you can't do that, it would still be a profound improvement if the mosaic tool could suspend and restart guiding. As it is, without that it doesn't really work well for my use case and I'm trying to figure out workarounds. I can think of some but they are cumbersome and manual and I may as well stick to doing it the hard way. :O(

If it were me (and it isn't, so take this with a grain of salt), I would build the mosaic tool around Feature Tracking. While imaging a panel, I would keep guiding on to keep the panel stable. When the panel is done, I would just use Feature tracking to guide to the next panel over instead of making a giant slew, for example moving the features identified in the rightmost 20% (or whatever) of the panel over to be in the leftmost 20% and then image the next panel. Or vice versa; depending on the phase and orientation the panels might move to the left. Backlash is automatically taken up by Feature Tracking. When you reach the end of a layer, guide down to the next layer and then scan from panel to panel in the opposite direction. There should always be a continuous path that can be followed from panel to panel, start to finish, for any mosaic. You still have to do the initial alignment, and you still have to plan the panels, but Feature Tracking is guiding the whole time, either stabilizing panels or moving between them. You can even have the user confirm the alignment of the first panel and correct it if necessary before hitting "go."

Mike

[admin]

Hi Mike,

I guess I see feature tracking more from the point of view of the fairly substantial fraction of people who struggle to get it working - it's great when it does work, but there are plenty of mounts that struggle to do the calibration for one reason or another, so anything based purely on it would be out of reach for many people.

Integrating the activation/deactivation of tracking depending on moving/capturing should be possible though - I presume it's fine for the feature tracknig to move the mount during a capture as the stacking application will just dump the frames that were smeared by the movement.

So many things now rely on knowing the orientation of the camera relative to the sky and the image scale. I have several ways this can be calculated (feature tracking calibration, framing assistant, plate solving, mosaic alignment) - at some point I need to bring all of these together so that data from one can be used for the others.

cheers,

Robin

[Borodog]

Hi Mike,

I guess I see feature tracking more from the point of view of the fairly substantial fraction of people who struggle to get it working - it's great when it does work, but there are plenty of mounts that struggle to do the calibration for one reason or another, so anything based purely on it would be out of reach for many people.

Integrating the activation/deactivation of tracking depending on moving/capturing should be possible though - I presume it's fine for the feature tracknig to move the mount during a capture as the stacking application will just dump the frames that were smeared by the movement.

So many things now rely on knowing the orientation of the camera relative to the sky and the image scale. I have several ways this can be calculated (feature tracking calibration, framing assistant, plate solving, mosaic alignment) - at some point I need to bring all of these together so that data from one can be used for the others.

cheers,

Robin

I think the part is bold will be sufficient to get the tool working well for ultra high resolution mosaics. And yes, feature tracking running while capturing has never been a problem for stacking.

Regarding many people struggling with Feature Tracking still, I wonder if that isn't telling us something about the need to improve that capability. I recall you working very hard a year or two ago to get Feature Tracking tolerant enough to calibrate with my CGEM carrying my 1100 EdgeHD. While it is adequate, it is still a pretty hurky-jerky compared to PHD2. The scope is way too heavy for the focal length for DSO imaging, but PHD2 can still guide it to within an arc-second or two accuracy, which for planetary or lunar may as well be dead still. I seem to recall asking you why Feature Tracking could not be made more accurate, and I seem to recall you saying something about issuing too many small, noisy corrections (although it's been a couple of years).

I wonder if Feature Tracking could somehow be made more robust in relatively simple ways. Two particular problems we had getting my scope to calibrate were the unavoidably large backlash in DEC, which I think you fixed, and the very different slew rates in the east and west directions. East has always been snappy, and west has always been slow and tends to drift a long time after you stop commanding a movement before it settles. So SharpCap would fail calibration because the east and west rates were very different, and you had to loosen the tolerance criterion a lot to get SharpCap to calibrate in RA. I suspect there are a lot of people still failing that check. So, how about not performing that check at all, and just using the 4 different rates you've measured? One for N, S, E, W. I suspect a lot more mounts would pass muster, and it shouldn't be that hard to code.

I don't know exactly how Feature Tracking works under the hood, so forgive me if some of this is already done or is not doable for some reason I don't understand. I believe I recall you telling me once that Feature Tracking measures the drift every 0.25s (correct me if I'm wrong). PHD2 typically uses something like 1-5s exposures, sometimes longer, to avoid "chasing the seeing". For DSO, PHD2 can't let a star drift more than an arc-second or so, which limits the guide exposure. For lunar or planetary you don't have that restriction because the camera exposures are very short. So if you are measuring the drift every 0.25s or so, you are definitely "chasing the seeing" and the individual points are noisy. However, you could fit a line to, say, 5-10s worth of drift samples and use that to issue a small guide command every 5-10s. Frankly, I am not a fan of the "dead zone"; I think it contributes to the jerkiness of the guiding. PHD2 doesn't need or use a dead zone; it leads to uncorrected drift punctuated by larger corrections, and the large corrections may be difficult to get right, hence the jerkiness. It seems like a better policy would be to just make small corrections frequently, but not too frequently. Getting rid of the dead zone and just continually correcting would also simplify the interface. Right now there are a LOT of parameters in Feature Tracking, which might contribute to why it is so difficult for some people to get it working well. You had to walk me through a lot of seemingly random parameter space to get FT working for my rig; for example my correction scaling is still set to 1%, and I have no idea why that is needed (or even how that can possibly work). Similarly, just issuing a small guide command every 5s or so would eliminate the need for the "Max Move Duration" parameter. I think. I'm not even really sure what it does or why it's needed; it's another mysterious setting.

[admin]

Hi,

I guess it all comes down to 'why not be more like PHD'? It's one of those things where each time you end up making a decision for a reason, it has further consequences...

PHD can probably detect star positions to 0.1 pixel accuracy (SharpCap can get close to that when detecting stars), so can calibrate for relatively small movements. The sort of surface feature trackign that was originally the only option doesn't have that sort of accuracy, so to get a decent calibration you need bigger offsets to be measured. If you need to measure bigger offsets as part of calibration, that means using faster movement rates (or calibration takes too long), which means using the commands to move the telescope axes at various rates, rather than pulse guiding. Moving the telescope axes that way opens you to dealing with the sort of ill-defined behaviour of whether the movement is superimposed on tracking or not... It continues from there

Similarly, using MoveAxis rather than PulseGuide to correct introduces the requirement for a dead zone - when you ask the mount to rotate the axis at a particular rate, you also have to ask it to stop, so there is a 'minimum' step based on how quickly it can respond to two instructions in quick succession. Without a dead zone you end up with hunting to/fro for small seeing fluctuations, etc. I suspect this is why your tracking still works with 1% adjustments - you are getting the minimum size adjustment each time, regardless of how small the request is.

Out of interest, what happens if you calibrate initially as usual and then switch to 'Guiding Rate' for tracking? That should then use pulse guiding for adjustments, which can be precisely timed (you will probably have to increase the adjustment % to 50 or so). In that mode your dead zone should only need to be large enough to deal with seeing offsets (and even if it chases the seeing a bit, it shouldn't really matter).

cheers,

Robin

[Borodog]

Robin,

My apologies if I sound like I'm criticizing SharpCap by comparing it to PHD2. PHD2 is no picnic; the internet is filled with endless problems people are having there too. I subscribe to the PHD2 email list and I get many emails a day from people looking for help. I need to write such an email myself, because I tried PHD2 for the first time last night with my newly motorized and GOTOed Vixen GP and it was a nightmare. It has a million parameters, including, as it turns out, a "dead zone." It's called Min Move and it's right there on the front cover for both RA and DEC. :Op

I'm just trying to think of a ways to get to smoother, simpler, more robust guiding on planets and the Moon. But of course, I have no idea what I am talking about, which is a problem. It's very easy to sit in a chair and come up with ideas when you are too incompetent to implement them.

I will try switching to Guiding Rate and upping the scaling (see, I would have never known about the connection between the two) the next time I have the CGEM set up. It may be a while.

[admin]

Hi Mike,

no worries - all the feedback is helpful, unfortunately I just don't have time to act on all of it. My feeling is that feature tracking is a feature that isn't used much, but I'm not sure if that is because it is hard to get working properly or not.

cheers,

Robin