GeoTIFF GPU processing: Rasterio, CuPy and cuCIM checks

A tiled raster workflow can combine Rasterio I/O with GPU array processing. Validate band meaning, masks, georeferencing and numerical results before comparing performance. This guide describes those checks; it does not certify a universal GeoTIFF or GPU-decoding recipe.

Start with CPU reading, optional GPU computation and CPU writing. Include transfers and I/O in the benchmark: a GPU does not guarantee a speedup. Evaluate cuCIM decoding separately for the exact format, plugin and version.

1) Pick an image

Two environment options to validate:

A) Existing tested image
Record its registry tag, digest, driver requirements and package versions. Do not use an unresolved RAPIDS 24.xx image placeholder.

B) Reproducible environment
Choose compatible Rasterio/GDAL and CuPy versions; add cuCIM only for the separately validated decoding path.

Keep a dependency lock and verify a small input/output fixture before processing real files. A successful import does not establish codec support, GPU execution or correct geospatial output.

Check the runtime’s GPU assignment and driver capabilities. These NVIDIA settings depend on the host configuration and do not allocate a GPU:

• NVIDIA_VISIBLE_DEVICES=all
• NVIDIA_DRIVER_CAPABILITIES=compute,utility

Sanity check inside the container:

nvidia-smi


2) Evaluate Cloud-Optimized GeoTIFFs (COGs)

COGs use internal tiles and overview levels for windowed access. Choose a block layout and compression supported by your reader, then measure I/O on representative files. Preserve the originals until the converted data, masks and georeferencing are validated.

Prepare and validate your GPU workload

Check the available configuration and software compatibility before launching. Measure results against a reference and keep an independent backup of your inputs and outputs.

Try Compute now

3) Pattern A: CPU read → GPU compute → CPU write

This pattern applies to inputs your Rasterio/GDAL build can read. Preserve georeferencing explicitly and validate the output; copying a profile alone does not preserve all band semantics or masks.

NDVI workflow checks for red and near-infrared bands

Identify the red and near-infrared bands from the dataset specification, not fixed band numbers. Apply required scale/offset calibration and read each band's validity mask. Compute (NIR − red) / (NIR + red) only where both inputs are valid and the denominator is nonzero. Keep invalid pixels invalid. Write to a new output, then compare valid values, masks, CRS, transform and dimensions against a CPU reference.

Output validation

• Use Rasterio’s mask handling and an explicit output profile. Retaining CRS and transform is necessary but not sufficient to validate a derived band.
• Budget memory for input windows, masks, converted arrays, intermediate results and output buffers. One window can still be too large for the selected GPU.
• Compressed inputs require codec support in the Rasterio/GDAL build; src.read() reads and decompresses the requested data.

4) Assess cuCIM decoding separately

Check cuCIM’s format and plugin documentation. Support for tiled RGB TIFF does not establish support for every multispectral GeoTIFF. Plugin behavior is version-dependent.

Before adopting a cuCIM path, test a known file and inspect its dimensions, channels, dtype and output device using the API for the installed version. Do not assume the fourth array channel is NIR or that a default region read returns GPU memory. Compare decoded values and masks with Rasterio before using the result in NDVI.

Caveats

• Verify channel meaning and array layout from metadata and a known fixture; changing the indexing alone cannot recover a missing spectral band.
• If decoding is unsupported or differs from the validated reference, stop that path and use the tested Rasterio workflow. Do not silently accept a different channel layout.

5) Reprojection (keep it simple)

Choose a target CRS, grid and resampling method appropriate to the data. A virtual warp performs reprojection when read; it does not materialize a completed warp just by creating the view.

Use WarpedVRT with explicit source/destination nodata behavior and a deliberate resampling method. Validate the target grid and masks on a small region, close all datasets, and only then add GPU calculations. Do not use bilinear interpolation indiscriminately for categorical data.

Why this approach

• You keep geodesy (CRS transforms, resampling kernels) in a battle‑tested library.
• Measure whether the GPU calculation saves time after including warp, transfers and output.

6) Performance & VRAM tips

• Use block-aware windows where practical. Check each relevant band’s block layout and keep window sizes within the memory budget.
• Choose a numeric type after checking required accuracy and valid-value ranges.
• Begin with one window in flight and increase concurrency only after measuring peak memory and correctness.
• Avoid per‑tile Python overhead by grouping windows and using simple loops.
• Write fewer, larger files (or COGs with internal tiling) to cut metadata overhead.

7) Self‑benchmark & cost math

Record input format, bands and calibration, masks, grid, codecs, software lock, GPU/plugin choices and output checks. Time reading, transfer, computation and writing separately; report end-to-end time and peak memory.

Cost per 100 GB processed

For a nonzero processed volume, normalized cost per 100 GB = total measured cost × 100 / processed GB. State whether GB refers to compressed input or decoded data, and include failed attempts when comparing workflows.

8) Troubleshooting

GPU memory exhausted
Use smaller windows or fewer concurrent windows. Release arrays no longer needed; CuPy’s public memory-pool API can release unused cached blocks, not live arrays. Do not change precision without checking accuracy.

Weird results
Mismatched bands or nodata handling. Check band order; propagate nodata to the output.

Slow reads
Check storage, compression and block layout. Benchmark a representative COG conversion before applying it to the dataset; conversion alone does not guarantee faster reads.

cuCIM errors
Fall back to Pattern A and log the file’s creation info for later conversion.

Methods record

Preserve the exact environment, input checksums, band mapping, calibration, masks, target grid, resampling, output profile and comparison results. Record measured device placement and plugin version if cuCIM is used. This is a checklist, not executable YAML.

Related reading

• Scientific modeling on cloud GPUs — what works, what doesn’t

Try Compute today

Use custom templates to reuse a tested container configuration. Check software compatibility and available capacity separately. Back up data outside the instance and check the current restart and retention conditions before stopping it.

‍