Objective comparative results
| Test Configuration | DB size (after initial loading) | Final DB size (including Pyramid) | Loading | Pyramidizing | Exporting |
|---|---|---|---|---|---|
| Compression: NONE tile size: 512 x 512 | 10.8 GB | 10.9 GB | 17 mins 35 secs | 14 mins 52 secs | 11.90 secs |
| Compression: JPEG tile size: 256 x 256 | 269.0 MB | 275.0 MB | 16 mins 47 secs | 3 mins 30 secs | 10.20 secs |
| Compression: JPEG tile size: 512 x 512 | 220.0 MB | 225.0 MB | 15 mins 24 secs | 3 mins 34 secs | 10.63 secs |
| Compression: JPEG tile size: 1024 x 1024 | 212.0 MB | 217.0 MB | 15 mins 37 secs | 3 mins 37 secs | 12.10 secs |
| Compression: PNG tile size: 256 x 256 | 1.51 GB | 1.53 GB | 34 mins 8 secs | 7 mins 22 secs | 14.09 secs |
| Compression: PNG tile size: 512 x 512 | 1.46 GB | 1.49 GB | 34 mins 36 secs | 7 mins 59 secs | 16.50 secs |
| Compression: PNG tile size: 1024 x 1024 | 1.47 GB | 1.49 GB | 34 mins 30 secs | 7 mins 32 secs | 20.71 secs |
| Compression: WEBP (lossy) tile size: 512 x 512 | 130.0 MB | 136.1 MB | 72 mins 29 secs | 8 mins 22 secs | 20.59 secs |
| Compression: WEBP (lossless) tile size: 512 x 512 | 1.06 GB | 1.07 GB | 210 mins 49 secs | 8 mins 52 secs | 24.99 secs |
Conclusions and final remarks
Very short said: the venerable JPEG (born in 1986, about thirty years ago) clearly wins hands down:- it supports a very nice visual quality
- it ensures an excellent compression ratio, even when using the default quality setting (not at all aggressive).
- it's damn fast: most notably when using the amazing libjpeg-turbo (as in this test).
- it ensures an effective compression, thus saving a lot of storage space.
- it's a little bit slow when compressing, but after all it's not so bad; timings are still reasonably acceptable.
- it's only marginally slower then NONE and JPEG when decompressing; and this one surely is the more critical aspect to be considered.
- yes, it effectively reaches excellent compression ratios; but that's all the good we can say about it.
- it's intolerably slow during compression; and using the lossless option it becomes deadly sluggish.
- even more important: it's not at all a good performer when decompressing. Any other alternative is clearly more efficient.
- adding a multi-resolution Pyramid (default setting) has a very limited impact on the DB-file size.
- using different tile sizes seems to have only a very marginal impact.
- smaller tiles are slightly faster: that's not surprising, if we consider that bigger tiles obviously imposes the cost to read and decode many useless pixels not strictly required in order to export the output image.
- on the other hand bigger tiles ensure better compression ratios.
- all this considered the default setting 512 x 512 seems to be the optimal choice.
- JPEG compressed tiles are marginally faster than uncompressed tiles (NONE):
- this seems apparently contradictory, because after all JPEG surely imposes a extra computational cost in order to encode and decode.
- but performing I/O tasks too has its own costs; and the difference in sizes between the huge uncompresses tiles and the nimble JPEG compressed tiles is so impressive that at the end of the game JPEG clearly emerges as the faster performer.
1.b) RGB (8 bit) multi-resolution Pyramid
Input dataset
Exactly the same as above.Scope of this benchmark
- Stressing the monolithic multi-resolution Pyramid supporting an RGB 8bit Coverage.
- Objectively measuring sizes and timings on different configurations.
Methodology
- recycling the tm_jpeg.sqlite DB prepared in the previous benchmark (RGB UINT8, JPEG compressed, 512 x 512 tiles).
- then rebuilding from scratch a monolithic multi-resolution Pyramid using any alternative configuration supported by RasterLite2.
- finally about 200 JPEG images at different arbitrary resolutions were extracted for each Pyramid configuration being tested: all extracted images had the same size but different resolutions and geographic positions, and exactly the same identical requests were issued on behalf on each configuration.
The intended scope is the one to reply the typical actions performed by an user zooming in and out on different positions of a map.
Objective comparative results
| Test Configuration | Final DB size (including Pyramid) | Pyramidizing | Images Extraction |
|---|---|---|---|
| -lev 1 all Pyramid levels are physical no virtual levels are present | 302 MB | 12 mins 9 secs | 17.48 secs |
| -lev 2 Pyramid levels are alternatively one physical and one virtual | 239 MB | 5 mins 2 secs | 17.55 secs |
| -lev 3 every three Pyramid levels one is physical and the following two are virtual (exactly corresponding the the default setting) | 225 MB | 3 mins 32 secs | 19.13 secs |
Conclusions and final remarks
- Not at all surprisingly explicitly setting the -lev 3 option produces exactly the same effects as before, because this one is the implicit default setting.
- The time required to build a denser Pyramid obviously tends to significantly increase.
- And exactly the same is for the overall size.
- Rather surprisingly, a denser Pyramid performs only marginally better in the majority of cases being tested; once again the wonderful JPEG trade-off makes few small sized tiles to be decently good performers.
- Anyway a denser Pyramid will surely support a smoother navigation between different arbitrary resolutions; but the difference is not as big as we were expecting, at least in the case of RGB/JPEG tiles.
2.a) Digital Elevation Model (DEM) (DATAGRID: 1 band, signed integer 16bit sample)
Input dataset
We'll use in this benchmark the well known SRTM DEM, and more precisely we'll use a reprocessed void filled sample covering the Italian peninsula.This dataset consists in 9 ASCII Grids files and is freely available for download under the CC-BY-SA license terms:
- E005_N35.asc
- E005_N40.asc
- E005_N45.asc
- E010_N35.asc
- E010_N40.asc
- E010_N45.asc
- E015_N35.asc
- E015_N40.asc
- E015_N45.asc
Scope of this benchmark
- Stressing the different tile sizes, encodings and compressions supported by RasterLite2.
- Objectively measuring their comparative performances, considering both speed and space effectiveness.
Methodology
- a separate db-file was created and populated for each configuration being tested.
- then a monolithic multi-resolution Pyramid was added.
- finally 100 GeoTiff images at full resolution were extracted from each db-file: all exported images had different sizes and geographic positions, and exactly the same identical requests were issued on behalf on each db-file.
- as far as possible all timings have been measured under hot cache conditions.
Objective comparative results
| Test Configuration | DB size (after initial loading) | Final DB size (including Pyramid) | Loading | Pyramidizing | Exporting |
|---|---|---|---|---|---|
| Compression: NONE tile size: 256 x 256 | 659 MB | 662 MB | 5 mins 6 secs | 41.59 secs | 7.58 secs |
| Compression: NONE tile size: 512 x 512 | 656 MB | 660 MB | 5 mins 2 secs | 33.66 secs | 8.76 secs |
| Compression: NONE tile size: 1024 x 1024 | 656 MB | 660 MB | 4 mins 53 secs | 33.02 secs | 11.74 secs |
| Compression: DEFLATE tile size: 256 x 256 | 192 MB | 196 MB | 5 mins 31 secs | 19.80 secs | 10.01 secs |
| Compression: DEFLATE tile size: 512 x 512 | 190 MB | 194 MB | 5 mins 31 secs | 15.02 secs | 11.90 secs |
| Compression: DEFLATE tile size: 1024 x 1024 | 193 MB | 197 MB | 5 mins 10 secs | 18.02 secs | 15.12 secs |
| Compression: LZMA tile size: 256 x 256 | 147 MB | 151 MB | 13 mins 15 secs | 54.10 secs | 26.16 secs |
| Compression: LZMA tile size: 512 x 512 | 142 MB | 147 MB | 13 mins 28 secs | 46.05 secs | 32.83 secs |
| Compression: LZMA tile size: 1024 x 1024 | 141 MB | 146 MB | 12 mins 32 secs | 48.10 secs | 48.09 secs |
Conclusions and final remarks
All compression algorithms (DEFLATE and LZMA) tested in this benchmark are of the lossless type, so any possible quality difference is certainly excluded. No data information loss will never be possible. So the unique interesting variables to be compared are size and time.There is no real difference in measured timings between NONE and DEFLATE (NONE is actually faster, but the difference isn't an impressive one). Anyway DEFLATE has an astonishing advantage in size; so all considered it's the clear winner of this comparison.
LZMA surely ensures an even better compression, but this is at the cost of a remarkable slowness; and the really bad new is in that it's noticeably slow even while decompressing. This definitely makes LZMA to be a discouraged option, except may be in the few cases when saving even the last possible storage bit has a capital relevance.
Few interesting details worth to be noted:
- adding a multi-resolution Pyramid (default setting) has a very limited impact on the DB-file size.
- using different tile sizes seems to have only a very marginal impact; the default setting 512 x 512 seems to be to optimal choice.
2.b) DEM (INT16) multi-resolution Pyramid
Input dataset
Exactly the same as above.Scope of this benchmark
- Stressing the monolithic multi-resolution Pyramid supporting a DATAGRID INT16 Coverage.
- Objectively measuring sizes and timings on different configurations.
- Objectively measuring the timings required to apply Styling rules (SLD/SE RasterSymbolizer).
Methodology
- recycling the srtm_deflate.sqlite DB prepared in the previous benchmark (DATAGRID INT16, DEFLATE compressed, 512 x 512 tiles).
- then rebuilding from scratch a monolithic multi-resolution Pyramid using any alternative configuration supported by RasterLite2.
- finally about 150 JPEG images at different arbitrary resolutions and applying different Styling rules were extracted for each Pyramid configuration being tested: all extracted images had the same size but different resolutions and geographic positions, and exactly the same identical requests were issued on behalf on each configuration.
The intended scope is the one to reply the typical actions performed by an user zooming in and out on different positions of a map.
 |
 |
 | ||
