Great! 🙂

I don't have much to comment on the code, my main remark at this stage is rather on the structure: Should we already anticipate other CLI usage than coregistration (e.g., terrain attributes, uncertainty)?

If yes, we could potentially separate into different namings, for instance by adding a first parameter to the parsing: xdem coregister path_ref path_sec, which could be extended to other modules to run for instance xdem terrain "slope", xdem uncertainty "method1" etc.
But this is a structure that works only if the functionalities are independent. We could also think of another structure where all these steps can be run sequentially (for instance all users run the uncertainty after coregistration), and everything is combined into a single call like xdem pipeline *params.
Or we could have both.
The structure(s) will have to be reflected in the JSON config file(s), so worth thinking ahead I think!

Small remarks:

• Should we modify "path_sec" -> "path_tba" to match the Python API? Or we can change the Python API.
• To save inlier_mask, can also write more shortly (duplicates the boolean data, which is not ideal even if it's pretty light; we'll have the _save() function callable on the NumPy array in GeoUtils to avoid that soon):

inlier_rst = coreg_dem.copy(new_array=inlier_mask)
inlier_rst.save("xxx.tif")

Thanks for your feedback @rhugonnet.

• I agree with you for the anticipation of other CLI usages, then I have restructured the code to allow other uses to be integrated.
  Now, to perform coregistration, the command is :
  xdem [options] coregister path_ref path_tba

• I have changed the path name in the documentation to match with Python API

• Thanks for the tip to save the inlier_mask in a simpler way, even if it is not perfect 👍

Updated following the merge of PR #617