[COG] COG performance best practices?

[Seth Fitzsimmons]

>
> > * 4-band, 8-bit sources are assumed to be RGBA; band 4 (if present) is
> > assumed to be an alpha channel and is extracted as the mask.
>
> This can be dangerous guessing. Why not checking the band color
> interpretation
> (or ExtraSample in TIFF parlance) ?
>

Agreed. That's been a TODO, but I haven't gotten to it yet.


> For people not too much concerned about interoperability and using recent
> GDAL
> + libtiff (recent libtiff here means a checkout from git, or using the
> internal libtiff copy in GDAL sources), I'd suggest using ZSTD, which will
> save a lot of CPU time for the same compression rate as DEFLATE.
>

The GDAL Docker image at quay.io/mojodna/gdal:v2.3.0 includes ZSTD support,
if anyone wants to experiment with it (along with nghttp for HTTP/2 support
and libjpeg-turbo, to take advantage of decoding optimizations).


> > I've compared data from Planet with re-transcoded sources using this
> > pipeline; Planet's compression ratios are better, potentially because
> they
> > use LZW rather than DEFLATE (and potentially a higher ZLEVEL; though I
> just
> > changed that in marblecutter-tools).
>
> That would be news to me that LZW is better than DEFLATE. To compare
> apples to
> apples, you should make sure to use the same settings of ZLEVEL and
> PREDICTOR.
> DEFLATE is supposed to be more efficient (compression-wise) than LZW due
> to
> the extra stage of Huffman compression.
> For what I know, the use of LZW is essentially governed by the need of
> better
> interoperability since there are commercial software not able to consume
> DEFLATE compressed TIFF.


 I'll check this again; it's probably due to ZLEVEL (I was using 6; I'm
guessing Planet has it cranked up to 9).

seth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/cog/attachments/20180612/3a6ae85f/attachment.html>