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.roua...@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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev