You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?)
The text was updated successfully, but these errors were encountered:
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?)
The text was updated successfully, but these errors were encountered: