Assessing Horizontal Alignment Post pc_align

[jlaura]

I am working with some CTX DTMs and am wondering what the best approach might be to assess the horizontal alignment of the pc_aligned DTM to some proxy of the reference. The proxy could be the MOLA gridded product, MDIM2.1, USGS controlled THEMIS, etc.

Put another way, once an ASP generated DTM has been pc_aligned to a MOLA point cloud, I am periodically seeing horizontal offsets on the order of 1-3km in the aligned DTM. Based on some testing, I believe this is due to the number or MOLA tracks and the minimization of error that pc_align is optimizing to. No issues or complaints there - as far as I am concerned pc_align is running as expected!

Currently, I am using geodiff and the descriptive statistics that are output to determine whether or not the DTM is misaligned. I am seeing that large StdDev, Min difference, and Max difference are generally, but not always an indicator of poor horizontal alignment.

If assessing quality just by horizontal alignment, the failure rate is ~5%, so not terrible at all.

Can anyone suggest other approaches for assessing the horizontal alignment between MOLA and an ASP generated DTM?

[oleg-alexandrov]

It will be hard to evaluate the horizontal alignment between a DEM and a dataset as sparse as MOLA. Normally, if the terrain has any relief, bad horizontal alignment will correlate with bad overall differences. If the terrain is flat, nothing will help.

I noticed myself that the ICP algorithm in pc_align is fragile. For each source point (second cloud, which in your case would be MOLA), it tries to match to first cloud, which is the ASP DEM. If the --max-displacement value is too high, this can end up in bad matches. If it is too low, it won't match to the right points. I usually set that one to about 4x the vertical difference, hoping that it may work well enough. Note that the ICP in pc_align does reject outliers, with a 75% ratio, though such logic may not be robust enough.

What you can do, after adjusting --max-displacement, and if still getting insufficiently good results, is to attempt a second pc_align pass with the original clouds, but using the previous alignment transform as initial guess, and this time using lower max-displacement, since that will be used only after the initial alignment is done.

At some point I need to spend more time robustifying pc_align. Ideally internally it should do several attempts and then retain the best result.

[jlaura]

Oleg, That is what I expected. I'll have to see if our two pass pc_align approach is causing the issue on some of these. That's a good thing for me to be able to quantify.

I have another 200+ of these that used the CSM. I noticed that more passed using the CSM than using ISIS, so I'm going to try and understand why. Also going to check and see if the horizontal displacements are the same. I assume they will be, but will report next week on the status there.

As always, many thanks for the rapid response!

[jlaura]

A little more information no the process I've been using with pc_align. Mostly in case anyone else stumbles onto this question.

For the initial run of pc_align, I've been using the mean of the initial geo_diff as the --max-displacement and applying an --initial-ned-translation as "0 0 mean" and using the --highest-accuracy flag. For a second run, I then pass the same --max-displacement and use the FGR alignment method and the initial transformation from the first run. So, two runs of pc_align, but with the max-displacement of the a priori computed mean.

I'll do some additional testing on the DTMs that have poor horizontal alignment to see if the --max-displacement I'm using is too small. Sounds like you are using 4x the absolute difference (maximum?).

[oleg-alexandrov]

I have no hard and fast rule about the max displacement. There's likely situations when what I am using may be insufficient.

When one aligns two DEMs, we have the --initial-transform-from-hillshading mode, which is more clever, it finds interest point matches, so in principle it can tie up two DEMs at opposite ends of the planet and a large scale change, but with MOLA the options one has are more limited.

One could also make use of bundle adjustment to get DEMs for which roughly same alignment will work, and mosaic them first and align later.

Anyhow, these are just some thoughts. For any large-scale processing job some process tuning will be needed.

[dshean]

Are you using the default point-to-plane ICP alignment routine? I’ve had better luck with the point-to-point alignment for co-registering DEMs with sparse ICESat altimetry over flat areas (ice sheet interior).

Are you considering the MOLA point density and spatial distribution for each CTX DEM in your assessment? Are the failures all near the equator? Honestly, 5% seems pretty good :)

You could potentially analyze terrain characteristics in the CTX DEM to predict whether pc_align with sparse MOLA points should work. As Oleg said, if the terrain is flat (or technically, planar), not much hope. But if you have some real terrain roughness at length scales greater than the average MOLA shot spacing, or really, enough curvature/deviation from a planar fit to the CTX DEM or MOLA shots, you should be able to get a decent result with pc_align - definitely better than 1-3 km horizontal.

