Developer’s Corner: GeoServer Stunning image quality + max compression rate = New PNG8 quantizer is served!

Blog ‐ Posted on 09.05.2012 by simone giannecchini

Hi everybody,
in this blog we want to introduce the new GeoServer PNG8 quantizer.

PNG8 is a shorthand for PNG 8bit, that is, a PNG image that uses a fixed palette of 256 (or less) colors and can thus encode each pixel with just one byte.
The interest in the format comes from its smaller size, often between 2 and 3 times smaller than the equivalent 24bit PNG image. Smaller size means:

  • proportional size cut in tile cache storage, which normally means cutting away several GB if not TB (depending on the amount of seending and the size of the cached geographic area)
  • shorter transfer times over the network, which means snappier front ends for applications delivered over typical Internet connections
  • or, in other terms, multiply the amount of clients that can be served in parallel given a fixed upload channel on the serving end

Historically in GeoServer you could get fast, good quality PNG8 images as long as the image was not using translucency, that is, pixels that are only partially transparent. Indeed the existing quantizer, based on the Octree algorithm, was able to produce fully opaque or fully transparent pixels, so any translucency information was lost during the on the fly color reduction.

This approach produces good quality images for opaque sources, but the result against the typical vector overlay left a lot to be desired:

The main issue is that the antialiasing of roads and symbols is lost, since it’s actually done with lots of pixels that are not fully opaque, not fully transparent, but translucent instead.

GeoServer 2.2.0 will instead ship with a new Median Cut based algorithm that can generate palettes with RGBA entries, the alpha channel preserves translucency and results in a much better looking output:

The above image can be used as an overlay on top of a background layer (e.g., Google Maps or OpenStreetMap) without significant loss of quality.
The new algorithm is also better at preserving opaque images with lots of different color shades, thought the effect is visible only against the typical DEM coloring. See the following, made with the old algorithm:

and then compare it with the same image going through the median cut version:

Performance wise the two algorithms are close enough, but the octree algorithm is generally faster at the expense of a lower quality output. 
So, you may ask, how does one choose one or the other?
By default GeoServer picks one or the other according to the image transparency:
  • if you ask for PNG8 output and the image is opaque, the octree algorithm is used
  • if you ask for PNG8 output and the image has transparency, the median cut algorithm is used instead

In case you are not happy with the default choice it’s possible to add the &format_options=quantizer:mediancut or &format_options=quantizer:octree to force the usage of a specific algorithm.

Interested in more image processing related improvements? Let us know!

The GeoSolutions team,