[gdal-dev] Creating Cloud Optimized GeoTIFFs

[Kurt Schwehr]

Thanks Even for the feedback.  There have be a few offline discussions
going on and Even added some notes to the document on Trac:

https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF?action=diff&version=11
<https://www.google.com/url?sa=D&q=https%3A%2F%2Ftrac.osgeo.org%2Fgdal%2Fwiki%2FCloudOptimizedGeoTIFF%3Faction%3Ddiff%26version%3D11>

This stems from me switching Earth Engine from LZW to DEFLATE when
exporting GeoTIFFs (and I added tiling).  We have a report from a user that
ENVI 5.4 (and 5.1) Classic can't read the resulting images but QGIS &
ArcGIS can.  I'm reverting exports back to LZW compression.

On Wed, Nov 15, 2017 at 6:02 AM, Even Rouault <even.rouault at spatialys.com>
wrote:

> 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
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171210/f625a13e/attachment.html>