Of course the CTX “jitter” artifacts and MOLA geolocation issues won’t make life easier, but magnitude should be less than 1-3 km.

[dpmayerUSGS]

@jlaura I'm pretty sure that the apparently higher elevations at the northern end of the DTM are due to a curl distortion. Those are not unusual in longer strips like this. I don't know what causes them (spacecraft motion at the start/end of one of the data takes?). The distortion might be enough that it's throwing off pc_align. If you look at the histogram of your post-align residuals, you might see that it's multimodal.

The difference between DTMs using the different camera models is interesting. I defer to @oleg-alexandrov on that, but whatever is causing the difference, it appears that the northern end of the DTM is being cut off in the CSM-based model because the intersection errors in that area are exceeding the threshold for inclusion in the DTM.

If you crop off the northern few percent of the initial DTM are you able to get pc_align to find a better solution?

[dshean]

Thanks for this additional info - really helps.

Yeah, the offset near the northern end of the DEM could be due to attitude error from the start/end of the stabilized MRO slew while CTX is continuing to acquire data. Curious to hear Oleg's thoughts on the different sensor models and why they handle identical inputs differently.

What are these image IDs? I wonder if the pointing kernels have increased error for this image/orbit and if that's something you could check for causality with your 5% failures. Interesting to see the large offsets near the north end of the image, and small (?) offsets near the south end of the image. Not what I would expect, and indicative of pointing error.

I expect that the small knobs and crater rims are being thrown out by the default pc_align 25% outlier filter, and most of the fit is to the smoother areas. Could adjust the threshold to preserve more of these differences over rough terrain, which will be helpful for the horizontal alignment. I see some long-wavelength offsets throughout the strip, which could be degrading the quality of the alignment.

[oleg-alexandrov]

CSM and ISIS camera models should normally agree to a small fraction of the pixel. The cam_test tool can help with validating that: https://stereopipeline.readthedocs.io/en/latest/tools/cam_test.html. If an issue is found, that should be raised with CSM developers.

The jitter solver for CSM I've been working on may help there, if the issue is with linescan poses going a little out of whack. (That solver is implemented, gives plausible results for LRO NAC, but needs more testing and documentation.)

One could try to run point2dem with the --errorimage option and examine that one, to see if, as @dpmayerUSGS says, there is a problem with that.

One could also crop the DEM to something smaller, avoiding the problematic area, and see if that aligns better.

[jlaura]

Thanks all for the discussion. This continues to be a terrific learning space! Here are some more results of tests.

Image IDs

• J03_045820_1915_XN_11N210W
• K05_055472_1916_XN_11N210W

camtest

This was run with ISIS as cam1 and CSM as csm2. Nothing here is standing out as being particularly egregious. @oleg-alexandrov Does anything looks amiss to you?

Using session: isis
Loading camera model: J03_045820_1915_XN_11N210W.lev1eo.cub J03_045820_1915_XN_11N210W.lev1eo.cub
Datum: Geodetic Datum --> Name: D_Mars  Spheroid: Mars  Semi-major axis: 3396190  Semi-minor axis: 3376200  Meridian: Reference Meridian at 0  Proj4 Str: +a=3.39619e+06 +b=3.3762e+06
Using session: csm
Loading camera model: J03_045820_1915_XN_11N210W.lev1eo.cub 
J03_045820_1915_XN_11N210W.lev1eo.json
Using plugin: UsgsAstroPluginCSM with model name USGS_ASTRO_LINE_SCANNER_SENSOR_MODEL
Image dimensions: 5000 52224
Number of samples used: 1050

cam1 to cam2 camera direction diff norm
Min:    2.77811e-11
Median: 2.73271e-08
Max:    4.89395e-08

cam1 to cam2 camera center diff (meters)
Min:    1.40719e-06
Median: 0.000101131
Max:    0.186689

cam1 to cam2 pixel diff
Min:    0.000130885
Median: 0.00137955
Max:    0.00255002

cam2 to cam1 pixel diff
Min:    5.54844e-06
Median: 0.000111444
Max:    0.00357204

Intersection Error

Thanks @dpmayerUSGS for the suggestion. We cook these with every pair, so the reminder to check this as well is appreciated! Again, nothing here looks particularly egregious. I am seeing jitter in the pair. What are others seeing?

Pointing Error

