<div dir="ltr"><div dir="ltr">Hi Andrew,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 22, 2020 at 6:11 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div style="font-family:monospace;font-size:9pt;font-weight:400;font-style:normal">
<p style="margin:0px;text-indent:0px">Andrew,</p>
<p style="margin:0px;text-indent:0px"> </p>
<p style="margin:0px;text-indent:0px">> When I create a mask band in a large lzw-compressed or jpeg-compressed tif</p>
<p style="margin:0px;text-indent:0px">> using the COG driver it dramatically increases processing time over writing</p>
<p style="margin:0px;text-indent:0px">> RGBA (hours instead of minutes), so the issue is not jpeg compression, it's</p>
<p style="margin:0px;text-indent:0px">> the creation of the mask band. Steps to reproduce:</p>
<p style="margin:0px;text-indent:0px"> </p>
<p style="margin:0px;text-indent:0px">There's clearly some complications & overhead internally to be able to deal with non-alpha mask bands. I wouldn't have expected it to be as large as you observed though. Would require deeper investigation to understand why that causes such performance difference.</p></div></blockquote><div><br></div><div>I would also be interested to see what steps you have taken to process the COG. We have used the driver to create both WEBP, and JPEG (including the 1bit transparency mask) COGs up to 200GB in size. It did take a couple of days on a mid-sized AWS EC2 instance but completed OK. Note the most of the time is taken up with the overview generation on large COGs. This will hopefully improve soon with multi-threaded overview computation likely coming to GDAL.<br></div><div><br></div><div>Warm Regards,</div><div>Jeremy</div></div></div>