[gdal-dev] Creating Cloud Optimized GeoTIFFs

[Even Rouault]

On mardi 14 novembre 2017 14:20:58 CET Kurt Schwehr wrote:
> Hi Even,
> 
> I have some follow up questions on Cloud Optimized GeoTIFFs:

The main constraint of C.O.G is that all the IFD definitions are at the beginning of the file, to 
avoid seeking at various points in it. Other parameters are pretty much unspecified.

> 
> * Is there a preferred/better INTERLEAVE if there is more than one band?

Depends on access patterns. If as soon as you process one pixel you need to access the value 
for all bands, then INTERLEAVE=PIXEL is better, and it will result in smaller sizes of 
StripOffsets/TileOffsets and StripByteCount/TileByteCount arrays

> * Is there a preferred tile blocksize?  You have 512 in your examples.  Are
> there any major trade offs between using 128, 256, 512, or 1024 for x and y
> block sizes?

Too small blocksizes will result in larger ...Offsets and ...ByteCount arrays. 

> * Should tiles be square?  Does it matter?

No

> * Is it better to skip tiling for small images?  If so, at what threshold
> do you think the switch should happen?  1024?

I'm not sure if that has an importance. But it is not wise to have an image whose one 
dimension is larger than the corresponding block dimension (as blocks are not truncated)

> * Is DEFLATE preferred for compression type over LZW for lossless
> compression?

Unspecified. DEFLATE is more CPU intensive, but if network times are the limiting factor, it is 
worth as more eficient

> * If the writer isn't constrained by compute power, are there preferred
> ZLEVEL and PREDICTOR values?  Is there a time cost for decompressing
> ZLEVEL=9 over 1?

PREDICTOR has neglectable CPU inflence (just a add/diff on integer values), but will not 
always result in smaller file sizes. Depends on the dataset

If I trust https://github.com/inikep/lzbench , the time cost for decompression for Deflate/Zlib 
doesn't seem to vary much with ZLEVEL. So the higher the better.
I don't know for LZW.

> 
> I'm a little confused by this code from validate_cloud_optimized_geotiff.py:
> 
>     if main_band.XSize >= 512 or main_band.YSize >= 512:
>         if check_tiled:
>             block_size = main_band.GetBlockSize()
>             if block_size[0] == main_band.XSize and block_size[0] > 1024:
>                 errors += ["The file is greater than 512xH or Wx512," +
>                            "but is not tiled"]
> 
> Will the above correctly fail an image that is (say) 256x2048 if it is not
> tiled?

No, it will pass this test. Since in that case block_size[0] == xsize == 256.
But for such a narrow image, it should probably warn if it is not tiled, as the number of strips, 
if letting to default strip height, will be larger than really necessary.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171115/9af81de4/attachment-0001.html>