| default mapping elevations to grayscale |
srtm_plus mapping elevations to false-colors |
srtm_plus_ShRel_100 mapping elevations to false-colors and applying shaded relief |
Objective comparative results
| Test Configuration | Final DB size (including Pyramid) | Pyramidizing | Styling: default | Styling: color rules | Styling: shaded relief |
|---|---|---|---|---|---|
| -lev 1 all Pyramid levels are physical no virtual levels are present | 260 MB | 48.66 secs | 11.07 secs | 14.00 secs | 1 min 5 secs |
| -lev 2 Pyramid levels are alternatively one physical and one virtual | 206 MB | 16.50 secs | 11.21 secs | 14.99 secs | 1 min 6 secs |
| -lev 3 every three Pyramid levels one is physical and the following two are virtual (exactly corresponding the the default setting) | 194 MB | 10.48 secs | 12.02 secs | 15.90 secs | 1 min 8 secs |
Conclusions and final remarks
- Explicitly setting the -lev 3 option produces exactly the same effects as before, because this corresponds to the default setting.
- The time required to build a denser Pyramid obviously tends to significantly increase, and exactly the same is for the overall size.
- Rather surprisingly, a denser Pyramid performs only marginally better in the majority of cases being tested.
- Anyway a denser Pyramid will surely support a smoother navigation between different arbitrary resolutions; but the average difference in timings is not as big as we were expecting.
- Applying a rendering Style based on false-color rules doesn't seem to imply any relevant cost (i.e. it's an efficient process).
- Anyway applying a rendering Style requiring shaded relief certainly is a more demanding task, and the corresponding timings are significantly slower.
The good new is in that all DEM-rendering related algorithms could be rather easily implemented by adopting multi-threaded parallel processing; and this advanced option will be surely supported by some future version of RasterLite2.
3.a) Panchromatic Satellite Imagery (GRAYSCALE: 1 band, unsigned integer 16bit sample)
Input dataset
We'll use in this benchmark the well known Landsat 8 imagery only considering its high-resolution panchromatic band (B8: 15m / pixel). So we'll process a single Landsat8 scene:- LC81920292013183LGN00_B8.TIF
Scope of this benchmark
- Stressing the different encodings and compressions supported by RasterLite2.
- Objectively measuring their comparative performances, considering both speed and space effectiveness.
Methodology
- a separate db-file was created and populated for each configuration being tested.
- then a monolithic multi-resolution Pyramid was added.
- finally 120 GeoTiff images at full resolution were extracted from each db-file: all exported images had different sizes and geographic positions, and exactly the same identical requests were issued on behalf on each db-file.
- as far as possible all timings have been measured under hot cache conditions.
Objective comparative results
| Test Configuration | DB size (after initial loading) | Final DB size (including Pyramid) | Loading | Pyramidizing | Exporting |
|---|---|---|---|---|---|
| Compression: NONE tile size: 512 x 512 | 472 MB | 476 MB | 2 mins 26 secs | 7.40 secs | 12.16 secs |
| Compression: DEFLATE tile size: 512 x 512 | 268 MB | 272 MB | 2 mins 5 secs | 10.45 secs | 14.93 secs |
| Compression: LZMA tile size: 512 x 512 | 241 MB | 245 MB | 7 mins 20 secs | 1 min 2 secs | 44.32 secs |
Conclusions and final remarks
Same conclusions as in the previous benchmark: even in the case of Landsat8 panchromatic imagery DEFLATE ensures a noticeable storage saving at the cost of a very bland performance loss.LZMA definitely confirms its intrinsic slowness either when compressing and while decompressing. The storage saving it certainly ensures is too much expensive in computational terms to be really interesting.
3.b) Grayscale (UINT16) multi-resolution Pyramid
Input dataset
Exactly the same as above.Scope of this benchmark
- Stressing the monolithic multi-resolution Pyramid supporting a DATAGRID UINT16 Coverage.
- Objectively measuring sizes and timings on different configurations.
- Objectively measuring the timings required to apply Styling rules (SLD/SE RasterSymbolizer).
Methodology
- recycling the landsat_deflate.sqlite DB prepared in the previous benchmark (DATAGRID UINT16, DEFLATE compressed, 512 x 512 tiles).
- then rebuilding from scratch a monolithic multi-resolution Pyramid using any alternative configuration supported by RasterLite2.
- finally about 150 JPEG images at different arbitrary resolutions and applying different Styling rules (contrast enhancements) were extracted for each Pyramid configuration being tested: all extracted images had the same size but different resolutions and geographic positions, and exactly the same identical requests were issued on behalf on each configuration.
The intended scope is the one to reply the typical actions performed by an user zooming in and out on different positions of a map.
 |
 |
 |
 | |||
