This page last changed on Apr 17, 2007 by aaime.

Introduction

Geoserver does support various output formats, but at the moment lacks a PNG 8 bit one.
There's enough evidence on the MapServer site to make us will implement a map producer in that format.

This page documents some research on this format, using a relatively big version of the topp:states image as a reference. The JDK used is 1.5.0_09. Times reported are anedoctal, and represent an rough average of the time it takes to generate the image after repeated calls (first call is always quite a bit slower).

Current implementation

The current output is about 68KB and takes on average 200ms to generate. Request and sample output below.

http://localhost:8080/geoserver/wms?bbox=-130,24,-66,50&styles=population&Format=image/png&request=GetMap&layers=topp:states&width=800&height=360&srs=EPSG:4326

Gimp 8 bit output

The gimp output, generated from the current output using Gimp to perform color reduction, is a PNG 8 bit file that weights only 38kb and still looks good enough:

Current 8 bit output

The current PNG8 generator committed to trunk renders the image on the standard 8bit java palette (seemingly, the internet safe palette):

As one can see, colors are not exactly the same as the original image, that's because the original colors aren't included in the standard palette, so a nearest color replacement has been found. Moreover, you may have noticed that antialiasing has been turned off: this is because of bug 6357416, if antialiasing is on, dithering cannot be disabled. Another restriction is that when asking for 8bit rendering, each color must be completely opaque, otherwise that color will be rendered using what looks like ordered dithering. The good news is the generated image still looks good enough and it's only 13KB! So, if you choose the colors from the internet safe palette, you wont' have troubles.

Alternative renderings could be done by drawing at 24bit and then reducing to 8bit, thru ordered dithering or error diffusion, which would result in fills that aren't solit, thougth more close to the original colors. The image file is around 44KB.

Experimental palette preloading

This approach assumes an optimal palette can be computed off line, and then used straight into the rendering engine, making it work directly against a 256 colors image. This reduces the rendering time significantly, down to less than 200ms, and generates an image around 13kb, which looks like the original one, minus the antialiasing:

Implementation proposal

In Geoserver 1.5.0 we have three formats that could potentially benefit from 8bit straight rendering:

  • GIF
  • PNG
  • TIFF and GeoTIFF

GIF is always 256 colors anyways, PNG has the 8 bits variant, as well as TIFF images.
Given that we may want to support multiple palettes, we would need to provide a new parameter for requests, allowing the user to choose a custom palette, or the standard one.
The format may be PALETTE=<name> where <name> is either "SAFE" or the name of a PNG or GIF file (minus the extension) to be located in the data directory (say, in a /palettes
subfolder).

This way, we would not need for an explicity PNG8 format, but we would switch to it when the user asked for an image with palette. The same goes for TIFF.

The main issue I see with this approach is with clients such as uDig, that do not allow extra parameters to be requested on a layer by layer basis. I guess for this kind of usage, the MapServer approach, where you build a map and customize it in detail the output, should be fine. This is possible with layer groups, we should augment their defintions with parameters such as the default palette, background color and the like.


Document generated by Confluence on May 14, 2014 23:00