GCPs and multispectral datasets

Hi! Last month I was having issues processing multispectral datasets with GCPs; after a good amount of trial and error and a hint in the forum (Fault with gcp_list.txt processing - #6 by ITWarrior) I established that having GCPs labelled in multiple bands within one capture invariably causes ODM to fail at the OpenSfM reconstruction step.

Multispectral rigs (e.g. MicaSense) consist of multiple cameras with a fixed offset; a single capture would produce, say, 5 files – one in each band. The filename follows the format capture-no_band.tif format, and GCPs will usually appear in all 5 images in a capture. However, including images from more than one band (eg. anything other than ????_1.tif) in gcp_list.txt leads to failure. I haven’t tested this further, but it seems irrespective of the --primary-band flag.

My understanding has been that, in addition to increasing georeferencing accuracy, the use of GCPs is a method for aligning the bands alternative (or supplementary) to the camera rig offsets. It looks like currently only one of the bands in a multispectral system is being georeferenced. Is this intentional behaviour? Since a given GCP will appear in at different pixel coordinates in different bands within the same capture, is it desirable (and wise) to ignore this information?

1 Like

Hi :wave: !

You should only add the primary band images to the GCP (as you found out).

The other bands are pixel-wise aligned to the primary band, so accuracy isn’t (shouldn’t be) affected.


Thanks @pierotofy; is the choice of the primary band arbitrary?

I’m thinking what the best practice would be here. Would a dataset consisting of each multispectral band processed separately (with dedicated gcp file) be a useful benchmark?

By default ODM selects the first band (the band that has the lowest band_index in the EXIFs), but you can override it. Depending on the scene one band might work slightly better than others. I suppose you could try all of them and see which one gives you the best accuracy.