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

cam2rpc bug with large images #296

Closed jchollingsworth closed 2 years ago

jchollingsworth commented 4 years ago

cam2rpc gives an error if the source image is too large (dimension > 79999 pixels), even if the desired crop region is small.

Would be good to fix this. :)

jchollingsworth commented 4 years ago

Hi... just wondering if this problem is an easy fix(?), because I need to use it extensively for some WV work, and I hitting this problem that the input image is too large, and so ASP won't crop it (even though I wish to crop it to something relatively small).

Cheers, J

ScottMcMichael commented 4 years ago

I'll try to take a look at it over the weekend.

ScottMcMichael commented 4 years ago

Can you send me your command line call and any small files you are using in your test case?

jchollingsworth commented 4 years ago

Hi Scott... thanks :)

My call is this: cam2rpc -t dg --dem-file demtmp.tif --penalty-weight 0.001 --bundle-adjust-prefix ba2 --threads $threads $f ${f:0:end-4}.xml ${f:0:end-4}_rpc.xml --save-tif-image

My input image ($f) is a tif, created with dg_mosaic, built of several (typically 4 to 7) wv tiles (as delivered from dg). So the long dimension of the input:tif is larger than 79999 pixels.

In this case, I find the corner positions (in lat long) of the raw mosaic (usingmapproject with query projection)... I then crop a reference DEM to this same region. Then I give this DEM to cam2rpc, rather than specifying a lat long crop box and height ranges... I just thought this would be easier. My goal was to re-write the RCPs.

However, I should say that even when I reduce the RPC region to being much smaller... using a lat long crop box for example, which would give a final cropped image with longest dimension <79999 pixels, I still get this same error. Because the starting tif (i.e. the dg_mosaic result) is big. Even though the final requested output is small. Does that make sense?

In short, I would quite like to crop several WV images to the same region, even though their starting mosaics have different extents. cam2rpc seems to throw out this error if the starting mosaics are large, even if the output extents are not. Which seems odd.

I'm not sure which files to send... the tifs are huge. Is the xml still useful?... and cropped dem?... and the adjust file I'm using? In my call, I had already bundle_adjusted some wv scenes with dg session. I then want to run stereo with mapprojected images, which requires converting the dg xml + adjust files to rpcs, so I can use dgmaprpc, or rpcmaprpc.

ScottMcMichael commented 4 years ago

Can you simplify the call down to a single image call, email me the xml files, bundle adjust result files, and also email the gdalinfo output from any large files? I can fake any image data but I need the proper geo/camera information to make sure I am exercising the same parts of the code.

It looks like the code is trying to load one of the input images entirely in memory at some point when it really should not need to for this operation.

ScottMcMichael commented 3 years ago

The fix for this issue should (finally) be in the main build now.