Pixel values when creating an orthomosaic from .tiff

[CerfoBB]

Hello everyone,

I want to produce an orthomosaic of thermal images acquired with a zenmuse H20T.
I have pre-calibrated the images manually, so my base images are .tiff with pixel values in degrees celcius and metadata identical to the original RJPG.

With this data I am able to produce the orthomosaic with the correct values with Pix4D, as a proof of concept.

However with WebODM there are some problems.
For now my best results are obtained by giving ODM .tiff images (UINT 16bit) whose values have been extended between 0 and 65535 by adding 27315 to the temperature values.
Non-default parameters: auto-boundary: true, dsm: true, fast-orthophoto: true, radiometric-calibration: camera, skip-3dmodel: true

The orthomosaic creation works but the pixel values change completely. For example, while the base data varies between 27360 and 27700, the orthomosaic pixel values vary between -0.078 and 4.155.

I tested several other variations such as using .tiff SINT 16bit rescaled or non-scaled, radiometric-calibration: none, several ODM presets… however no configuration allowed me to obtain the original values. Some configurations even crash the creation process.

Here are the images in question (.tiff UINT 16bit rescalled): https://we.tl/t-hL4p0eo0fU
Here is the orthomosaic produced with the best results: https://we.tl/t-owUWlUcPrD

Has anyone ever faced a similar problem in creating orthomosaics?

Thanks!

[Saijin_Naib]

Welcome!

Sorry for the trouble. Thank you for providing such great detail and sample data.

Are you able to provide the output from Pix4D, or at least the metadata/structure (band count, bit depth/type, etc)? It’d be helpful in starting to assess what’s happening.

[CerfoBB]

Here is the orthomosaic produced with Pix4D, and the images used (SINT 16bit containing temperature data without recalling): https://we.tl/t-eOvtX7rlRA

On my side, when used with ODM, these images produce a 2 band raster (I don’t know what the 2nd band is) with the wrong values.

[Yunpeng_Li]

For UINT16 calibrated DJI H20T imagery, the ODM pipeline can translate the raw image values back to temperature values (in Float32 GeoTIFF) if you turn on the radiometric-calibration option. Since the raw data is single band, you should pass the skip-band-alignment option as well.

As H20T is not global shutter and the images are low resolution, you can also try the following options:

• sfm-algorithm: planar (for flat areas)
• fast-orthophoto: false
• feature-quality: ultra
• pc-quality: ultra

[CerfoBB]

The radiometric calibration has indeed shown the best results so far (radiometric-calibration: camera) but the values are not the right ones.

I have tested on several types of images with the following parameters: auto-boundary: true, radiometric-calibration: camera, sfm-algorithm: planar, skip-3dmodel: true, skip-band-alignment: true

• RJPEG: Orthomosaic creation ok but RGB values only.

• TIFF UINT16 raw (=temp C) : Assembly fails

Logs

===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 134
Traceback (most recent call last):
File “/code/stages/odm_app.py”, line 88, in execute
self.first_stage.run()
File “/code/opendm/types.py”, line 380, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 380, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 380, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 361, in run
self.process(self.args, outputs)
File “/code/stages/run_opensfm.py”, line 35, in process
octx.feature_matching(self.rerun())
File “/code/opendm/osfm.py”, line 416, in feature_matching
self.match_features(rerun)
File “/code/opendm/osfm.py”, line 421, in match_features
self.run(‘match_features’)
File “/code/opendm/osfm.py”, line 34, in run
system.run(‘“%s” %s “%s”’ %
File “/code/opendm/system.py”, line 109, in run
raise SubprocessException(“Child returned {}”.format(retcode), retcode)
opendm.system.SubprocessException: Child returned 134

===== 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 Flying Tips — OpenDroneMap 3.1.7 documentation

• TIFF UNIT16 scalled (=temp C + 27315) : Orthomosaic creation ok but pixel values are between 0 and 4.164

• TIFF UNIT16 scalled (=tempC + 27315), but radiometric-calibration: none : Assembly fails

Logs

===== 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 88, in execute
self.first_stage.run()
File “/code/opendm/types.py”, line 380, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 380, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 380, in run
self.next_stage.run(outputs)
[Previous line repeated 1 more time]
File “/code/opendm/types.py”, line 361, in run
self.process(self.args, outputs)
File “/code/stages/openmvs.py”, line 226, in process
raise e
File “/code/stages/openmvs.py”, line 220, in process
system.run(‘“%s” %s’ % (context.omvs_densify_path, ’ '.join(config + gpu_config + extra_config)))
File “/code/opendm/system.py”, line 109, 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 Flying Tips — OpenDroneMap 3.1.7 documentation

Do you have any clues about changing values in TIFF UNIT16 scalled? Or a way to allow the assembly not to fail?