The base that I am using for visualization is relatively controlled. So, it could be that one of the images has really poor a priori pointing. To test this, I simply map projected the uncontrolled image. I would expect to see any strange twists or rotations in that image. Unfortunately, not seeing anything leap out here. (Colorized blue just so that it stands out from the CTX background. This image barely adjusted during the control process.) Data peaking out on the edges are MOLA points; good alignment there.

In terms of a casual, is this an orbit issue, I am not comfortable saying anything certain. Sure, I am see more P06 orbit images in the bad list, but when the sample size is ~300 in a single quadrangle I don't think it is indicative of an issue. Those P orbits also have some noise data, but nothing terribly out of line with D-N data.

Additional Tests

• I am running some tests now adjusting the max-displacement to see if perhaps that is causing the issue.
• I will run some tests as suggested by @dshean to adjust the pc_align outlier threshold. Since this pair is thrown off during the first, point-to-plane run, it may be that altering the outlier threshold there and then maintaining the defaults for FGR is advisable. I'll know more tomorrow.

CSM / ASP interaction question

Trent and @dpmayerUSGS have recently been discussing standardization to the MOLA sphere as the datum. @oleg-alexandrov, when using the CSM, if I use spiceinit with shape=ellipsoid and then manually edit the semi-major / semi-minor radii I can force the CSM to use the MOLA sphere as well. If I do that, do I need to be worried about any other interactions inside of ASP? I tell pc_align that the MOLA point data are using the MOLA datum and can write the DTM with the proper datum, etc. It seems that parallel_stereo has no user level concern for the datum. Bundle adjustment uses the datum from the sensor / ISD, so that seems to take care of any potential issue as well.

[oleg-alexandrov]

Your csm_cam_test stats are good. For the intersection error, one should examine its statistics, and min and max values. It looks very non-uniform to me, which is not a good thing, but one has to look at magnitude of those errors to say for sure. The CTX camera ground resolution is about 6 m as I recall, and then an intersection error a lot worse than that could be an issue.

Likely you editing the datum manually should be fine, since CSM has camera positions and orientations and should adjust to whatever ground you set.

If you have another stereo pair for that area, it may be interesting to create a DEM from that, and see if it aligns better and what the absolute difference between this and that DEM could be. Or, as before, if a smaller clip from this DEM aligns better, which may suggest there's some warping somewhere.

[dpmayerUSGS]

I know this isn't quite apples-to-apples, but I banged out a quick CTX DTM in ASP from that stereopair using the ISIS camera model, running bundle_adjust on the 2 images, and using the block matcher in parallel_stereo. There is definitely a long wavelength distortion in the CTX DTM.

Here is a transect over the CTX DTM (blue line on chart) and HRSC DTM h2940_0000_dt4 (red line on chart). (Edited to add: horizontal scale is degrees because I was in a hurry; vertical scale is meters.) I haven't made any attempt to to align the CTX DTM to anything, and the HRSC DTM is using a different vertical datum than the CTX DTM, so there's a spurious 190 meter vertical offset on top of the "real" errors. Nonetheless, the long baseline slope is not even remotely similar between the 2 DTMs, especially over the northern end. This is typical of distortions I've seen before in very long CTX stereopairs. This is a pretty flat and smooth area on Mars at CTX scale (no ~2 km vertical parabolas), so even if there's a large horizontal offset, the slopes should be similar.

Not shown, but the crater at the northern end of the CTX stereopair looked fairly well aligned horizontally to the HRSC reference. Given the distortion in the CTX DTM , pc_align probably came up with a spurious transform that pushed the CTX DTM several kilometers away. That would be consistent with other cases I've seen where these kinds of distortions are present.

I'd be curious to hear if anyone has ideas on how to fix the long baseline distortion (can that be done in bundle adjustment?). I've always just thrown out pairs like this when I've encountered them.

[oleg-alexandrov]

That is very interesting.

I'd be curious to hear if anyone has ideas on how to fix the long baseline distortion (can that be done in bundle adjustment?). I've always just thrown out pairs like this when I've encountered them.

The solution will be (sorry to repeat myself) a jitter solver. The one I implemented adjusts each individual camera position and orientation in the CSM camera file. It is like bundle adjustment, but with a sequence of poses rather than a single pose. I had a testcase where the error went down noticeably.

