Back to RasterLite2 doc index
RasterLite2 reference Benchmarks
1.a) Color Satellite/Aerial Orthophotos (RGB: 3 bands, unsigned integer 8bit sample)
Input dataset
We'll use in this benchmark the well known True Marble imagery in its 500m version. This dataset corresponds to a worldwide mosaic of many reprocessed cloud-free Landsat scenes. All the input GeoTIFFs are freely available for download under the CC-BY license terms:- TrueMarble.500m.21600x21600.A1.tif
- TrueMarble.500m.21600x21600.A2.tif
- TrueMarble.500m.21600x21600.B1.tif
- TrueMarble.500m.21600x21600.B2.tif
- TrueMarble.500m.21600x21600.C1.tif
- TrueMarble.500m.21600x21600.C2.tif
- TrueMarble.500m.21600x21600.D1.tif
- TrueMarble.500m.21600x21600.D2.tif
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 50 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.
$ rl2tool CREATE -db tm_png1024.sqlite -cov tm -smp UINT8 -pxl RGB \
-cpr PNG -srid 4326 -res 0.00416666666666667 -tlw 1024 -tlh 1024
$ rl2tool IMPORT -db tm_png1024.sqlite -cov tm -dir . -ext tif
$ rl2tool PYRAMIDIZE-MONOLITHIC -db tm_png1024.sqlite -cov tm
$ export "SPATIALITE_SECURITY=relaxed"
$ sqlite3 tm_png1024.sqlite <test.sql
$
--------------
SELECT RL2_WriteGeoTiff('tm', './img122.tif', 1024, 512, MakePoint(-61.5, 52), 0.004167, 0.004167, 0, 'JPEG');
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 | 11.0 GB | 10 mins 3 secs | 2 mins 57 secs | 9.12 secs |
| Compression: DEFLATE tile size: 256 x 256 | 1.49 GB | 1.52 GB | 16 mins 26 secs | 4 mins 9 secs | 9.01 secs |
| Compression: DEFLATE tile size: 512 x 512 | 1.46 GB | 1.50 GB | 15 mins 29 secs | 3 mins 47 secs | 9.28 secs |
| Compression: DEFLATE tile size: 1024 x 1024 | 1.48 GB | 1.51 GB | 15 mins 15 secs | 3 mins 54 secs | 11.95 secs |
| Compression: DEFLATE_NO tile size: 512 x 512 | 1.85 GB | 1.89 GB | 13 mins 14 secs | 3 mins 17 secs | 11.29 secs |
| Compression: PNG tile size: 256 x 256 | 1.51 GB | 1.54 GB | 21 mins 38 secs | 4 mins 42 secs | 10.60 secs |
| Compression: PNG tile size: 512 x 512 | 1.48 GB | 1.51 GB | 21 mins 15 secs | 4 mins 25 secs | 10.74 secs |
| Compression: PNG tile size: 1024 x 1024 | 1.47 GB | 1.50 GB | 21 mins 44 secs | 4 mins 28 secs | 13.52 secs |
| Compression: CHARLS tile size: 512 x 512 | 1.70 GB | 1.74 GB | 15 mins 14 secs | 6 mins 34 secs | 20.18 secs |
| Compression: LZMA tile size: 512 x 512 | 1.31 GB | 1.34 GB | 1 hour 17 mins 56 secs | 8 mins 23 secs | 20.91 secs |
| Compression: LZMA_NO tile size: 512 x 512 | 1.56 GB | 1.34 GB | 1 hour 15 mins 46 secs | 8 mins 59 secs | 24.62 secs |
| Compression: WEBP (lossless) tile size: 512 x 512 | 1.06 GB | 1.08 GB | 1 hour 16 mins 32 secs | 6 mins 58 secs | 18.0 secs |
| Compression: JPEG2000 (lossless) tile size: 512 x 512 | 1.37 GB | 1.40 GB | 55 mins 50 secs | 30 mins 34 secs | 1 min 28 secs |
| Compression: JPEG tile size: 256 x 256 | 270.0 MB | 276.0 MB | 10 mins 47 secs | 2 mins 50 secs | 7.50 secs |
| Compression: JPEG tile size: 512 x 512 | 220.0 MB | 226.0 MB | 9 mins 20 secs | 2 mins 32 secs | 6.95 secs |
| Compression: JPEG tile size: 1024 x 1024 | 212.0 MB | 217.0 MB | 8 mins 57 secs | 2 mins 33 secs | 7.53 secs |
| Compression: WEBP (lossy) tile size: 512 x 512 | 131.0 MB | 135.0 MB | 49 mins 27 secs | 7 mins 12 secs | 15.40 secs |
| Compression: JPEG2000 (lossy Q=5) tile size: 512 x 512 | 210.0 MB | 216.0 MB | 57 mins 5 secs | 16 mins 45 secs | 33.72 secs |
Conclusions and final remarks
We clearly have three homogeneous groups and each group presents its own distinctive overall pattern:- the uncompressed approach (NONE): this obviously requires the biggest storage amount but will require no extra overhead due to compression algorithms.
We can use this one as a common reference standard. - lossless compressions (DEFLATE, PNG, CharLS, LZMA, WebP and Jpeg2000):
all them achieve broadly similar compression ratios but there are interesting differences.
We note instead a very large dispersion in processing timings; some compression algorithms are reasonably fast whilst other are noticeably slow:- DEFLATE and PNG have very similar performances; this is not all surprising, because both them are based on the same basic compression method (i.e. LZ77).
It's surely interesting to note that they impose a very light compression overhead whilst the decompression is highly efficient. - CharLS in this specific test marks the worst compression ratio: it's nicely fast when compressing (same as DEFLATE) but it impose a sensible decompression overhead.
- LZMA and WebP are terribly slow when compressing; anyway they are reasonably efficient when decompressing. It's interesting to note that WebP marks the higher compression ratio immediately followed in second position by LZMA.
- Jpeg2000 is roughly similar to LZMA and WebP for what concerns compression ratio and compression speed; anyway it's intolerably slow when decompressing.
- Applying a Delta Filter to both DEFLATE and LZMA implies a noticeably better compression ratio.
- DEFLATE and PNG have very similar performances; this is not all surprising, because both them are based on the same basic compression method (i.e. LZ77).
- evaluating lossy codecs is more difficult because all them support adjustable compression ratios with decreasing quality;
so just comparing the compression ratios has very little meaning.
Anyway we can easily notice that their comparatice efficiency is widely dispersed:- JPEG clearly presents an astonishing speed (most notably in its recent Jpeg-turbo implementation, as in this test).
- WebP presents an absolutely decent decompression speed (not very different from the ones measured for the fastest lossless algorithms); unhappily it's terribly slow when compressing.
- Jpeg2000 is similar to WebP but it's deadly slow also when decompressing.
- 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_deflate512.sqlite DB prepared in the previous benchmark (RGB 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 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.
$ rl2tool DE-PYRAMIDIZE -db tm_deflate512.sqlite -cov tm
$ sqlite3 tm_deflate512.sqlite
sqlite> vacuum;
sqlite> .quit
$ rl2tool PYRAMIDIZE-MONOLITHIC -db tm_deflate512.sqlite -cov tm -lev 1
$ sqlite3 tm_jpeg.sqlite <test.sql
$
--------------
SELECT RL2_GetMapImage('tm', BuildCircleMBR(-81.5, 12, 0.75), 512, 512, 'default', 'image/jpeg');
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 | 2.04 GB | 14 mins 47 secs | 20.44 secs |
| -lev 2 Pyramid levels are alternatively one physical and one virtual | 1.60 GB | 6 mins 2 secs | 20.31 secs |
| -lev 3 every three Pyramid levels one is physical and the following two are virtual (exactly corresponding the the default setting) | 1.50 GB | 3 mins 58 secs | 29.77 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.
$ rl2tool CREATE -db srtm_lzma1024.sqlite -cov srtm -smp INT16 -pxl DATAGRID \
-cpr LZMA -srid 4326 -res 0.000833194467589 -nd -9999 -tlw 1024 -tlh 1024
$ rl2tool IMPORT -db srtm_lzma1024.sqlite -cov srtm -srid 4326 -dir . -ext asc
$ rl2tool PYRAMIDIZE-MONOLITHIC -db srtm_lzma1024.sqlite -cov srtm
$ export "SPATIALITE_SECURITY=relaxed"
$ sqlite3 srtm_lzma1024.sqlite <test.sql
$
--------------
SELECT RL2_WriteGeoTiff('srtm', './img86.tif', 1024, 1024, MakePoint(13.7, 37.6), 0.000833, 0.000833, 0, 'NONE');
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 | 670 MB | 3 mins 44 secs | 7.12 secs | 3.97 secs |
| Compression: NONE tile size: 512 x 512 | 656 MB | 669 MB | 3 mins 27 secs | 6.34 secs | 4.07 secs |
| Compression: NONE tile size: 1024 x 1024 | 656 MB | 678 MB | 3 mins 17 secs | 6.08 secs | 5.53 secs |
| Compression: DEFLATE tile size: 256 x 256 | 147 MB | 150 MB | 4 mins 04 secs | 10.68 secs | 4.77 secs |
| Compression: DEFLATE tile size: 512 x 512 | 143 MB | 146 MB | 4 mins 02 secs | 10.57 secs | 6.30 secs |
| Compression: DEFLATE tile size: 1024 x 1024 | 143 MB | 146 MB | 3 mins 51 secs | 10.65 secs | 9.95 secs |
| Compression: DEFLATE_NO tile size: 512 x 512 | 190 MB | 194 MB | 3 mins 58 secs | 8.19 secs | 8.58 secs |
| Compression: LZMA tile size: 256 x 256 | 123 MB | 126 MB | 9 mins 16 secs | 33.49 secs | 13.80 secs |
| Compression: LZMA tile size: 512 x 512 | 119 MB | 121 MB | 8 mins 52 secs | 31.20 secs | 18.42 secs |
| Compression: LZMA tile size: 1024 x 1024 | 118 MB | 120 MB | 9 mins 22 secs | 35.22 secs | 27.28 secs |
| Compression: LZMA_NO tile size: 512 x 512 | 143 MB | 146 MB | 8 mins 36 secs | 38.23 secs | 26.63 secs |
Conclusions and final remarks
Both 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.DEFLATE confirms to be a good performer; it always ensures intersting compression ratios and it's pretty fast.
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.
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.
- applying a Delta Filter ensures more effective compression ratios.
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_deflate512.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.
$ rl2tool DE-PYRAMIDIZE -db srtm_deflate512.sqlite -cov srtm
$ sqlite3 srtm_deflate512.sqlite
sqlite> vacuum;
sqlite> .quit
$ rl2tool PYRAMIDIZE-MONOLITHIC -db srtm_deflate512.sqlite -cov srtm -lev 1
$ sqlite3 srtm_deflate.sqlite512 <test.sql
$
--------------
SELECT RL2_GetMapImage('srtm', BuildCircleMBR(12.5, 42.5, 0.5), 1024, 1024, 'default', 'image/jpeg');
SELECT RL2_GetMapImage('srtm', BuildCircleMBR(12.5, 42.5, 0.5), 1024, 1024, 'srtm_plus', 'image/jpeg');
SELECT RL2_GetMapImage('srtm', BuildCircleMBR(12.5, 42.5, 0.5), 1024, 1024, 'srtm_plus_ShRel_100', 'image/jpeg');
The following are visual examples of the Styling rules being tested: |
 |
 | ||
| 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 | 201 MB | 47.89 secs | 10.67 secs | 13.54 secs | 57 secs |
| -lev 2 Pyramid levels are alternatively one physical and one virtual | 156 MB | 16.98 secs | 11.15 secs | 13.91 secs | 58.36 secs |
| -lev 3 every three Pyramid levels one is physical and the following two are virtual (exactly corresponding the the default setting) | 146 MB | 10.82 secs | 12.33 secs | 15.24 secs | 1 min 5 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.
That's not all: in this case we have unsigned values, so a richest set of compressing algorithms is supported.
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.
$ rl2tool CREATE -db landsat_none.sqlite -cov landsat8 -smp UINT16 \
-pxl DATAGRID -cpr NONE -srid 32632 -res 15 -nd 0
$ rl2tool IMPORT -db landsat_none.sqlite -cov landsat8 \
-src ./LC81920292013183LGN00_B8.TIF
$ rl2tool PYRAMIDIZE-MONOLITHIC -db landsat_none.sqlite -cov landsat8
$ export "SPATIALITE_SECURITY=relaxed"
$ sqlite3 landsat_none.sqlite <test.sql
$
--------------
SELECT RL2_WriteGeoTiff('landsat8', './img101.tif', 1024, 1024, MakePoint(701957.5, 4942987.65), 15, 15, 0, 'NONE');
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 | 481 MB | 1 mins 25 secs | 4.77 secs | 7.45 secs |
| Compression: DEFLATE tile size: 512 x 512 | 256 MB | 260 MB | 1 mins 45 secs | 10.18 secs | 13.10 secs |
| Compression: DEFLATE_NO tile size: 512 x 512 | 268 MB | 272 MB | 1 mins 44 secs | 7.58 secs | 16.18 secs |
| Compression: PNG tile size: 512 x 512 | 251 MB | 255 MB | 2 mins 6 secs | 11.32 secs | 14.44 secs |
| Compression: LZMA tile size: 512 x 512 | 233 MB | 236 MB | 4 mins 45 secs | 48.76 secs | 57.47 secs |
| Compression: LZMA_NO tile size: 512 x 512 | 241 MB | 245 MB | 4 mins 55 secs | 51.28 secs | 59.31 secs |
| Compression: CharLS tile size: 512 x 512 | 206 MB | 210 MB | 1 mins 42 secs | 20.82 secs | 26.78 secs |
| Compression: Jpeg2000 (lossless) tile size: 512 x 512 | 205 MB | 209 MB | 5 mins 14 secs | 2 mins 45 secs | 3 mins 7 secs |
| Compression: Jpeg2000 (lossy Q=5) tile size: 512 x 512 | 22.87 MB | 23.3 MB | 4 mins 15 secs | 40.49 secs | 36.05 secs |
Conclusions and final remarks
Yet another confirmation of what we've already discovered during the previous benchmarks:- all lossless compressions tend to reach broadly similar compression ratios but there are impressive differences in efficiency terms.
Both LZMA and Jpeg2000 confirm their intrinsic slowness; DEFLATE, PNG and CharLS are surely more efficient and fast.
The two generic/universal lossless compressors (DEFLATE and LZMA) in this specific test present rather unbrilliant compression ratios: applying a Delta Filter clearly is a suggested option. - using a lossy compressor (in this case Jpeg2000) allows to reach much better compression ratios but at the cost to introduce an irreversible data degradation.
Few very important remarks about lossless compressors:
|
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.
$ rl2tool DE-PYRAMIDIZE -db landsat_deflate.sqlite -cov landsat8
$ sqlite3 landsat_deflate.sqlite
sqlite> vacuum;
sqlite> .quit
$ rl2tool PYRAMIDIZE-MONOLITHIC -db landsat_deflate.sqlite -cov landsat8 -lev 1
$ sqlite3 landsat_deflate.sqlite <test.sql
$
--------------
SELECT RL2_GetMapImage('landsat8', BuildCircleMBR(701857.5, 4942042.5, 24000), 512, 512, 'default', 'image/jpeg');
SELECT RL2_GetMapImage('landsat8', BuildCircleMBR(701857.5, 4942042.5, 24000), 512, 512, 'gamma_2.5', 'image/jpeg');
SELECT RL2_GetMapImage('landsat8', BuildCircleMBR(701857.5, 4942042.5, 24000), 512, 512, 'histogram', 'image/jpeg');
SELECT RL2_GetMapImage('landsat8', BuildCircleMBR(701857.5, 4942042.5, 24000), 512, 512, 'normalize', 'image/jpeg');
The following are visual examples of the Styling rules (contrast enhancement) being tested: |
 |
 |
 | |||
| 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 | 342 MB | 47.66 secs | 14.50 secs | 14.62 secs | 14.79 secs | 14.63 secs |
| -lev 2 Pyramid levels are alternatively one physical and one virtual | 273 MB | 18.02 secs | 15.30 secs | 15.59 secs | 15.93 secs | 15.75 secs |
| -lev 3 every three Pyramid levels one is physical and the following two are virtual (exactly corresponding the the default setting) | 260 MB | 10.72 secs | 16.01 secs | 16.22 secs | 16.34 secs | 16.23 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.
$ rl2tool CREATE -db indiana_none.sqlite -cov naip -smp UINT8 \
-pxl MULTIBAND -bds 4 -cpr NONE -srid 26916 -res 1
$ rl2tool IMPORT -db indiana_none.sqlite -cov naip -dir . -ext tif
$ rl2tool PYRAMIDIZE-MONOLITHIC -db indiana_none.sqlite -cov naip
$ export "SPATIALITE_SECURITY=relaxed"
$ sqlite3 indiana_none.sqlite <test.sql
$
--------------
SELECT WriteGeoTiff('naip', './img88.tif', 1024, 1024, MakePoint(679195, 4297632), 1.0, 1.0, 0, 'NONE');
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 | 802 MB | 1 mins 6 secs | 9.96 secs | 14.58 secs |
| Compression: DEFLATE tile size: 512 x 512 | 529 MB | 537 MB | 1 mins 44 secs | 17.23 secs | 22.26 secs |
| Compression: DEFLATE_NO tile size: 512 x 512 | 633 MB | 642 MB | 1 mins 38 secs | 15.57 secs | 26.82 secs |
| Compression: PNG tile size: 512 x 512 | 530 MB | 538 MB | 2 mins 19 secs | 20.77 secs | 26.00 secs |
| Compression: CharLS tile size: 512 x 512 | 560 MB | 568 MB | 2 mins 35 secs | 1 min 2 secs | 1 min 13 secs |
| Compression: LZMA tile size: 512 x 512 | 464 MB | 471 MB | 8 mins 51 secs | 1 min 29 secs | 1 min 31 secs |
| Compression: LZMA_NO tile size: 512 x 512 | 556 MB | 563 MB | 7 mins 52 secs | 1 min 34 secs | 1 min 51 secs |
| Compression: WebP (lossless) tile size: 512 x 512 | 408 MB | 414 MB | 13 mins 15 secs | 51.31 secs | 47.94 secs |
| Compression: Jpeg2000 (lossless) tile size: 512 x 512 | 481 MB | 488 MB | 11 mins 5 secs | 5 mins 32 secs | 6 mins 8 secs |
| Compression: WebP (lossy) tile size: 512 x 512 | 173 MB | 176 MB | 8 mins 3 secs | 39.23 secs | 42.02 secs |
| Compression: Jpeg2000 (lossy Q=5) tile size: 512 x 512 | 44.44 MB | 45.1 MB | 7 mins 57 secs | 1 min 18 secs | 1 mins 38 secs |
Conclusions and final remarks
More or less we still continue noticing the same general trends already seen on the last two benchmarks. Many lossless codecs (with the notable exception of WebP) fail 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.
e.g. in a previous benchmark based on TrueMarble worldwide imagery all lossless compressions reached really impressive compression ratios, but this was mainly due to the fact that abut 2/3 of the Earth's surface are deep blue Oceans. - data presenting a very rich and highly dynamic internal variance will be compressed very poorly.
- data presenting a rather poor internal variance and possibly containing many repeated sequences will be compressed in a very effective way.
- Color photographies of natural subjects usually present an impressive internal variance; thus it's not at all surprising to discover that so many lossless codecs will achieve only moderate compression ratios.
- Between all lossless codecs LZMA clearly emerges as the more efficient general purpose compressor, but in this specific test it is clearly outperformed by WebP.
- For both generic/universal compressors (DEFLATE and LZMA) applying a Delta Filter ensures substantilly better compression ratios.
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.
$ rl2tool DE-PYRAMIDIZE -db indiana_deflate.sqlite -cov naip
$ sqlite3 indiana_deflate.sqlite
sqlite> vacuum;
sqlite> .quit
$ rl2tool PYRAMIDIZE-MONOLITHIC -db indiana_deflate.sqlite -cov naip -lev 1
$ sqlite3 indiana_deflate.sqlite <test.sql
$
--------------
SELECT RL2_GetMapImage('naip', BuildCircleMBR(676195, 4296632, 256), 512, 512, 'default', 'image/jpeg');
SELECT RL2_GetMapImage('naip', BuildCircleMBR(676195, 4296632, 256), 512, 512, 'style_rgb', 'image/jpeg');
SELECT RL2_GetMapImage('naip', BuildCircleMBR(676195, 4296632, 256), 512, 512, 'style_ir_rg', 'image/jpeg');
SELECT RL2_GetMapImage('naip', BuildCircleMBR(676195, 4296632, 256), 512, 512, 'style_gr_ir', 'image/jpeg');
The following are visual examples of the Styling rules (band selection) being tested: |
 |
 |
 | |||
| 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 | 691 MB | 1 min 17 secs | 12.37 secs | 14.07 secs | 14.00 secs | 14.04 secs |
| -lev 2 Pyramid levels are alternatively one physical and one virtual | 562 MB | 28.84 secs | 13.18 secs | 14.89 secs | 14.89 secs | 14.91 secs |
| -lev 3 every three Pyramid levels one is physical and the following two are virtual (exactly corresponding the the default setting) | 537 MB | 17.55 secs | 20.92 secs | 22.69 secs | 22.63 secs | 22.52 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.
$ rl2tool CREATE -db mono_fax4.sqlite -cov mono -smp 1-BIT \
-pxl MONOCHROME -cpr FAX4 -srid 25832 -res 0.67730
$ rl2tool IMPORT -db mono_fax4.sqlite -cov mono -srid 25832 \
-dir . -ext tif
$ rl2tool PYRAMIDIZE-MONOLITHIC -db mono_fax4.sqlite -cov mono
$ export "SPATIALITE_SECURITY=relaxed"
$ sqlite3 mono_fax4.sqlite <test.sql
$
--------------
SELECT WriteGeoTiff('mono', './img89.tif', 1024, 1024, MakePoint(665370, 5102333), 0.67730, 0.67730, 0, 'NONE');
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: DEFLATE tile size: 512 x 512 | 45.4 MB | 134 MB | 42 secs | 4 mins 9 secs | 5.15 secs |
| Compression: DEFLATE_NO tile size: 512 x 512 | 37.9 MB | 127 MB | 45 secs | 4 mins 7 secs | 4.92 secs |
| Compression: LZMA tile size: 512 x 512 | 40.6 MB | 130 MB | 2 mins 3 secs | 4 mins 18 secs | 12.30 secs |
| Compression: LZMA_NO tile size: 512 x 512 | 31.1 MB | 120 MB | 2 mins 18 secs | 4 mins 15 secs | 10.30 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. - DEFLATE_NO offers a compression ratio very close to the one offered by PNG: this is not at all surprising because both them are based on the same LZ77 compression algorithm.
LZMA_NO offers an even better compression ratio but at the cost of a barely tolerable slowness; anyway FAX4 is more effective and faster. - We should note a rather paradoxical effect: in this specific test DEFLATE_NO and LZMA_NO support a better compression ratio than DEFLATE and LZMA.
Just a quick explanation: applying a Delta Filter can have a positive impact only when individual samples have a size being an exact multiple of 1 byte.
In this case we simple have 1 bit samples, so each byte will contain 8 pixels; under such conditions the Delta Filter will effectively increase dispersion of values thus worsening the compression ratio. - 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.
$ rl2tool DE-PYRAMIDIZE -db mono_fax4.sqlite -cov mono
$ sqlite3 mono_fax4.sqlite
sqlite> vacuum;
sqlite> .quit
$ rl2tool PYRAMIDIZE-MONOLITHIC -db mono_fax4.sqlite -cov mono -lev 1
$ sqlite3 mono_fax4.sqlite <test.sql
$
--------------
SELECT RL2_GetMapImage('mono', BuildCircleMBR(665370, 5102333, 750), 512, 512, 'default', 'image/png');
SELECT GetMapImage('mono', BuildCircleMBR(665370, 5102333, 750), 512, 512, 'monochrome_red', 'image/png');
The following are visual examples of the Styling rules (re-coloring) being tested: |
 | |
| 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 any 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