I was testing out different compression algorithms for import into Avenza and I found out that for the deflate algorithm, making the bit depth 24 decreased the file size and decreased the processing time.

However the confusing part was how to make the bit depth 24. Setting NBITS (in QGIS) to 24 made a 32 bit image (as per windows explorer right-click>properties). Yet setting NBITS to 25 or 17 made a 24 bit image.

The map was a general topographic map (without shading etc.)

My results were as follows

Packbits: processing = 34 seconds, size = 875MB

LZW: processing = 41 seconds, size = 83MB

Deflate (32bit): processing = 44 seconds, size = 64MB

Deflate 24bit: processing = 38 seconds, size = 60MB

The reason that setting NBITS to 17 created a 24 bit image is that: "Option name="NBITS" type="int" description="BITS for sub-byte files (1-7), sub-uint16 (9-15), sub-uint32 (17-31), or float32 (16)" /"

All the above was done in QGIS, meanwhile ArcGIS Desktop was able to make a 60MB LZW file that processed in 33 seconds so I guess QGIS's renderers aren't as optimised.

How do I reduce the file size as much as possible using QGIS for the importing of GeoTIFFs into Avenza?

EDIT: My eventual solution to this, as prompted by the ESRI support lady that called me up, was to jump onto ArcGIS Pro. From here I figured out that the solution is to: Right click and zoom to your raster (this puts your view at 110%), then multiply the map scale by 0.909090909 (this brings your view in to 100%), then export the map as a deflate TIFF on max with tags with the resolution of the original raster (ArcGIS Pro seems to fix the weird pixel shifting that ArcMap had).

For QGIS it seems the best settings are Deflate at 24 bit (NBITS = 17) with some least significant bits removed (DISCARD_LSB = 4). Also always use NUM_THREADS = 8.

The result was 55mb in QGIS and 40mb in Arc

  • 1
    GDAL (software QGIS uses) supports Byte (8bit), UInt16, Int16, UInt32, Int32, Float32 and some other larger bit depth types for gtiffs. To deal with 1-7 bit GDAL creates a purportedly Byte gtiff but fills it with 1-7 bit data, for 9-15 bit a UInt16 filled with 9-15, for 17-31 bits a UInt32 or Float32 filled with 17-31, etc...
    – user2856
    May 5, 2021 at 3:05
  • We're a little different from other sites; this isn't a discussion forum but a Q&A site. I recommend reviewing meta.gis.stackexchange.com/a/3353/115 for tips on how to structure a good question.
    – PolyGeo
    May 5, 2021 at 5:26
  • Hello again PolyGeo, I hope the edits improved this a little
    – Buff Fox
    May 5, 2021 at 6:19
  • Your edits made it better but I've edited too, in order to focus your question on QGIS. If you also want to ask how to do this using ArcGIS Desktop, then please do so in a separate question and specify whether it is ArcGIS Pro or ArcMap that you are asking about.
    – PolyGeo
    May 5, 2021 at 6:31
  • Did you make tests also with different predictor values?
    – user30184
    May 5, 2021 at 7:13

1 Answer 1


Looking back on this a couple of years later there were a few things I missed.

  1. Where Arc refers to an image as "24bit", it actually means 8bit in 3 bands. I.e the equivalent of exporting a "24bit" tiff in Arc is a byte (8bit) tiff in QGIS.

  2. Where Arc mentions adjusting the "quality" of an exported deflate tiff, they're not actually talking about the quality of the image, given that deflate is lossless. What it appears they're referring to is the z level of the deflate compression.

  3. QGIS has the ability to control the amount of effort (z level) in the deflate compression as well. Setting the ZLEVEL to 9 for me produced a tiff slightly smaller than the Arc tiff! However it's worth remembering that the processing time in Avenza will likely be negatively affected by the extra compression. This means that's worth weighing up download time vs processing time to figure out the quickest way to get a tiff into Avenza.

  4. When QGIS renders out a rectangular tiff with no holes, it still comes with an alpha band. Arc does not do this. This affects the file size marginally. The solution in QGIS is to have the tif in byte format and export as raw data (not rendered image), assuming the original only has 3 bands.

  5. For a map with super homogenous pixel values, lossless compression creates smaller files. However for everything else, jpeg compression will work better.

  6. ZSTD is superior but is not supported by a lot of things, including Avenza.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.