Hi Andy,
On Wed, Apr 22, 2020 at 8:33 AM Ritchie, Andrew C wrote:
>
>
> Sorry I should’ve run more tests to clarify the situation re BIGTIFFs. It
> looks like gdal_translate honors -co BIGTIFF=NO for the raster but not the
> mask.
>
What's the output size of your COG when it successful complete
Palmer
Sent: Tuesday, April 21, 2020 2:57 PM
To: Even Rouault
Cc: Ritchie, Andrew C ; gdal-dev@lists.osgeo.org
Subject: [EXTERNAL] Re: [gdal-dev] gdal_translate (3.1.0dev) "never" finishes
on large jpeg cogs... REALLLLLY long time to unload.
Hi Andrew,
On Wed, Apr 22, 2020 at 6:11 AM Ev
Hi Andrew,
On Wed, Apr 22, 2020 at 6:11 AM Even Rouault
wrote:
> Andrew,
>
>
>
> > When I create a mask band in a large lzw-compressed or jpeg-compressed
> tif
>
> > using the COG driver it dramatically increases processing time over
> writing
>
> > RGBA (hours instead of minutes), so the issue
Andrew,
> When I create a mask band in a large lzw-compressed or jpeg-compressed tif
> using the COG driver it dramatically increases processing time over writing
> RGBA (hours instead of minutes), so the issue is not jpeg compression, it's
> the creation of the mask band. Steps to reproduce:
The
020 4:38 AM
To: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Cc: Ritchie, Andrew C mailto:aritc...@usgs.gov>>
Subject: [EXTERNAL] Re: [gdal-dev] gdal_translate (3.1.0dev) "never" finishes
on large jpeg cogs... REALY long time to unload.
Andrew,
Has your so
Andrew,
Has your source raster an alpha band ? That could explain the difference
since it isn't possible to directly create a YCbCrA JPEG compressed file, but
internally a mask band must be created. However I wouldn't anticipate such
a huge difference in performance between compression schemes.
I've been working in the gdal-dev-env (version 3.1.0, installed around
mid-December) on OSGeo4w (mostly because it's faster than making COGs using the
GTIFF driver) on large (e.g. 102600x91100) orthophoto rasters, generating VRTs,
TIFFs and COGs.
While I can do LZW, DEFLATE, and uncompressed ju
