GeoTIFF sur GPU : contrôles Rasterio, CuPy et cuCIM

Une procédure par fenêtres peut combiner les entrées/sorties Rasterio avec des calculs sur GPU. Validez les bandes, les masques, le géoréférencement et les résultats avant de comparer les performances. Ce guide décrit ces contrôles, sans garantir une recette universelle pour GeoTIFF ou le décodage GPU.

Commencez par une lecture CPU, un calcul GPU éventuel et une écriture CPU. Comptez les transferts et les entrées/sorties : un GPU ne garantit pas une accélération. Évaluez le décodage cuCIM séparément, pour le format, le plugin et la version exacts.

1) Choisissez une image

Deux options d’environnement à valider :

A) Image déjà testée
Consignez son tag, son empreinte, ses exigences de pilote et ses paquets. N’utilisez pas un espace réservé RAPIDS 24.xx comme image installable.

B) Environnement reproductible
Choisissez des versions compatibles de Rasterio/GDAL et CuPy ; ajoutez cuCIM seulement pour le décodage validé séparément.

Conservez les dépendances verrouillées et vérifiez un petit jeu d’entrées/sorties avant les fichiers réels. Un import réussi ne démontre ni la prise en charge du codec, ni l’exécution GPU, ni la justesse géospatiale.

Vérifiez l’attribution du GPU et les capacités du pilote. Ces paramètres NVIDIA dépendent de la configuration hôte et n’attribuent pas de GPU :

• NVIDIA_VISIBLE_DEVICES=all
• NVIDIA_DRIVER_CAPABILITIES=compute,utility

Vérification dans le conteneur :

nvidia-smi


2) Évaluer les GeoTIFF optimisés pour le cloud (COG)

Les COG utilisent des tuiles internes et des niveaux d’aperçu pour la lecture par fenêtres. Choisissez une organisation en blocs et une compression prises en charge par votre lecteur, puis mesurez les E/S sur des fichiers représentatifs. Conservez les originaux jusqu’à validation des données converties, des masques et du géoréférencement.

Préparer et valider votre calcul GPU

Vérifiez la configuration disponible et la compatibilité logicielle avant le lancement. Comparez les résultats à une référence et sauvegardez vos entrées et sorties hors de l’instance.

Try Compute now

3) Schéma A : lecture CPU → calcul GPU → écriture CPU

Ce schéma s’applique aux entrées lisibles par votre version de Rasterio/GDAL. Préservez explicitement le géoréférencement et validez la sortie ; copier un profil ne conserve pas à lui seul le sens des bandes ni tous les masques.

Contrôles NDVI pour les bandes rouge et proche infrarouge

Identifiez les bandes rouge et proche infrarouge dans la documentation du jeu de données, sans supposer des numéros fixes. Appliquez la calibration requise et lisez le masque de validité de chaque bande. Calculez (PIR − rouge) / (PIR + rouge) seulement si les deux entrées sont valides et le dénominateur non nul. Préservez les pixels invalides. Écrivez un nouveau fichier et comparez valeurs, masques, projection, transformation et dimensions à une référence CPU.

Validation de la sortie

• Utilisez la gestion des masques de Rasterio et un profil de sortie explicite. Conserver projection et transformation est nécessaire, mais ne valide pas à lui seul une bande dérivée.
• Prévoyez la mémoire des fenêtres, masques, tableaux convertis, résultats intermédiaires et tampons. Une seule fenêtre peut encore dépasser la capacité du GPU.
• Les entrées compressées nécessitent un codec pris en charge par la version de Rasterio/GDAL ; src.read () lit et décompresse les données demandées.

4) Évaluer séparément le décodage cuCIM

Consultez la documentation des formats et plugins cuCIM. La prise en charge d’un TIFF RGB tuilé ne démontre pas celle de tout GeoTIFF multispectral. Le comportement dépend de la version et du plugin.

Avant d’adopter cuCIM, testez un fichier connu et inspectez dimensions, canaux, type et périphérique de sortie avec l’API correspondant à la version installée. Ne supposez ni que le quatrième canal est le proche infrarouge ni qu’une lecture par défaut renvoie de la mémoire GPU. Comparez valeurs et masques à Rasterio avant tout calcul NDVI.

