Unify names, order and number of channels in config files

[romeokienzler]

@Joao-L-S-Almeida is this already done?

[Joao-L-S-Almeida]

Do you mean to guarantee the names and orders for the bands are uniform ? @romeokienzler Currently three formats are supported, strings, integers (including intervals) and HLSBands. There are tests for all those cases.

[romeokienzler]

@Michal-Muszynski can you please test this issue and let us know if it works?

[Michal-Muszynski]

@romeokienzler I have tested integers and strings, the terratorch is able to capture an error when output_bands is not a subset of dataset_bands. However I have found an exception, model channel (bands) and output_bands might be complete different in a config file and there will be no error returned by terratorch, for example, dataset_bands:

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10 output_bands:
• 1
• 2
• 3
• 4
• 5
• 6
  bands (model):
• 100
• 101
• 102
• 103
• 104
• 105 We can have the same exception for strings, for example, dataset_bands:
• a
• b
• c
• d
• e
• f
• g
• h
• i
• j output_bands:
• a
• b
• c
• d
• e
• f bands (model):
• BLUE
• GREEN
• RED
• NIR_NARROW
• SWIR_1
• SWIR_2

[CarlosGomes98]

@Michal-Muszynski its true, as the code is right now, the model bands currently are checked separately, as they depend on the pretrained model that is being used, the bands it was trained on, and how these were named, rather than the dataset.

I would say this works as intended though, as we have no way of enforcing the naming used by each of the pretrained models to name their bands.

[Michal-Muszynski]

@romeokienzler I have tested channel selection in config files using integer inclusive brackets for output_bands, dataset_bands and bands (model). That works correctly, we just need to remember that output_bands should be a subset of dataset_bands and output_bands should always match bands (model channel).

[romeokienzler]

@Michal-Muszynski can you confirm this is working or it needs further work? can we close?

@Joao-L-S-Almeida suggesting to add a warning to the documentation / or raise exception