This is the end of my console log, as it has been for the past 3 hours or so. I thought the 3D model of some tomatoes might take <1 hour with GPU feature extraction, but it is stuck for some reason.
Creating output file that is 61248P x 60620L.
Processing E:\WebODM51\resources\app\apps\NodeODM\data\1ff4387e-2350-49e4-be06-b7390fab59b3\opensfm\stats\overlap.original.tif [1/1] : 0Using internal nodata values (e.g. 255) for image E:\WebODM51\resources\app\apps\NodeODM\data\1ff4387e-2350-49e4-be06-b7390fab59b3\opensfm\stats\overlap.original.tif.
Copying nodata values from source E:\WebODM51\resources\app\apps\NodeODM\data\1ff4387e-2350-49e4-be06-b7390fab59b3\opensfm\stats\overlap.original.tif to destination E:\WebODM51\resources\app\apps\NodeODM\data\1ff4387e-2350-49e4-be06-b7390fab59b3\opensfm\stats\overlap.tif.
…10…20…30…40…50…60…70…80…90…100 - done.
[INFO] running gdaldem color-relief “E:\WebODM51\resources\app\apps\NodeODM\data\1ff4387e-2350-49e4-be06-b7390fab59b3\opensfm\stats\overlap.tif” “E:\WebODM51\resources\app\apps\ODM\opendm\report\overlap_color_map.txt” “E:\WebODM51\resources\app\apps\NodeODM\data\1ff4387e-2350-49e4-be06-b7390fab59b3\opensfm\stats\overlap.png” -of PNG -alpha
0…10…20…30…40…50…60…70…80…90…100 - done.
[INFO] Exporting report to E:\WebODM51\resources\app\apps\NodeODM\data\1ff4387e-2350-49e4-be06-b7390fab59b3\odm_report\report.pdf
WebODM CPU use is sitting just under 10%, with ~29GB of memory in use, which seems an awful lot to put a few files into a report!
Have you checked if the report is readable in the storage? Maybe you can find something out with this. Other users had success with stopping and starting the process from the last step again
The report has not been generated, I did have a look in the Reports folder.
I cancelled it and restarted from Report, but memory use built up to ~29GB in a few minutes, and it has hung at the same place, where it has been for over an hour.
I really can’t tell. Maybe it is a problem because of ultra- ultra takes four times longer than high. But maybe it is also a problem of the gpu, someone already mentioned that it does something a little bit different.
So i would give the option without gpu a try to make sure that this does not cause the problem
GPU caused a race condition with some large datasets, but it fails much earlier in the processing. I’m pretty sure that is not the case here. Ultra-Ultra is not a problem with a small dataset, and it almost made it to the end in under an hour, whereas build 47 with no GPU took over 3 hours to complete, but didn’t hang on the report.
Running it without GPU is not an option in build 51, if the images are small enough without resizing, it uses GPU.
That attempt had already produced the .obj 3D model, which I could view in Meshlab, it just was not able to pull all the various image files etc together to compile the report, this is well past the GPU usage stage.
Anyway, I’ve deleted it and am running again with slightly different settings.
Just for kicks, I used Saijin_Naib’s favourite setting
Options: feature-quality: ultra, ignore-gsd: true, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 5000, pc-filter: 5, pc-quality: ultra, resize-to: -1, use-3dmesh: true
It took 1h 3m to complete. The shiny white surface of the plate is clearly problematic, and the tomatoes all had a shiny patch from the diffuse side lighting, which cant have helped either. The plate was sitting on a wooden turntable, and photos taken from about the same location to the side, varying a little, mostly in height above the tomatoes.
Running it again now without that, and without setting PC_filter to 5.
Similar strange results with these settings - Options: feature-quality: ultra, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 5000, pc-quality: ultra, use-3dmesh: true
finished in 1h 4m.
Nothing visible initially, but adding textures to the view brings the tomatoes into view. However, I can’t zoom in any more than shown here, as that background grey obscuration moves completely across the image with 2 more clicks on the wheel, leaving nothing visible. The Potree controls don’t work properly either. but the .obj model is again visible normally in Meshlab, although again the tomatoes are not rendered very well.
I think this batch of images is not well suited to creating a 3D model in WebODM! It is notable for very few matches between images being found, most total fail or <20, so failing.
Download the point cloud and mesh to see how well it has done. The problem is with floating point problems in the web viewer combined with no geographic info in the data.