The tool I have also has a ground constraint, and, like bundle_adjust, can use overlapping images. The hope is that with all this, given that each jittery image pattern is likely uncorrelated to the one in other images, that it should converge to a unique well-behaved solution which agrees with the underlying ground constraint (which is a DEM).

Hoping in this fiscal year I'll have time to test and release that tool for general use.

[jlaura]

@dpmayerUSGS That figure is terrific and I realize that it is something I should be generating as well. Here is an example comparing MOLA gridded with the ASP generated DTM for the 'bad' DTM.

Bad 1

Good 1

Here is an example from a DTM that I identified as having good horizontal alignment. This visualization also shows what I think is good vertical alignment (but please jump in and correct me!).

Bad 2

Here is an example that is close to aligned, but not close enough to be generally usable outside itself. I am posting this because the geodiff metrics do not look terrible:

Max difference:       341.771
Min difference:       -361.495
Mean difference:      0.180975
StdDev of difference: 25.2286
Median difference:    -1.62315

Likewise, the magnitude of the intersection error (summarized via gdalinfo) looks okay:

    STATISTICS_MAXIMUM=8.7392578125
    STATISTICS_MEAN=2.1427603940257
    STATISTICS_MINIMUM=0.00390625
    STATISTICS_STDDEV=1.3758174233971

The transect also looks okay in the flat area, but deviates significantly (and highlights the horizontal offset) when hitting a crater rim.

This last example also drifts in the same NW direction. With a sample size so low, that NW pull is nothing more than an anecdotal observation.

I tested computing cos similarity on the transects and that metric is ambiguous. I'll continue to test methods to assess the quality of these DTMs at scale. I'll also be testing some different parametrizations to understand how better to constrain the transformation distances as the a priori pointing on is quite good.

[dpmayerUSGS]

In the "Bad 1" case, I think comparing elevation transects directly is useful only because the magnitude of the shape distortion is so large.

In most cases, I find looking at a histogram of the post-align differences between a reference DTM and a source DTM to be more useful than comparing elevation transects directly. If the histogram looks ~Gaussian and centered on 0, it's probably okay. If it's strongly multimodal (that is, several modes with similar amplitude) or uniform, that indicates an alignment issue. I've never tried to automate this, but I know there are all sorts of ways to classify histograms into several categories. It may be possible to run a classifier on a histogram of the post-align residuals and if there are strong secondary, tertiary, etc. peaks, the DTM gets flagged as having an issue.

As pointed out earlier, if the terrain is ~planar detecting horizontal offsets is difficult. In such cases, trying to detect horizontal offsets implicitly by examining vertical residuals is nearly impossible.

Here is an example that is close to aligned, but not close enough to be generally usable outside itself.
[...]
The transect also looks okay in the flat area, but deviates significantly (and highlights the horizontal offset) when hitting a crater rim.

Looking at a histogram (or even a transect) of the post-align residuals from the "Bad 2" case might be more informative than the descriptive stats and elevation transects alone. Also, how much did pc_align try to move the DTM? What did it say the 84%ile errors were pre- and post-alignment? Did they improve much?

Based on the transect, I wouldn't be shocked if the CTX DTM has blunders inside the crater (especially on shadowed areas of the interior crater wall). Similarly, I wouldn't be shocked if MOLA undersampled the crater such that there are interpolation artifacts in the gridded product. If so, this could be a situation where tuning the inlier ratio and the max-displacement value in pc_align may help filter out blunders so that they don't skew the solution.

[jlaura]

@dshean Thanks for the suggestion to use point-to-point and thanks @oleg-alexandrov for prompting to look at max-displacement more. Even with a DTM that is showing very significant bowing, the horizontal alignment is being maintained. I believe I am going to need to deal with the overall 'shape' of the DTM in processing before the alignment stage (unless I am mistaken?). I'll run some additional tests on other DTMs to check how portable this parameterization is for my use case, I'll check the other image in the pair with cam_test, and I'm going to try building the DTM in chunks thinking that might address what @dpmayerUSGS suggested when discussing N/S clipping. I am also wondering if a 'chunked' DTM won't exhibit the same parabolic elevation swings. The fact that the CSM is 'losing' the top/bottom of the pair while ISIS is able to generate a DTM is bothersome to say the least.

Two step pc_align ICP using point to point with 85% inlier requirement and then FGR seeded with the output from the first pc_align on the same point cloud as the initial posts.

Transect of the CTX DTM to the MOLA gridded product (identical datums).

[dpmayerUSGS]

