Add nvJPEG GPU acceleration for JPEG-compressed GeoTIFFs

[brendancol]

Author of Proposal: @brendan

Reason or problem

The geotiff package reads JPEG-compressed TIFFs (tag 7) via Pillow on CPU, but there's no GPU path. NVIDIA ships libnvjpeg.so in the CUDA toolkit for batch JPEG encode/decode on GPU. We have GPU acceleration for deflate/ZSTD (nvCOMP) and JPEG 2000 (nvJPEG2000), so JPEG is the odd one out.

JPEG is the most common lossy codec in existing GeoTIFFs (aerial orthophotos, Google Earth exports, etc.), so this would probably help more users than the J2K work did.

Proposal

Design:

Add nvJPEG GPU decode/encode for TIFF tag 7, following the nvJPEG2000 pattern:

1. _gpu_decode.py: _find_nvjpeg_lib() / _get_nvjpeg() lazy library discovery, _try_nvjpeg_batch_decode() and _nvjpeg_batch_encode() via ctypes
2. Hook into gpu_decode_tiles() for tag 7, try nvJPEG first, fall back to Pillow
3. Hook into gpu_compress_tiles() for tag 7, try nvJPEG first, fall back to Pillow
4. Wire JPEG into _compression_tag() in the writer so users can write_geotiff(data, path, compression='jpeg') (currently read-only, not writable via the public API)

Existing CPU Pillow path stays untouched. GPU path is optional.

Usage:

write_geotiff(data, "ortho.tif", compression="jpeg")
write_geotiff(cupy_data, "ortho.tif", compression="jpeg", gpu=True)  # nvJPEG
da = read_geotiff("ortho.tif", gpu=True)  # nvJPEG decode if available

Stakeholders and impacts

Anyone reading JPEG-compressed GeoTIFFs on GPU. Additive, no existing code paths affected.

Drawbacks

• JPEG is lossy only, not suitable for scientific data that needs exact roundtrips
• nvJPEG requires CUDA toolkit

Alternatives

Pillow CPU path already works. This is a speed improvement, not new functionality.

Unresolved questions

• Quality parameter: expose via write_geotiff or just default to 75?
• YCbCr vs RGB colorspace handling in the TIFF JPEG context