| default | gamma 2.5 | histogram | normalize |
Objective comparative results
| Test Configuration | Final DB size (including Pyramid) | Pyramidizing | Styling: default | Styling: gamma 2.5 | Styling: histogram | Styling: normalize |
|---|---|---|---|---|---|---|
| -lev 1 all Pyramid levels are physical no virtual levels are present | 357 MB | 55.33 secs | 9.96 secs | 10.09 secs | 10.06 secs | 10.07 secs |
| -lev 2 Pyramid levels are alternatively one physical and one virtual | 286 MB | 19.26 secs | 10.25 secs | 10.45 secs | 10.43 secs | 10.38 secs |
| -lev 3 every three Pyramid levels one is physical and the following two are virtual (exactly corresponding the the default setting) | 272 MB | 11.15 secs | 14.01 secs | 14.80 secs | 14.75 secs | 14.50 secs |
Conclusions and final remarks
- Exactly as we've already seen in any other previous benchmark the time required to build a denser Pyramid tends to significantly increase, and the same is for the overall size.
- The differences in timings required by applying different contrast enhancement algorithms are practically negligible. So systematically choosing the higher quality and better looking normalize algorithm doesn't imply any further computational cost.
4.a) RGB + IR Aerial Imagery (MULTIBAND: 4 bands, unsigned integer 8bit samples)
Input dataset
Aerial imagery supporting standard RGB bands plus an extra Near InfraRed (NIR) band is quickly becoming widespread in recent times.The extra NIR band allows visualizing false colors images, thus making an easier task differentiating and correctly recognizing the vegetation and the water bodies.
This specific kind of aerial imagery is a very popular option for many remote sensing projects related to agricultural activities.
In the current benchmark we'll use a NAIP quadrant freely distributed by Indiana University; and most precisely we'll download the following four GeoTIFF images:
- m_3808409_ne_16_1_20120607
- m_3808409_nw_16_1_20120607
- m_3808409_se_16_1_20120607
- m_3808409_sw_16_1_20120607
Scope of this benchmark
- Stressing the different encodings and compressions supported by RasterLite2.
- Objectively measuring their comparative performances, considering both speed and space effectiveness.
Methodology
- a separate db-file was created and populated for each configuration being tested.
- then a monolithic multi-resolution Pyramid was added.
- finally 100 GeoTiff images at full resolution were extracted from each db-file: all exported images had different sizes and geographic positions, and exactly the same identical requests were issued on behalf on each db-file.
- as far as possible all timings have been measured under hot cache conditions.
Objective comparative results
| Test Configuration | DB size (after initial loading) | Final DB size (including Pyramid) | Loading | Pyramidizing | Exporting |
|---|---|---|---|---|---|
| Compression: NONE tile size: 512 x 512 | 788 MB | 797 MB | 1 mins 27 secs | 16.50 secs | 27.01 secs |
| Compression: DEFLATE tile size: 512 x 512 | 633 MB | 642 MB | 2 mins 10 secs | 25.38 secs | 34.21 secs |
| Compression: LZMA tile size: 512 x 512 | 556 MB | 565 MB | 11 mins 53 secs | 1 min 52 secs | 2 mins 17 secs |
Conclusions and final remarks
More or less we still continue noticing the same general trends already seen on the last two benchmarks. Anyway in this specific case both DEFLATE and LZMA are unable to reach high compression ratios as we were probably expecting; but there is very clear explanation for all this:- all lossless compression algorithms are basically intended to reduce any redundancy found in input data; and consequently:
- data presenting a rather poor internal variance and possibly containing many repeated sequences will be compressed in a very effective way.
- data presenting a very rich and highly dynamic internal variance will be compressed very poorly.
- Color photographies of natural subjects usually present an impressive internal variance; thus it's not at all surprising to discover that they couldn't be efficiently compressed by DEFLATE or LZMA.
Unhappily the alternative lossy compression algorithms specifically intended to support an efficient compression for photographic images (e.g. JPEG or WEBP) don't support multi-band imagery; so DEFLATE and LZMA still remain the unique available options.
4.b) MULTIBAND (UINT8, 4 bands) multi-resolution Pyramid
Input dataset
Exactly the same as above.Scope of this benchmark
- Stressing the monolithic multi-resolution Pyramid supporting a MULTIBAND (4 bands) UINT8 Coverage.
- Objectively measuring sizes and timings on different configurations.
- Objectively measuring the timings required to apply Styling rules (SLD/SE RasterSymbolizer).
Methodology
- recycling the indiana_deflate.sqlite DB prepared in the previous benchmark (MULTIBAND UINT8, DEFLATE compressed, 512 x 512 tiles).
- then rebuilding from scratch a monolithic multi-resolution Pyramid using any alternative configuration supported by RasterLite2.
- finally about 100 JPEG images at different arbitrary resolutions and applying different Styling rules (band selection) were extracted for each Pyramid configuration being tested: all extracted images had the same size but different resolutions and geographic positions, and exactly the same identical requests were issued on behalf on each configuration.
The intended scope is the one to reply the typical actions performed by an user zooming in and out on different positions of a map.
 |
 |
 |
 | |||