I believe I am going to need to deal with the overall 'shape' of the DTM in processing before the alignment stage (unless I am mistaken?).

Yes, the shape issue has to be dealt with earlier in the processing. I really don't think that anything can be done with pc_align to salvage the DTM as it is now. I wouldn't even use it on its own because of how severe the slope errors are. I agree with @oleg-alexandrov that the only real solution for this particular stereopair is dejittering.

[rbeyer]

There's a 500 elevation difference, is that really a jitter problem? Seems much too high of a magnitude for that. Don't get me wrong, there is something quite broken about this pair, but I can't quite put my finger on it.

[jlaura]

I did not have a good feel for just how much smaller that baseline was going to be. :/ bummer. I think the test is going to be pre/post adjustment to get another data point. Thanks for the figure!

[oleg-alexandrov]

This looks like fun. Jay, welcome to the club of folks who spend weeks of their life chasing registration errors.

I used this exchange as an excuse to document the jitter tool and to test it it more with LRO NAC. I don't have time to actually run it on this pair, but for the record, the doc is here, https://stereopipeline.readthedocs.io/en/latest/tools/jitter_solve.html. The usual caveats for the adventurous user apply.

[jlaura]

@oleg-alexandrov Sweet! I'll give this a go tomorrow. If I have questions or observations specific to jitter_solve I'll get a new discussion opened.

🎉

[oleg-alexandrov]

I will be out of town for a few days but I will respond when I can, if need be. I threw 800 images at this tool, with hundreds of pairwise matches among many of the image pairs and it did not fail. I also tested it on sets of 3 and 5 LRO NAC images. But the software is new, and it is not clear how sensitive it is to the anchor weight and the other weights. So there will be some uncertainty. If at least the trend goes in the right direction, it will be encouraging.

[oleg-alexandrov]

Oh, and this will need the daily build from https://github.com/NeoGeographyToolkit/StereoPipeline/releases.

[rbeyer]

Just peeked at our internal-to-HiRISE data server which keeps track of a variety of statistics, and both halves of this HiRISE image had 2 to 6 pixels of jitter, and the first observation indicates that the spacecraft was not in high stability mode, but for the second it was (not that it seemed to matter much).

That doesn't explain the long-wavelength weirdness, but when the spacecraft oscillates to produce HiRISE-scale jitter, I wouldn't be surprised if there was a other frequency components, but long-wavelength stuff like that is supposed to be captured by SPICE, I thought.

[oleg-alexandrov]

The long-wavelength behavior looks like madness. I guess the only alternatives are to throw this out as David says (using the IntersectionErr.tif mean and stddev stats as criteria), or hope that with semi-decent horizontal alignment which appears to exist here, the jitter solver could bend properly that offending spacecraft trajectory to make things behave better, though clearly the magnitude of errors here is not just a handful of pixels. A 500 meter elevation difference is maybe 100 pixels at CTX resolution. Big, but not out of this world, given the overall CTX image dimensions (yes, mixing up vertical and horizontal measurements here).

[jlaura]

cam_test K05_055472_1916_XN_11N210W

Below is the cam_test output for the second image in the pair. I was concerned that the data drops at the top/bottom of the image could be caused by an issue with the second image which was not tested via cam_test. For better or worse, K05_055472_1916_XN_11N210W looks good. Therefore, I am not sure why the ISIS sensor is performing 'better' in this instance in terms of being able to capture additional extent.

I will note that the CSM sensor is able to generate almost 30% more DTMs for the Elysium quadrangle than the ISIS sensor. So, something more complex is clearly occurring.

Loading camera model: K05_055472_1916_XN_11N210W.lev1eo.cub K05_055472_1916_XN_11N210W.lev1eo.json
Using plugin: UsgsAstroPluginCSM with model name USGS_ASTRO_LINE_SCANNER_SENSOR_MODEL
Image dimensions: 5000 52224
Number of samples used: 1050

cam1 to cam2 camera direction diff norm
Min:    1.25124e-10
Median: 2.4916e-08
Max:    5.103e-08

cam1 to cam2 camera center diff (meters)
Min:    1.03498e-05
Median: 0.000198572
Max:    0.18375

cam1 to cam2 pixel diff
Min:    1.00157e-05
Median: 0.00127254
Max:    0.0122513

cam2 to cam1 pixel diff
Min:    2.37485e-05
Median: 0.000477741
Max:    0.0128881

