Hi Jeremy and Even,
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.
If I omit the mask, then I don’t see any bigtiff messages with -co BIGTIFF=NO.
If I include the mask band (change -b 4 t
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
Hello,
I'm using *.vrt file that is built atop of COG rasters with internal mask
(PER_DATASET) + external overview file *.vrt.ovr.
These files are stored on Azure Blob Storage and I get access to them using
/vsiaz scheme.
I've found out that when I read data from this VRT GDAL does few requests
to
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
Just wanted to follow up on this because I didn't want to leave the impression
that the issue was resolved, or limited to jpeg compression. It seems to be an
issue with writing the internal mask band.
When I create a mask band in a large lzw-compressed or jpeg-compressed tif
using the COG drive
Hays,
GCPsToGeoTransform() is not used directly by gdalwarp (although it should
likely be
equivalent to running -order 1 polynomial), but by other code (OZI .map
exporting, .tab
exporting)
You rather want to use the gdal.Transformer() API which is tested in
https://github.com/OSGeo/gdal/blob/
