[gdal-dev] Question about strategy on building big mosaic

Even Rouault even.rouault at mines-paris.org
Thu May 29 11:45:48 PDT 2014


David,

If you have plenty of storage space, you could translate each JPEG2000 image 
to a tiled uncompressed geotiff. Ideally you would use tiles of size 128 to 
match with the block size of the VRT driver.
If storage space is an issue, yes you can try reversible JPEG2000 (although 
compression rate is not particuarly shiny with reversible compression), but 
make sure that the block size is 128 too.

If you have enough RAM, you should also make sure that GDAL_CACHEMAX is at 
least 128 * width_of_vrt_mosaic * 3 (if your images are RGB). And potentially 
* 2 as security margin.

Even

On Thursday 29 May 2014 08:33:36 David Fawcett wrote:
> I am working on a project where am creating (and re-creating) a large image
> from ~125 image tiles.  Each tile is a 5000x5000px jp2000 compressed image,
> with no internal tiles.
> 
> I have a vrt set up and I have merged them all together using
> gdal_translate, but it took ~20 hours to run on an admittedly old Macbook
> Pro.  Even explained that the large input tiles make it really inefficient
> for the OpenJPEG2000 driver to read the input images as part of the
> translate operation.
> 
> I am trying to figure out if it is a reasonable strategy to introduce an
> intermediate step where I create tiled copies of the input tiles.  At the
> same time, I don't want to decrease image quality with the intermediate
> step.
> 
> If I used -co REVERSABLE=YES, would I be able to end up with the same
> quality in my final output?
> 
> I realize that I will have to do the performance test to determine if it
> makes sense to add this intermediate step from a processing time
> standpoint, but does this sound like a reasonable approach?
> 
> Thanks,
> 
> David.
-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140529/01d27b2a/attachment.html>


More information about the gdal-dev mailing list