AgroCam imagery fails multi spectral processing. Error: Strange values in reconstruction

G’day Folks,

I am attempting to process multi spectral imagery for the first time, so I am probably missing something obvious…

I am running WebODM 1.9.11 in Docker on Windows 10. This container has successfully processed several data sets from a P4P. It has also processed this AgroCam imagery as a standard orthophoto successfully.

If I upload just the AgroCam imagery it fails to process. If I upload both the AgriCam and P4P imagery it fails. There was an issue (operator error) that resulted in the AgroCam being flown using intervalometer so there is no semblance of synchronization between RGB and the ArgroCam. I don’t know enough about the process to know if this is relevant ?

Regards,
Pete

Dataset is here :

Error code for the geeks :wink:

===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 1
Traceback (most recent call last):
File “/code/stages/odm_app.py”, line 94, in execute
self.first_stage.run()
File “/code/opendm/types.py”, line 346, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 346, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 346, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 327, in run
self.process(self.args, outputs)
File “/code/stages/run_opensfm.py”, line 192, in process
octx.run(‘export_visualsfm --points’)
File “/code/opendm/osfm.py”, line 34, in run
system.run(’%s %s “%s”’ %
File “/code/opendm/system.py”, line 106, in run
raise SubprocessException(“Child returned {}”.format(retcode), retcode)
opendm.system.SubprocessException: Child returned 1

===== Done, human-readable information to follow… =====

[ERROR] Uh oh! Processing stopped because of strange values in the reconstruction. This is often a sign that the input data has some issues or the software cannot deal with it. Have you followed best practices for data acquisition?

Full task output is truncated (not sure wherre to find the full log), but this is the point it all started to go south;

2021-12-12 10:47:11,049 DEBUG: Undistorting image 2021_1212_015620_053.JPG
[INFO] running /code/SuperBuild/install/bin/opensfm/bin/opensfm export_visualsfm --points “/var/www/data/e1403e22-ab47-4066-9abe-fde40149b4be/opensfm”
Traceback (most recent call last):
File “/code/SuperBuild/install/bin/opensfm/opensfm/io.py”, line 1221, in image_size_from_fileobject
with Image.open(fb) as img:
File “/usr/local/lib/python3.9/dist-packages/PIL/Image.py”, line 2943, in open
raise UnidentifiedImageError(
PIL.UnidentifiedImageError: cannot identify image file <_io.BufferedReader name=’/var/www/data/e1403e22-ab47-4066-9abe-fde40149b4be/opensfm/undistorted/images/2021_1212_015441_020.JPG.tif’>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/code/SuperBuild/install/bin/opensfm/bin/opensfm_main.py”, line 15, in
commands.command_runner(
File “/code/SuperBuild/install/bin/opensfm/opensfm/commands/command_runner.py”, line 38, in command_runner
command.run(data, args)
File “/code/SuperBuild/install/bin/opensfm/opensfm/commands/command.py”, line 12, in run
self.run_impl(data, args)
File “/code/SuperBuild/install/bin/opensfm/opensfm/commands/export_visualsfm.py”, line 11, in run_impl
export_visualsfm.run_dataset(dataset, args.points, args.image_list)
File “/code/SuperBuild/install/bin/opensfm/opensfm/actions/export_visualsfm.py”, line 29, in run_dataset
export(reconstructions[0], tracks_manager, udata, points, export_only)
File “/code/SuperBuild/install/bin/opensfm/opensfm/actions/export_visualsfm.py”, line 49, in export
shot_size_cache[shot.id] = udata.undistorted_image_size(shot.id)
File “/code/SuperBuild/install/bin/opensfm/opensfm/dataset.py”, line 1112, in undistorted_image_size
return self.io_handler.image_size(self._undistorted_image_file(image))
File “/code/SuperBuild/install/bin/opensfm/opensfm/io.py”, line 1376, in image_size
return image_size_from_fileobject(fb)
File “/code/SuperBuild/install/bin/opensfm/opensfm/io.py”, line 1226, in image_size_from_fileobject
image = imread(fb)
File “/code/SuperBuild/install/bin/opensfm/opensfm/io.py”, line 1093, in imread
_, ext = os.path.splitext(path)
File “/usr/lib/python3.9/posixpath.py”, line 118, in splitext
p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not BufferedReader

===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 1
Traceback (most recent call last):
File “/code/stages/odm_app.py”, line 94, in execute
self.first_stage.run()
File “/code/opendm/types.py”, line 346, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 346, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 346, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 327, in run
self.process(self.args, outputs)
File “/code/stages/run_opensfm.py”, line 192, in process
octx.run(‘export_visualsfm --points’)
File “/code/opendm/osfm.py”, line 34, in run
system.run(’%s %s “%s”’ %
File “/code/opendm/system.py”, line 106, in run
raise SubprocessException(“Child returned {}”.format(retcode), retcode)
opendm.system.SubprocessException: Child returned 1

===== Done, human-readable information to follow… =====

[ERROR] Uh oh! Processing stopped because of strange values in the reconstruction. This is often a sign that the input data has some issues or the software cannot deal with it. Have you followed best practices for data acquisition? See

1 Like

Welcome, Pete!

Thanks for the great info (logs, WebODM version, and data!). All hugely helpful.

I’m going to take a poke at this all this week, so please bear with me while I investigate.

1 Like

Much appreciated. It’s not mission critical so no mad rush to figure it out, it’s just an economical option for (hopefully) NDVI imagery on a P4P.

When I process the imagery from each camera separately as quick ortho’s, the resultant images are offset approximately 3 meters. Presumably due to using different GPS references.

I am new to QGIS but I assume there is a way to align geoTIFF’s using common features in both images ?

1 Like

Can you give me an idea of how much RAM and pagefile you have on your machine?

Hehe… One of my favorite questions. What are you using as your truth data to compare the location to? If something like Google Earth, be mindful that it is often on the order of 3-10m off from actuality.

Yep! There are numerous ways, but the Georeferencing Tool is where you’d want to look. You can place N-number (4+ is normally best) of points to reshape it.

64GB system. Pagefile shows 9GB, but that is on automatic settings so I assume it is dynamic.
WebODM diagnostics shows 50GB total. I don’t believe I have changed the default docker configuration for memory allocation.

I am importing both geoTIFFs into the same QGIS project. There is at least one obvious feature and the offset is between both geoTIFFs. I have only looked briefly at GCP’s up till now. I think I’ll need to get serious about them. I do have access to RTK equipment so I’ll probably start laying out permanent GCP’s in my area of interest.

1 Like

This is pretty preliminary/unconfirmed, but I’m not seeing the GITUP G3 Duo in upstream OpenSFM, so that might be why it fails to reconstruct (if it can’t tell what the lens/sensor parameters are).

Are the GITUP G3 Duo images manipulated in any way? Resized? Scaled? I’m having a hard time finding information that that camera supports images at 4608x3456 (16MP) [like what you provided]. Everything I can find seems to indicate it should be 12MP for stills.

the 16MP is an optional setting in the camera menus. I was aiming for best resolution. I’ll create another dataset at 12MP in the next few days.

Loosely related; I’ve attempted to map GCP’s to physical ground features using a uBlox M8P with NTRIP corrections. FastOrtho reconstruction results in garbage. I suspect that’s because I’m having to convert the uBlox NMEA position to UTM. I’ve never worked with UTM, so I’m assuming I’m doing something wrong.

1 Like

Can you attach those positions? Should be fine to leave them in their source CRS without converting them.

1 Like

Seems to have worked, once I took out all formatting from the text file.

The GCP related chapter in the wiki is pretty light on guidance for users who don’t have a background in GIS.

I’ll reprocess with the EPSG:4326 GCPs and see what we get.

1 Like

Thanks for the confirmation and the feedback.

I’m going to be working my way around to all of the documentation eventually :slight_smile:

1 Like

I’ve re-run the AgroCam imagery and still getting a similar output; the stitched image is in the right geographic area but instead of covering ~30ha, it has been shrunk to ~10 m^2 and rotated ~90 degrees

1 Like

Sounds like it is failing to reconstruct properly. Bad reconstruction like that can indeed be due to not working out the lens/sensor parameters properly.

Can you link me to the native 12MP (not upscaled 16MP) data? I still need to figure out where/how I’m going to get the sensor specs… Who did your conversion to NDVI/Full Spectrum? KolariVision?

Not sure who’s filters are fitted. but this is the kit https://www.agrocam.eu/product-page/dji-phantom-4-ndvi-upgrade-single-camera-ndvi

I’ll hopefully get a chance to run another mission this week with 12MP images.

1 Like

Attempted a dataset today with 12MP images but WebODM is making a mess of the stitching again.
IR Dataset here for what it’s worth…

I’ll try again tomorrow.

1 Like

Thanks for those, Pete.

I still can’t get confirmation on the sensor and its dimensions from the OEM yet, so I can’t patch upstream OpenSFM to have the right parameters (which should greatly help).

I’ll try patching locally and running this new unresized dataset this week.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.