search

NeoGeographyToolkit / StereoPipeline

The NASA Ames Stereo Pipeline is a suite of automated geodesy & stereogrammetry tools designed for processing planetary imagery captured from orbiting and landed robotic explorers on other planets.
Apache License 2.0
479 stars 168 forks source link

mapproject with crop window #310

Closed jchollingsworth closed 4 years ago

jchollingsworth commented 4 years ago

Hi,

I don't think it's currently possible(?), but it would be very useful to be able to mapproject an image using a cropbox defined from the raw image (like using -srcwin in gdal_translate). Otherwise, if you want to mapproject only a small region, you have to crop the raw image manually and adjust the camera file... or use projwin, but this requires you to know the eventual projected coordinates of the raw cropbox positions... and anyhow, if the raw image is oriented substantially off NSEW, the final mapprojected image will show areas outside of the cropbox.

Cheers, J

oleg-alexandrov commented 4 years ago

mapproject has the option --t_pixelwin in addition to --t_projwin. I never used it myself, but it is documented, and I think we use it internally when we perform the map-projection using multiple processes with each allocated a tile. See if it works for you.

jchollingsworth commented 4 years ago

t_pixelwin refers to the pixel positions in the final mapprojected image, not the raw... so you need to know where the image will end up before you can choose the relevant positions.

Maybe this is a bug(?), because I can't see the value of having t_pixelwin for cropping when t_projwin exists for cropping the final mapprojected image.

ScottMcMichael commented 4 years ago

I don't think there is currently a way to do this besides cropping the input image.

oleg-alexandrov commented 4 years ago

I looked at the code. There is a lengthy chain of function calls getting deep into VisionWorkbench that would need to be overhauled to make it possible to choose a custom input image region to which to restrict the map-projection. Some lad who wrote that code, long time ago, just was not enough of a visionary, I guess. I think the case for having this functionality is not very strong for now to warrant such extensive code rework.