SPOT 6/7 camera model and jitter correction

[davidef...@gmail.com]

Hi folks,

I have been processing some SPOT 6 stereo pairs with RPCs and noticed quite a lot of jitter in the resulting intersection error maps and DEM differencing.

So I was wondering if it would be at all possible to introduce support for the exact camera model of SPOT 6/7 so that jitter can also be hopefully minimized. As far as I know, the metadata file for the camera model follows the DIMAP V2 scheme of Pleiades, although with some differences (e.g. comparing the XML file for SPOT6 and Pleiades PHR, quaternions are stored differently).

Best wishes

Davide

[Oleg Alexandrov]

Spot6 looks like a nice addition. I will have this on likely in a couple of days. 

--
You received this message because you are subscribed to the Google Groups "Ames Stereo Pipeline Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ames-stereo-pipeline...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/16151337-7e10-49fa-ba63-acb56bce33c4n%40googlegroups.com.

[davidef...@gmail.com]

Hi Oleg,

that would be amazing, thanks!

Cheers

Davide

[Oleg Alexandrov]

Hi Davide,

I added support for the SPOT 6/7 exact linescan camera model. It uses most of the logic as for Pleiades NEO.

I tested with the public single camera sample for La Crau, France (PAN band). The exact model agrees with the RPC model with a pixel error of under 0.002 pixels.

I did not have a SPOT 6 stereo pair, so I created a synthetic one by adapting a Pleiades NEO run. With this synthetic data, stereo, bundle adjustment, and jitter solving all run as expected.

For next steps, it would be very helpful to run parallel_stereo with an actual SPOT 6 dataset using the exact linescan model (session type "spot") and compare the results against the same run with RPC. 

You can also try our cam_test tool with the exact and RPC cameras as inputs to see if you get similar agreement (this is a very quick step, before doing stereo). 

Then one can proceed with bundle adjustment and jitter solving. As before, our jitter solver can solve some things, but if the ref DEM has big differences such as over steep areas, lots of snow or vegetation, it can struggle. Ideally one should run it with a higher DEM uncertainty and evaluate carefully. I would be happy to hear if it makes a difference for the better. 

The build 2026-03-25 has this: https://github.com/NeoGeographyToolkit/StereoPipeline/releases

The documentation is at: https://stereopipeline.readthedocs.io/en/latest/examples/spot67.html

The jitter solving workflow is the same as for Pleiades: https://stereopipeline.readthedocs.io/en/latest/tools/jitter_solve.html#example-3-airbus-pleiades

See also the limitations of jitter solver: https://stereopipeline.readthedocs.io/en/latest/tools/jitter_solve.html#limitations

Oleg

To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/3937d9fa-b08f-43fe-94af-82680ec30a15n%40googlegroups.com.