Running Danesfield - Demo

[NourSoltani]

Greetings! First of all, I would to thank you for sharing the demonstration.. It is helping a lot. And also, I would like to apologize since I have been asking many questions the last period. Well, I have downloaded a part of data (more specifically the Jacksonville data), the docker image...etc. But whenever I try to run the script, it always prompt this message

Is there any idea for what could be the cause of that?

[mleotta]

@jacobderosa can you take a look at this and respond?

[jacobderosa]

@NourSoltani It doesn't look like your input_Jacksonville.ini is in your config directory (that you mounted to /configs)

[NourSoltani]

@jacobderosa Well It exists in the /configdir folder which i have mounted to /configs

[jacobderosa]

@NourSoltani Try putting the _source /opt/conda/etc/profile.d/conda.sh && conda activate core3d && python /danesfield/tools/run_danesfield.py --image --vissat /configs/inputJacksonville.ini part of the command in double quotes

[NourSoltani]

Thank you! I think there is some advancement.. But it stopped.. here is what I found

[jacobderosa]

@NourSoltani this often happens when there is insufficient GPU memory to run the VisSat step. There are ways to lower the GPU requirements if you are interested, as well as running VisSat with CPUs instead of GPUs (this will take much longer). Or if you already have a point cloud, there is an option to start Danesfield with that cloud instead of generating one.

[mleotta]

You could also try a different site or manually shrink the specified region of interest for Jacksonville to cover a smaller areas. Jacksonville is the largest of our test datasets. Larger sites will require more GPU memory. We don't currently have tiling implemented to break the problem into smaller subproblems. What GPU hardware are you using?

[NourSoltani]

@mleotta @jacobderosa We have a Quadro RTX 6000 with 24 GB of GPU memory.. So I think it is sufficient.. isn't it? also, I am trying to work with the point cloud data; I am dealing now with the [Jacksonville_P3D.las] and [Jacksonville_VisSat.las] files which I have found in data.kitware.com I am sorry again for disturbing, but I think your product is a very interesting solution.

[mleotta]

Yeah, I think 24GB should be enough. Looking closer, this error doesn't look like a GPU memory issue. It looks like VisSat is trying to compute a np.percentile on and empty z_values on line 99 of VisSatSatelliteStereo/reparam_depth.py. @jacobderosa can you help debug why z_values could be empty? Those processing times for previous steps look very quick. Maybe it's not actually finding the images?

[jacobderosa]

The processing time for clean_data seems reasonable but the rest are very quick. It does suggest VisSat couldn't find the images. Are the images organized in the right directory structure at the correct location?

[NourSoltani]

@jacobderosa . I think it is in the right place; As you can see in the attached image.. and the instruction for mounting with the docker container was: /media/nextav/NextAV/Nour/Danesfield_Nour/Danesfield/demo/Data:/mnt

And the full command that i've typed was: docker run -it --gpus all --shm-size 8G -v /media/nextav/NextAV/Nour/Danesfield_Nour/Danesfield/demo/Data:/mnt -v /media/nextav/NextAV/Nour/Danesfield_Nour/Danesfield/demo/outdir:/workdir -v /media/nextav/NextAV/Nour/Danesfield_Nour/Danesfield/demo/configdir:/configs -v /media/nextav/NextAV/Nour/Danesfield_Nour/Danesfield/demo/Models:/models kitware/danesfield "source /opt/conda/etc/profile.d/conda.sh && conda activate core3d && python danesfield/tools/run_danesfield.py --image --vissat /configs/input_Jacksonville.ini"

[jacobderosa]

I recommend checking the log files for the clean_data and crop_image steps. You can find them at outdir/vissat/logs. They will have more clues as to what's going wrong here. Post them here and I can look through them.

[NourSoltani]

Oh Okay! I understand you. You can find below all the log files. log_sfm_perspective.txt log_reparam_depth.txt log_derive_approx.txt log_crop_image.txt log_clean_data.txt

Also for the two quotes in the full command; why did we put them in that way?

[jacobderosa]

It looks like GDAL is unable to crop the input images (see the errors in log_crop_image.txt). Can you check to see if /workdir/Jacksonville/vissat/images is empty, or if the links in there are broken? Also, are you using kitware/danesfield:latest or kitware/danesfield:danesforaws from Dockerhub? You should use the latter.

As for the quotes, I believe it's so the entirety of the encapsulated text will be interpreted as part of the same command, though I'm not certain.