Open jakimowb opened 2 months ago
One thing that is not entirely clear to me for INTERLEAVE=BAND in a cloud optimized context is how to place tiles in the file I can see 2 alternatives:
Both could make sense, although I suppose first one would be slightly preferred and closer to what BSQ is. The second alternative would be a kind of BIL layout adapted for tiling.
Both options are valid choices, and selecting one rather than the other heavily depends on the predicted/prevalent access scenarios. I would recommend making this choice user selectable via a configuration option.
@cholmes @vincentsarago @joanma747 Do you expect some "disruption" of the COG ecosystem if GDAL would start writing multi-band COG files with INTERLEAVE=BAND ? (although that wouldn't be the default)
Would be interesting to see what this means in terms of average loading times for the following use-case:
- classic map visualization on different zoom levels, i.e. a small number of bands required for a single-band or 3-band combination.
Let's imagine that your request intersects 2 tiles in the horizontal direction (thus consecutive)
Let's imagine that your request intersects 2 tiles in the vertical direction (thus non-consecutive)
- extraction of single pixel profiles (same pixel coordinate but all band values).
- if using BSQ layout, then you need as many HTTP GET requests as they are bands
- if using "pseudo-BIL" layout, you need one single HTTP GET request In both cases, you will need to download the whole blocks for compressed data (for uncompressed data, you could in theory issue a multi-range GET request, but very few servers support that, in particular commercial cloud object storage services don't)
(all the above assumes a "smart" reader. I'm not totally sure that the GDAL driver has all those read optimizations in the multi-band case)
Feature description
Request
It is requested to enhance the COG driver by an option to create COG rasters with band interleave, i.e. an creation option
INTERLEAVE=BAND
, similar those existing in the GTiff driver.Problem
According to the OGC COG specification, COGs with multiple bands may be stored with pixel interleave (BIP) or band interleave (BSQ).
By now (GDAL 3.9.2), the COG driver supports BIP only. Unfortunatelly, COGs generated in this way for multiband datsets, e.g. hyperspectral satellite data with more than 100 bands, cannot be visualized smoothly. The loading times for block-by-block band information, e.g. to visualize them in QGIS, are simply too long.
Workaround
A current workaround to create BSQ COGs for such kind of raster data is to:
TILED=YES
andINTERLEAVE=BAND
osgeo_utils.samples.validate_cloud_optimized_geotiff
)How to reproduce
Additional context
No response