When using vrt to mosaic on the fly large collections of images, is it better to add overviews (pyramids) to the individual rasters or to the final .vrt, or both? (Where "better" means finding the balance point between using no more storage than necessary while still providing a smooth experience for using and browsing the final image.)
asked May 22, 2015 at 23:17
-
i want to ask what is the reason of using mosaic– luka tumbaCommented Jul 9, 2019 at 16:09
Add a comment
|
1 Answer
It depends mostly on which is the minimun scale to show your image layer.
Creating overviews for individual rasters is more flexible when you update your layer partially. Just delete old image and put a new image with overviews in place. If you have build overviews for the .vrt you must create it again after update. However, individual overviews do not work well in small scale. If your original images cover 10x10 km each and you want to show on screen an area of 100x100 km the system must open 100 individual files for reading the overviews. If you have created overviews for the .vrt there is only one file to open and it will be faster.
You can also use a hybrid model: build a few internal overview levels (2 4 8) and then create a new physical file from .vrt with pixel size of the next overview (16). Create internal overviews for the subsampled image and finally combine all together into a scale dependent group. When individual images are changed to newer ones the physical overview file often does not require updating because changes are not visible at small case anyway.
When it comes to the need of disk space, it is the the same in both cases. But remember to compress your overviews. With aerial images you can save more than 90% of disk space by compressing overviews with JPEG method and photometric interpretation.
As you put your question I would say that create compressed overviews for your .vrt. It takes the same amount of disk space and browsing experience will be good at any scale. Remember still what I wrote about updating.
-
the hybrid idea is very interesting! I'm curious about why a physical file at level-16. Does that offer something
gdaladdo foo.vrt 16 32 64doesn't? ...it also occurs to me: both tiled and vrt overviews might be wanted in instances where individual tiles are access as well as the virtual mosaic. Commented May 25, 2015 at 16:48 -
gdaladdo foo.vrt 16 32.64creates a physical file but if you didgdaladdo foo.vrt 2 4 8before you have already a foo.vrt.ovr file. Well, .ovr file is really just a tiff and you can rename it and build overview levels by hand with a new .vrt file that that is a bit complicated. Do you mean that you have foo_1234.tif in a virtual mosaic all_foo.vrt but some users might need to access that single tiff directly? Then you are right, no software can guess to take overviews from all_foo.vrt.ovr. Commented May 25, 2015 at 17:00 -
Oh, perhaps you meant to write 2 4 8 overviews for individual images and 16 32 64 ... for the vrt. Excellent idea indeed. Commented May 25, 2015 at 17:07
-
yes to the 2nd response, 2 4 8 for tiles and 16 32 64 for vrt. Commented May 25, 2015 at 18:54
-
The problem being discussed is one I am frequently trying to hack around and it is constantly a cause of agony. I have a huge amount of files arranged in folders of 10 km2. For each folder I generate a vrt and add overviews (2 4 8 16). I then aggregate the vrt-files in one (gdalbuildvrt aggreg.vrt *.vrt). Creating one overview for the aggreg.vrt (32 64 128 256) is a pain. I suspect that gdalbuildvrt goes directly to the source files instead of the already built ovr files... Is this correct? And if so: Is there a workaround?– user83648Commented Oct 2, 2016 at 19:15