Using Relatively Controlled Images

I also tested using relatively controlled images from a larger quad. Same image pair, that has been relatively controlled with a few thousand other images in Elysium. These results are really compelling. First, we see that the CSM solved for the full image extent. It is not losing the top/bottom of the pair. Second, the alignment horizontally looks great and the profile looks good. I am not ignoring the suggestion to compare histograms, I just haven't had time yet and the profile code is easily at hand.

Edit

Here is the histogram of the final geodiff. As @dpmayerUSGS suggested for a good rule-of-thumb this is normally distributed with mean around zero.

End Edit

This single test seems to support the hypothesis that the issues in the original pair are 100% ephemeris related. The long wavelength distortion is not handled properly in the a priori SPICE. I have another 1/2 dozen or so CTX pairs that also exhibit poor horizontal alignment that I can test using the relatively controlled data.

It is interesting, but not surprising, that the 'local' bundle adjustment that ASP does is not able to adequately update the sensor pointing. The larger solution is required and I suspect starts to approximate a result that is similar to @oleg-alexandrov's jitter_solve tool. I hope to test the jitter solve tool soon!

Follow up

Thanks all for the input on this. I've really enjoyed this conversation. Hopefully it's cool to keep working through issues like this on here. Are you all seeing other artifacts or issues with this particular DTM that warrant additional inspection?

[oleg-alexandrov]

I am looking at this pair, J03_045820_1915_XN_11N210W K05_055472_1916_XN_11N210W with the CSM model and no bundle adjustment, and I see no outrageous warping with height differences of 1000 meters. At most, I am seeing 150 m difference. Are you sure the original problematic pair had no other things applied to it and it was with raw spice data as read into CSM?

As stated above, "relatively controlled images" fixes things. Does "control" mean one position and rotation adjustment per single image?

How can one explain that nonlinear gross taco warping with amplitude difference of 1000 m go away by simply adjusting one position and one orientation?

All in all, this pair looks decent to me. After bundle adjustment and pc_align the intersection error and difference with MOLA are both under 10 m. There is some jitter, but I can't reproduce the gross problem.

[oleg-alexandrov]

I added a full example, with figures, of solving for jitter for this stereo pair. The results are quite solid. Using a preexisting DEM (MOLA) as a ground constraint seems important, and also using uniformly distributed interest points to capture the jitter. The doc page is as before: https://stereopipeline.readthedocs.io/en/latest/tools/jitter_solve.html. I've also tried another example with a stereo triplet, for Pleiades. That is not documented yet. Could be tried for CTX too.

[jlaura]

@oleg-alexandrov Thanks for the docs! On the orginal pair, can you post the source of the spice? We have the naif stored ephemeris and the improved ephemeris that came out of (I can't remember if it is goddard or somewhere else, @dpmayerUSGS do you recall?).

Control means that this pair, along with 3500 other images were fully bundle adjusted using ISIS, solving for sensor position and orientation. Without looking at the labels, we corrects somewhere north of 500 positions and orientations (before interpolation to smooth the ephemerides). Does that description help describe the process?

How is the horizontal alignment to a controlled base, for example, THEMIS or MDIM2.1 or MOLA shaded relief? That is where I was seeing the most significant, easily visible offsets. pc_align was doing a great job mean centering the error to 0 with a normal distribution for many DTMs. Some where misaligned horizontally in order to minimize (presumably?) the x,y,z fit.

Many thanks for checking out this pair!

[oleg-alexandrov]

I spice-inited with usual ISIS data. I don't recall now when I updated it last.

Before doing bundle adjustment, the CTX stereo pair DEM was within 200 meters or so of MOLA, both vertically and horizontally.

Thank you for the clarification. Since you were able to bundle-adjust with ISIS, which amounts to just one position and orientation per camera, and that made your issue go away, that means that, thankfully, the problem is not really bad warping, which would be nasty, but some big translation (which I can't reproduce).

You mentioned smoothing the ephemerides. I ran into that as well, but am not sure if the issue was the ephemeris (position), or the orientation. The latter appears to have noise as well, as when I resampled it the intersection error undulations became smoother, and those speak of orientation more than of position perturbation. The jitter solver resamples both of these before optimization.

Going forward, if you run into another nasty pair, we could see first if we can reproduce same .json camera files, and then see what to do next. CTX is a nice sensor for sorting out these problems. Images are not huge, but have pretty big footprint to fit enough MOLA samples.