| default band #0 (Red) as grayscale |
RGB natural colors |
false colors NIR + R + G bands |
false colors G + R + NIR bands |
Objective comparative results
| Test Configuration | Final DB size (including Pyramid) | Pyramidizing | Styling: default | Styling: RGB | Styling: NIR+R+G | Styling: G+R+NIR |
|---|---|---|---|---|---|---|
| -lev 1 all Pyramid levels are physical no virtual levels are present | 819 MB | 1 min 26 secs | 14.88 secs | 17.00 secs | 17.12 secs | 17.14 secs |
| -lev 2 Pyramid levels are alternatively one physical and one virtual | 670 MB | 35.67 secs | 15.41 secs | 17.89 secs | 18.14 secs | 17.95 secs |
| -lev 3 every three Pyramid levels one is physical and the following two are virtual (exactly corresponding the the default setting) | 642 MB | 22.46 secs | 22.72 secs | 25.69 secs | 25.44 secs | 25.28 secs |
Conclusions and final remarks
- Exactly as we've already seen in any other previous benchmark the time required to build a denser Pyramid tends to significantly increase, and the same is for the overall size. Anyway in this specific case the poor compression ratio implies bigger sizes, and consequently longer times due to the obvious impact on the I/O sub-system.
- The differences in timings required by applying different band selections are negligible for any practical purpose.
Please note: the default test performs marginally faster simply because it handles just a single band instead of three.
5.a) 1-BIT topographical maps (MONOCHROME)
Input dataset
We'll use exactly the same GeoTIFF files we've already encountered in the trento-ctr tutorial.Scope of this benchmark
- Stressing the different encodings and compressions supported by RasterLite2.
- Objectively measuring their comparative performances, considering both speed and space effectiveness.
Methodology
- a separate db-file was created and populated for each configuration being tested.
- then a monolithic multi-resolution Pyramid was added.
- finally 120 GeoTiff images at full resolution were extracted from each db-file: all exported images had different sizes and geographic positions, and exactly the same identical requests were issued on behalf on each db-file.
- as far as possible all timings have been measured under hot cache conditions.
Objective comparative results
| Test Configuration | DB size (after initial loading) | Final DB size (including Pyramid) | Loading | Pyramidizing | Exporting |
|---|---|---|---|---|---|
| Compression: NONE tile size: 512 x 512 | 111 MB | 200 MB | 49.37 secs | 4 mins 1 sec | 7.58 secs |
| Compression: PNG tile size: 512 x 512 | 38.6 MB | 128 MB | 1 mins 10 secs | 4 mins 59 secs | 8.47 secs |
| Compression: FAX4 tile size: 512 x 512 | 29.8 MB | 119 MB | 56.16 secs | 4 mins 59 secs | 7.36 secs |
Conclusions and final remarks
1-bit MONOCHROME samples are rather exceptional under many aspects:- 8 pixels can be directly packed into a single byte; and this implies that even uncompressed tiles (NONE) will require a surprising limited storage amount.
- both PNG and FAX4 algorithms support good compression ratios, and are fast performers either while compressing and when decompressing.
Both supports very similar performances, difference are practically marginal; anyway the more specialized FAX4 (specifically intended for monochromatic tiles) is surely the best available option under any possible aspect. - the monolithic Pyramid in the specific case of 1-bit samples always requires a substantial storage amount. This is directly related to the very limited variance intrinsic in 1-bit; simple/naive downsampling (aka rescaling) algorithms in this case offer a really unpleasant and sacrificed visual quality.
A by far better visual quality is supported by RasterLite2 for rescaled images based on 1-bit samples; but this necessarily implies adopting more sophisticated algorithms based on interpolation. And in turn interpolated values imply scaling-up to Grayscale UINT8 samples, thus requiring many more storage space for any upper level of the multi-resolution Pyramid except the first one (corresponding to full resolution).
The following two figures will definitely clarify this critical point.
This first figure exactly corresponds to a rescaled 1-bit image produced by another sw tool adopting a simpler and unsophisticated downsampling algorithm.
As you can easily notice, the visual quality is indecently poor, and any fine grained detail has gone completely lost when rescaling; this one isn't a map, it simply is meaningless digital noise.
This second figure exactly corresponds to a rescaled 1-bit image produced by RasterLite2 by applying a more advanced algorithm based on halftone interpolated pixels (Grayscale: 256 shades of gray). The difference between the two alternative approaches is self-explanatory.
5.b) 1-BIT (MONOCHROME) multi-resolution Pyramid
Input dataset
Exactly the same as above.Scope of this benchmark
- Stressing the monolithic multi-resolution Pyramid supporting a MONOCHROME (1-BIT) Coverage.
- Objectively measuring sizes and timings on different configurations.
- Objectively measuring the timings required to apply Styling rules (SLD/SE RasterSymbolizer).
Methodology
- recycling the mono_fax4.sqlite DB prepared in the previous benchmark (MONOCHROME 1-BIT, FAX4 compressed, 512 x 512 tiles).
- then rebuilding from scratch a monolithic multi-resolution Pyramid using any alternative configuration supported by RasterLite2.
- finally about 100 JPEG images at different arbitrary resolutions and applying different Styling rules (re-coloring) were extracted for each Pyramid configuration being tested: all extracted images had the same size but different resolutions and geographic positions, and exactly the same identical requests were issued on behalf on each configuration.
The intended scope is the one to reply the typical actions performed by an user zooming in and out on different positions of a map.
 |
 | |
