<div dir="ltr">Dear gdal-dev team,
<div>
<div><br>
</div>
<div>we have to build a mosaic for 350 aerial images. These images are
gray images and have an alpha band. The avg size of each images is
24000x24000. The size of final mosaic would be 1676843x1441203. The
coordinate system of input images and final mosaic
is EPSG:25832</div><span class="gmail-im">
<div><br>
</div>
<div>First approach: virtual mosaic, gdal_translate, gdaladdo</div>
</span><div>first built a virtual mosaic for all input images with the command</div><span class="gmail-im">
<div>```gdalbuildvrt virtualmosaic.vrt ./*.tif```</div>
<div>This process was fast</div>
<div><br>
</div>
<div><span style="color:rgb(0,0,0)">``` gdal_translate virtualmosaic.vrt
mosaic.tif -ot Byte -of GTiff -co TILED=YES -co COMPRESS=JPEG -co
BIGTIFF=YES -a_srs EPSG:25832```<br>
</span></div>
</span><div><span style="color:rgb(0,0,0)">This process took almost one and a half days<br>
</span></div><span class="gmail-im">
<div><span style="color:rgb(0,0,0)"><br>
</span></div>
<div><span style="color:rgb(0,0,0)"></span></div>
<div><span style="color:rgb(0,0,0)">```gdaladdo -r average --config
COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW MINISBLACK --config
INTERLEAVE_OVERVIEW PIXEL --config GDAL_TIFF_OVER_BLOCKSIZE 256
--config BIGTIFF_OVERVIEW YES mosaic.tif 2 4 8 16 32
64 128 256 512 1024 2048 4096 8192```<br>
</span></div>
</span><div>This was taking way too much time. After three weeks of
processing, it did not even showed any progress on terminal. The mosaic
image size is increasing very slowly (it increased 40 kb in three
weeks). We checked htop. It was using less than 2 percent
of cpu processing. Most of the time the process status id D in red
color.</div>
<div>
<div>
<div><div><img src="cid:ii_jo5kkqy11" alt="image.png" width="545" height="110"><br></div></div></div></div></div>
<div><br>
</div>
<div>This process was taking too much time so we tried the second approach.</div>
<div><br>
</div>
<div>Second approach: The idea is to build a mosaic with gdalwarp and build the overviews with gdaladdo</div><span class="gmail-im">
<div>mosaic command<br>
</div>
<div>```gdalwarp -of GTiff -co COMPRESS=JPEG -co TILED=YES -co BIGTIFF=YES images_path/*.tif image_path/mosaic.tif```</div>
</span><div>This process was too slow. It was taking around 30 hours to
merge one image. So we thought it would take a long time merge 350
images and build overviews so we stopped there.<br>
</div>
<div><br>
</div>
<div>Third approach: We divided all images into 8 sets. First we
mosaiced neighborhood sets using gdalwarp. This process was fast. We
followed same way for next 4 sets. Finally we mosaiced all images with
gdalwarp in a few days. Then we started building overviews
with gdaladdo. Again building overviews was very slow.</div>
<div><br>
</div>
<div>We tried with -multi option, increasing the cache memory --config GDAL_CACHEMAX xxx and -WM xxx but nothing helped us.</div>
<div><br>
</div>
<div>Our first and second approach worked well when we mosaiced a few
images or the mosaic extent was small but it is taking too much time to
create mosaic of a large extent.</div>
<div><br>
</div>
<div>We have a quite powerful processing machine available which has 20 processing cores and 120 GB RAM.</div><span class="gmail-im">
<div><br>
</div>
<div>Finally our questions are:</div>
<div><br>
</div>
<div>1) Is there any flaw in our approach to build overviews?</div>
<div>2) If our approach is fine then why it is taking too much time to process and how we can increase the processing speed?</div>
</span><div>3) How can we run gdal commands using effectively multiple cores?<br clear="all">
</div>
<div>
<div><br>
</div>
<br>
<div dir="ltr" class="gmail-m_8882974187284237570x_m_-9176894354612893182gmail-m_-6742809519547570772m_-5639947182880004754gmail_signature">
<div dir="ltr">Best Regards,
<div>Pradeep Gulla </div></div></div></div></div>