Mises en garde

• Vérifiez le sens des canaux et l’organisation du tableau avec les métadonnées et un test connu ; changer l’indexation ne recrée pas une bande spectrale absente.
• Si le décodage n’est pas pris en charge ou diffère de la référence, arrêtez cette voie et utilisez la procédure Rasterio validée. N’acceptez pas silencieusement une autre organisation des canaux.

5) Reprojection (restez simple)

Choisissez une projection, une grille et un rééchantillonnage adaptés. Une vue virtuelle effectue la reprojection lors de la lecture ; sa création ne produit pas à elle seule un raster reprojeté.

Utilisez WarpedVRT avec une gestion explicite des valeurs invalides et un rééchantillonnage choisi. Validez grille et masques sur une petite région, fermez les jeux de données, puis ajoutez les calculs GPU. N’appliquez pas systématiquement une interpolation bilinéaire aux données catégorielles.

Pourquoi cette approche

• Rasterio/GDAL assure les transformations de coordonnées et le rééchantillonnage ; validez les réglages et les résultats pour vos données.
• Mesurez si le calcul GPU fait gagner du temps en incluant reprojection, transferts et écriture.

6) Conseils sur les performances et la VRAM

• Utilisez si possible des fenêtres adaptées aux blocs. Vérifiez l’organisation des bandes utiles et limitez les fenêtres au budget mémoire.
• Choisissez le type numérique après vérification de la précision et des plages de valeurs requises.
• Commencez avec une seule fenêtre en cours et augmentez la concurrence après mesure de la mémoire maximale et vérification des résultats.
• Évitez la surcharge de Python par tuile en regroupant les fenêtres et en utilisant des boucles simples.
• Écrivez des fichiers moins nombreux et plus volumineux (ou COG avec tuilage interne) pour réduire la surcharge des métadonnées.

7) Mesure des performances et calcul des coûts

Consignez format, bandes, calibration, masques, grille, codecs, versions, choix GPU/plugin et contrôles de sortie. Chronométrez lecture, transfert, calcul et écriture séparément ; indiquez durée totale et mémoire maximale.

Coût par 100 Go traités

Pour un volume traité non nul, coût normalisé pour 100 Go = coût total mesuré × 100 / Go traités. Précisez s’il s’agit des entrées compressées ou des données décodées et comptez les échecs dans la comparaison.

8) Résolution des problèmes

Mémoire GPU épuisée
Réduisez la taille ou le nombre de fenêtres simultanées. Libérez les tableaux inutiles ; l’API publique du pool CuPy peut libérer des blocs en cache inutilisés, pas les tableaux encore actifs. Validez toute modification de précision.

Résultats inattendus
Vérifiez l’ordre et le sens des bandes, ainsi que les masques de validité. Conservez dans la sortie le caractère invalide des pixels nodata.

Lectures lentes
Vérifiez stockage, compression et organisation en blocs. Mesurez les performances d’une conversion COG représentative avant de l’appliquer au jeu complet ; elle ne garantit pas à elle seule des lectures plus rapides.

Erreurs cuCIM
Revenez au schéma A et consignez les caractéristiques de création du fichier avant d’évaluer une conversion.

Relevé de méthode

Conservez l’environnement exact, les empreintes des entrées, les bandes, la calibration, les masques, la grille cible, le rééchantillonnage, le profil de sortie et les comparaisons. Avec cuCIM, consignez le périphérique observé et la version du plugin. Cette liste n’est pas un fichier YAML exécutable.

Lecture associée

• Modélisation scientifique sur les GPU cloud : ce qui fonctionne et ce qui ne fonctionne pas

Essayez Compute dès aujourd'hui

Les modèles personnalisés réutilisent une configuration testée. Vérifiez séparément la compatibilité et la capacité disponible. Sauvegardez les données hors de l’instance et consultez les conditions actuelles de redémarrage et de conservation avant l’arrêt.

‍