[gdal-dev] About COG with multiple bands

[Javier Jimenez Shaw]

Thanks for the explanation and the link. I thought that the pixel
interleaving was defined in COG standard, but now I see it is only in GDAL
(so far).
Definitely depending on the use case, pixel or band interleaving is more
useful (as already commented on the issue you linked). I am not sure if the
COG readers are prepared for band interleave.

Cheers,
Javier.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Mon, 2 May 2022 at 10:09, Even Rouault <even.rouault at spatialys.com>
wrote:

> Javier,
>
> up to now, GDAL has restricted the COG definition to pixel interleaved
> organization, a bit artificially admittedly. This issue was recorded in
> https://github.com/opengeospatial/CloudOptimizedGeoTIFF/issues/3 .
> There's no way to efficiently extract a subset of bands with pixel
> interleaved organization.
>
> Even
> Le 01/05/2022 à 11:10, Javier Jimenez Shaw a écrit :
>
> Hi
>
> In the event "Cloud Native Geospatial" Chris mentioned that a COG file
> allows to extract just a few bands. For instance, from a satellite image
> with 12 bands, you could extract only red, green and blue, not needing to
> download all the bands. In this example it would be a reduction factor of 4.
>
> If I understand correctly from https://gdal.org/drivers/raster/cog.html
> "Pixel interleaving for multi-band dataset" the optimization mentioned
> above could not be possible. Am I right? Is there any efficient way to read
> just one band?
>
> Thanks,
> Javier.
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
> Entre dos pensamientos racionales
> hay infinitos pensamientos irracionales.
>
>
> _______________________________________________
> gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220502/6937ad97/attachment.htm>