Converting linescan camera resolution

[Jeremy Allen]

Hello all, 

I am orthorectifying KH-9 HEXAGON images using the new method released in 3.6.0-alpha, and have been having great success so far. A big thank you to the developer of the latest release. For some images with extreme terrain and shadows, the dem2gcp and bundle_adjust steps aren't able to address some local warping at the horizontal edges of the image. I tried using the fix prescribed in section 8.28.10 using jitter_solve, and it worked well for sub_16 images. 

Unfortunately, I have only been able to successfully mapproject the sub_16 images, and the mapproject tool terminates during the mapprojection of the full resolution images. I am assuming that this is likely a memory issue with my local machine, as the images are very large. Ideally I would like to convert the jitter_solved CSM camera to the full resolution, and try mapprojecting the full resolution image with that converted camera. 

It is mentioned in the documentation that a tool is being planned to facilitate the conversion of the linescan camera resolutions. I was wondering if that release is imminent? If anyone has any suggestions on overcoming mapproject errors, that would also be very appreciated.

Below is the way I invoke the mapproject tool for the full resolution images. The images have been rotated 90 degrees as prescribed.

mapproject \
  --tr 1 \
  --ot Byte \
  --tif-compress None \
  ./stereo/dem-adj-43.tif \
  ./stereo/D3C1216-300814-015/jitter_solve/forward.tif \
  ./stereo/D3C1216-300814-015/jitter_solve/forward.json \
  ./stereo/D3C1216-300814-015/jitter_solve/fwd.map.tif

Cheers,

Jeremy 

[Oleg Alexandrov]

Hello Jeremy,

I am glad you think the recent update to KH-9 processing is some progress.

 For some images with extreme terrain and shadows, the dem2gcp and bundle_adjust steps aren't able to address some local warping at the horizontal edges of the image. I tried using the fix prescribed in section 8.28.10 using jitter_solve, and it worked well for sub_16 images. 

The logic is a bit fragile. The dem2gcp program is hoping that your reference DEM and the ASP-produced DEM have enough features in the hillshade, such as mountains, to reliably and densely tie the two. For flat areas the disparity can be wrong, of course. Here going way beyond your point, but in this case it is suggested to use the --max-disp option and do lots of inspections.

 

Unfortunately, I have only been able to successfully mapproject the sub_16 images, and the mapproject tool terminates during the mapprojection of the full resolution images. I am assuming that this is likely a memory issue with my local machine, as the images are very large. Ideally I would like to convert the jitter_solved CSM camera to the full resolution, and try mapprojecting the full resolution image with that converted camera. 

If you simply take the camera model at sub16 it won't work for higher resolution.

 

It is mentioned in the documentation that a tool is being planned to facilitate the conversion of the linescan camera resolutions. I was wondering if that release is imminent? If anyone has any suggestions on overcoming mapproject errors, that would also be very appreciated.

I now added a link to the script in the doc, at the very bottom of https://stereopipeline.readthedocs.io/en/latest/examples/historical.html#kh9 (hard reload required in browser).

I did not have time to polish this before the project ran out of time, but it should work or at least let me know if it fails.

Happy to hear how this is going. We spent a lot of time on this and got plausible results if there are enough mountains to tie to. If you have images from another source, consider incorporating them somehow.

[Oleg Alexandrov]

To add, this tool takes, for example, a camera at sub16, and produces a camera for sub8. So you can try mapprojecting with that and sub8 images. If in luck, can scale up. Likely re-running the jitter solving at sub8 is good, and improvement should be seen before continuing.

If the problem with the crash you have is purely due to memory, this should at least work at lower resolution.

At full resolution, consider inspecting your file with gdalinfo. Our tools don't like images that have block sizes as wide or as tall as the full image. One can convert them to block sizes of 256 by 256 for example, with gdal_translate with the -co option and setting the block size.

[Jeremy Allen]

Dear Oleg,

Happy new year, and thank you very much for sharing the CSM camera resolution, it worked great. After some tinkering, I found that setting the --threads parameter to 1 worked for mapprojecting the full size image with the re-scaled CSM camera. I had no issues with mapprojecting the full sized images with the optical bar camera, and so this might be an issue with the CSM camera specific to my image, as there is quite a lot of warping in the edges of the image where cloud cover is present after solving for jitter. Regardless I am glad to have found a solution that works.  

Thanks again, 

Jeremy

[Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC]]

Jeremy,

I am glad there is progress.

I am not sure why one needs to set --threads 1 for mapprojecting at full size, but I am glad it worked at least.

>as there is quite a lot of warping in the edges of the image where cloud cover is present after solving for jitter. Regardless I am glad to have found a solution that works.  

Clouds can be a pain as they can confuse the jitter solver. Normally they should not, if few, but a whole blanked out portion may make the solver go wild, maybe. We have some options for anchor points for constraining the solution which works independently of interest points, but it is likely a partial solution (the doc has more info). One could try to push hard on the anchor points and see if things get better without affecting the fit in other areas. 

I am also not sure how lens distortion would work for you. I think the doc suggests enabling that (in the bundle adjust-based refinement), but that needs a huge lot of dense features, or else would be another source of problems on image edges maybe.

We know the tools are not going to be a universal solution especially where there is lack of relief, but hoping you'll get somewhere.

Oleg

 

---

From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of Jeremy Allen <jeremy....@gmail.com>
Sent: Monday, January 12, 2026 2:04 PM
To: Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: [EXTERNAL] [BULK] Re: Converting linescan camera resolution

 

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

--
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/40f0358a-8eda-4f06-8f4d-ba97ce0eff69n%40googlegroups.com.