[gdal-dev] Creating Cloud Optimized GeoTIFFs

[Kurt Schwehr]

Hi Even,

I have some follow up questions on Cloud Optimized GeoTIFFs:

* Is there a preferred/better INTERLEAVE if there is more than one band?
* 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?
* Should tiles be square?  Does it matter?
* Is it better to skip tiling for small images?  If so, at what threshold
do you think the switch should happen?  1024?
* Is DEFLATE preferred for compression type over LZW for lossless
compression?
* 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?

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?

Thanks!
-kurt

On Wed, May 10, 2017 at 1:53 PM, Even Rouault <even.rouault at spatialys.com>
wrote:

> On mercredi 10 mai 2017 14:41:44 CEST Peter Schmitt wrote:
>
> > Hi,
>
> >
>
> > I ran into something confusing when using gdal-2.2.0 to generate Cloud
>
> > Optimized GeoTIFFs following the instructions at:
>
> > https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF
>
> >
>
> > Here's what I did:
>
> >
>
> > 1. Fetch an image:
>
> > env CPL_VSIL_CURL_ALLOWED_EXTENSIONS=tif GDAL_DISABLE_READDIR_ON_OPEN=
> YES
>
> > VSI_CACHE=TRUE gdal_translate
>
> > https://github.com/mapbox/rasterio/raw/master/tests/data/RGB.byte.tif
>
> > rgb_byte_jpg.tif -co TILED=YES -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR
>
> >
>
> > Not a cloud-optimized GeoTIFF as expected:
>
> >
>
> > validate_cloud_optimized_geotiff.py rgb_byte_jpg.tif
>
> > rgb_byte_jpg.tif is NOT a valid cloud optimized GeoTIFF : The file should
>
> > have overviews
>
> >
>
> >
>
> > 2. Add internal overviews:
>
> > gdaladdo -r average rgb_byte_jpg.tif 2 4 8 16 32
>
> >
>
> > validate_cloud_optimized_geotiff.py rgb_byte_jpg.tif
>
> >
>
> > rgb_byte_jpg.tif is NOT a valid cloud optimized GeoTIFF : The offset of
> the
>
> > first block of overview of index 3 should be after the one of the
> overview
>
> > of index 4
>
> >
>
> >
>
> > 3. Translate the image again copying source overviews added above.
>
> >
>
> > gdal_translate rgb_byte_jpg.tif rgb_byte_jpg_trans.tif -co TILED=YES -co
>
> > COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co COPY_SRC_OVERVIEWS=YES
>
> >
>
> > Now the image _is_ cloud-optimized.
>
> >
>
> > validate_cloud_optimized_geotiff.py rgb_byte_jpg_trans.tif
>
> > rgb_byte_jpg_trans.tif is a valid cloud optimized GeoTIFF
>
> >
>
> >
>
> > I expected the image to be "cloud optimized" at step 2. Why do I need an
>
> > additional translate?
>
>
>
> Peter,
>
>
>
> Because gdaladdo will add the overview IFD at the end of the file, whereas
> in the definition of cloud optimized GeoTIFF, they must be all at the
> beginning of the file so as to be efficiently fetchable. And that can only
> be done with gdal_translate -co COPY_SRC_OVERVIEWS=YES
>
> To avoid quality loss you should only use JPEG compression for the final
> gdal_translate stage.
>
>
>
> Even
>
>
>
>
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>



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