[QGIS-Developer] webp for qgis server ?

Tue Jul 7 03:27:17 PDT 2020

Hi Lucie, 

Thank you for updating the blog post. 

However, when you do a "plain save" to tiff in QGIS without any creation
options you will get a very suboptimal Geotiff without any compresssion.
An uncompressed Geotiff takes a long time to read and create huge file
sizes. You can see it in your table that the uncompressed geotiff
creates the largest file (no wonder). 

I would recommend the following creation option, assuming that your WMS
contains orthoimage data: 

COMPRESS=JPEG 

JPEG_QUALITY=75 (it is the default, you can either skip this option or
set it to some other quality value) 

TILED=YES

PHOTOMETRIC=YCBCR

I am 99% sure that if you use the above creation options, that the
Geotiff file shows very similar performance (or better) than Geopackage
and the file size would be also reduced drastically.

If your data contains not Orthoimages, but a small number of homogeneous
colors, you should use COMPRESS=DEFLATE or COMPRESS=LZW 

--------- 

So something like:

gdal_translate -of GTIFF -co COMPRESS=JPEG -co JPEG_QUALITY=85 -co
PHOTOMETRIC=YCBCR -co TILED=YES file.xml file.tif

BTW, in QGIS you need to do this (use the "JPEG compression" profile)
and use the green "Plus" to add the options for PHOTOMETRIC and TILED: 

I would appreciate if you could use my recommendation above and compare
the numbers again and inform us about the differences. And then I would
be surprised if Geopackage is still the fastest or GTIFF - and if gpgk,
then it would be interesting to see how much the difference really is? 

Thanks a lot, 

Andreas 

On 2020-07-07 11:37, Lucie Nicolier wrote:

> Hi everyone, 
> 
> I upgraded the blog-post with all command lines I used and how I get the base TIF and the other formats from it. 
> 
> Hope to see the parameters I used will explain the results we got. 
> 
> I'm open to received recommendations to get better result. 
> 
> Stay here for more information. 
> 
> Regards, 
> 
> Lucie 
> 
> Lucie Nicolier
> lucie at opengis.ch 
> +41 (0)79 276 67 76 [1]
> 
> [2] 
> 
> Le 09.06.2020 à 14:01, Matthias Kuhn a écrit : 
> 
> Thanks for the excellent questions Even 
> 
> Lucie has done the analysis and has all the parameters. She is not in the office these days. Once she is back I hope she can share the parameters and potentially also add a couple of additional rows to the table with improved parameters. 
> 
> Sorry that I can't help more right now. 
> 
> Matthias
> 
> On 6/9/20 1:56 PM, Even Rouault wrote: 
> 
> Matthias, 
> 
> thanks for the analysis. There are however a few unexpected results. 
> 
> 1) I'd expect gpkg pyramid_JPEG and COG_JPEG to have very similar sizes, even COG_JPEG being potentially slightly smaller. 
> 
> And I'd also expect COG_JPEG to be slighly faster (but with less confidence that my statement about size) 
> 
> Has by chance the source raster an alpha band ? In which case gpkg_pyramid_JPEG would have dropped it, whereas COG_JPEG will encode it as DEFLATE compressed mask, but still the difference is surprising 
> 
> Another explanation might be the block size. GPKG defaults to 256x256 tiles, whereas COG_JPEG to 512x512. Perhaps that affect compression efficiency. And performance? (depends if your bench maintains the GDAL raster opened between requests or not) 
> 
> If you didn't specify quality settings, both COG_JPEG and GPKG JPEG should use the same quality of 75% 
> 
> 2) For the same compression type, block sizes and number of overviews, MBTiles (the report doesn't specify the compression scheme for it) and GeoPacakge should also have similar sizes and performance. They are really close brothers, with just a few systems tables different. 
> 
> Even 
> 
>> Hi all, 
> 
>> 
> 
>> At OPENGIS.ch we have recently looked into different raster formats. The 
> 
>> results can be read here: 
> 
>> https://www.opengis.ch/2020/06/09/offline-wms-benchmarking-raster-formats-fo 
> 
>> r-qfield/ 
> 
>> 
> 
>> Not that surprising, but one of the interesting findings was that webp 
> 
>> is very efficient. Low filesize, reasonable rendering performance, 
> 
>> support for transparency. In short, it has all the potential for being 
> 
>> used as default transport format for WM(T)S. 
> 
>> 
> 
>> Looking at our server implementation, this format is not supported. Did 
> 
>> someone ever think about or even look into that? 
> 
>> 
> 
>> Regards 
> 
> -- 
> 
> Spatialys - Geospatial professional services 
> 
> http://www.spatialys.com

_______________________________________________
QGIS-Developer mailing list
QGIS-Developer at lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 

Links:
------
[1] tel:+41792766776
[2] http://www.opengis.ch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200707/1f313e06/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 66ca6782.png
Type: image/png
Size: 9289 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200707/1f313e06/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6671 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200707/1f313e06/attachment-0003.png>