Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bands identification: make mandatory and use stac's eo extension's common names #441

Open
remtav opened this issue Dec 21, 2022 · 0 comments

Comments

@remtav
Copy link
Collaborator

remtav commented Dec 21, 2022

Currently, the dataset.bands parameter is a list as [1,2,3], ["R", "G", "B"] or ["red", "green", "blue"].
However, if a model is trained with bands as integers (therefore this param is saved in the checkpoint to be used during inference), then during inference a stac item is used (rather than a multiband raster), a mapping must be provided for GDL to select proper bands.

The need here is to have a common language for all places where bands must be selected or ordered. This common language would be stac's eo extension's common names.

(to be translated)
Si un utilisateur veut entraîner avec des bands comme entier (ex.: [1,2,3]), est-ce qu'on devrait le forcer à spécifier {"red": 1, "green": 2, "blue": 3}?
Le but de pouvoir spécifier des bandes sous forme de listes d'entier, c'est surtout de pouvoir reordonner ou sélectionner des bandes si le fichier source est multibande (i.e. on ne connaît pas les bandes qui constitue l'imagerie contrairement aux stacs ietms). Donc, le dict pourrait être une clé séparée dans la config:
bands: [3,2,1] (si la source est BGR)
bands_map: {1: "red", 2: "green", 3: "blue"}
On validerait dans ce cas, que, si "bands" est une liste d'entiers:
bands_map n'est pas None et contient un dictionnaire
pour chaque entier de la liste "bands", il y a une clé correspondante dans le dictionnaire et la valeur pour cette clé est un common name valide
valeur min >= 1 (convention gdal commence à 1)
valeur max <= nombre de bandes dans l'image

puis, ça permettrait à tous les modèles entraînés d'avoir des common name associés à leurs "bandes" requises. Ça permet de garder cette info à même le .ckpt. Donc:

Scénario 1 (très peu fréquent présentement): si on veut inférer un stac item avec ce modèle (initialement entraîné avec de l'imagerie multibande), alors on est plus certain des bandes par common names qu'il nous faut (ce qui n'est pas le cas dans la PR actuelle)

Scénario 2 (serait le cas avec l'imagerie aérienne en ce moment qui n'est pas dans le cube): si on veut inférer une image multibande (bandes inconnues) avec un modèle qui s'attend à des common names, il faudra accompagner l'inférence d'un paramètre qui associe chaque numéro de bande à un common name (comme bands_map, mais en inversant clés et valeurs?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant