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.