| default black and transparency |
re-colored red and transparency |
Objective comparative results
| Test Configuration | Final DB size (including Pyramid) | Pyramidizing | Styling: default | Styling: Red |
|---|---|---|---|---|
| -lev 1 all Pyramid levels are physical no virtual levels are present | 119 MB | 4 mins 50 secs | 10.79 secs | 16.02 secs |
| -lev 2 Pyramid levels are alternatively one physical and one virtual | 93.4 MB | 3 mins 36 secs | 11.65 secs | 18.42 secs |
| -lev 3 every three Pyramid levels one is physical and the following two are virtual (exactly corresponding the the default setting) | 86.2 MB | 3 mins 22 secs | 13.72 secs | 18.09 secs |
Conclusions and final remarks
- Please, pay close attention: in the case of 1-bit monochrome samples the default setting when building a monolithic Pyramid is -lev 1, and not -lev 3 as in any other different case.
This is because in this special case using virtual Pyramid level will impair the interpolation algorithm thus producing worst visual results; and RasterLite2 always attempts to preserve the best possible visual quality. - Anyway, exactly as we've already seen in any other previous benchmark the time required to build a denser Pyramid tends to significantly increase, and the same is for the overall size. Anyway in this specific case, due to intrinsic requirements of the hi-quality interpolated rescaled levels, the multi-resolution Pyramid will require paradoxically more storage space than the full resolution level itself.
- A clearly noticeable overhead is required when applying some re-colored style, but the implied computational cost seems to be fairly reasonable.
Back to RasterLite2 doc index Z 2e9c9627494548287876697415092890